ERP implementation team in 2026: who you need and what they do

An ERP implementation team needs a sponsor with authority, a project manager who knows ERP, business process owners from every affected function, functional and technical consultants, and dedicated leads for integration, data migration, testing, change and cutover. Cloud SAP programmes add a clean core architect and a named SAP contact. Size the team by complexity, not by company headcount, and pair every consultant with an internal person who will own that area after go-live.

This is for sponsors, CIOs and programme directors staffing an ERP programme. It covers the roles, what makes each succeed or fail, team size, what cloud ERP and AI change, and how to split work with an implementation partner.

A company I worked with had two ERP implementations running at the same time: one on SAP, one on Oracle. The Oracle project had 4,500 people working on it. The SAP project had 38. One went live smoothly. The other was a never-ending disaster. The difference was the team.

After 25 years of SAP implementations, the pattern holds. Get the wrong team, or the right people in the wrong structure, and the project drags, costs climb, and by go-live the users have already decided they hate the system.

1. Project sponsorClears roadblocks, secures budget, decides between departments
   SAP service contactOn RISE programmes, platform escalations and service reviews
2. Project managerTimeline, scope, risk and partner coordination

• Business process ownersValidate design and test real workflows
• Functional and technical consultantsConfigure, extend and push back
• Data migration leadCleansing, loads and cutover data
• Integration leadMiddleware design and data flows
• Change and training leadCommunication, champions, adoption
• Clean core architectWhere every extension lives, on cloud editions

Role	What they actually do	When they are involved
Project sponsor	Clears roadblocks, secures budget, makes cross-department calls	All phases
Project manager	Runs timeline, scope, risk and partner coordination	All phases
Business process owners	Validate design, test scenarios, represent real workflows	Explore to Deploy
Functional consultants	Gather requirements, configure modules, support testing	Explore to Deploy
Technical consultants	Extensions, interfaces, system setup	Realize to Deploy
Integration lead	Middleware design and data flows across systems	Explore to Deploy
Data migration lead	Data strategy, cleansing, loads, cutover data	Prepare to Deploy
Change and training lead	Training, communication, adoption measures	Explore to Run
Testing lead	Test scripts, SIT, UAT, defect tracking	Realize to Deploy
Cutover manager	Production switchover, downtime, rollback plan	Deploy
Clean core architect (cloud editions)	Decides where every extension lives and at what clean core level	Explore to Run
SAP service contact (RISE)	Platform escalations, service reviews, SAP roadmap alignment	Prepare to Run

My SAP implementation team roles article goes role by role in more detail.

Project sponsor

The sponsor's job is not to sign the charter and disappear. Projects stall for months when nobody above the project manager has authority to decide when departments disagree. The sponsor has to be reachable, willing to make hard calls, and present through stabilisation, not just at kickoff.

What goes wrong: sponsors who hand everything to IT. ERP changes how the business runs. If leadership isn't driving it, it fails. The steering committee guide covers how to structure the sponsor's forum.

Project manager

An ERP project manager needs to know how SAP or Oracle programmes actually run, not just general IT project management. The risks, the dependencies and the pressure at cutover are different.

What goes wrong: a project manager who defers to consultants on scope, or can't hold the business to testing deadlines.

Business process owners

IT doesn't run your business. Operations, finance, procurement and HR do. Process owners make sure the system works for real processes, not just on paper. Leave them out and you get a configuration that made sense in a workshop and fails in week one.

Involve them from the start, not at UAT to approve decisions they weren't part of.

ERP consultants

Good consultants push back. If yours agree with everything and never challenge a requirement, they are billing hours, not adding expertise. The best ones stop mistakes before they cost months.

One sign of a weak consultant: they over-customise because it's easier than explaining why the business should change a process. Every custom program has to be maintained, tested at upgrade and explained to the next team. With SAP's clean core levels, that debt is now visible: an extension built the old way lands at level C or D and shows up at the first major upgrade.

Data migration lead

Bad data in the old system becomes bad data in the new one. If nobody owns the data quality conversation before migration, the financial reports won't match reality on day one.

Data migration is a business process that needs business ownership. IT can move the data. The business has to confirm it is right.

Change management and training lead

Change management isn't training. It is communication, early involvement and finding champions inside the business before go-live. When a business assumes training is enough, users who don't trust the new system go back to their spreadsheets, and fixing that after go-live is expensive.

This lead should be building content, running pilots and measuring readiness, not handing out a PDF two weeks before go-live. On SAP programmes they now own the digital adoption tooling too: SAP is folding SAP Enable Now into WalkMe, which it bought in 2024, so new content should be planned in WalkMe.

Clean core architect (cloud editions)

SAP now grades every extension on four clean core levels, A to D. Someone has to decide, for each gap, whether it is solved in standard configuration, as a level A extension on SAP BTP or in-system with ABAP Cloud, or not at all. On large programmes that is a dedicated role. On mid-market programmes the solution architect usually absorbs it.

Partners without SAP BTP and ABAP Cloud experience can't fill this role. Ask how many extensions they have delivered under these rules, and ask to see them.

SAP service contact (RISE programmes)

Under RISE with SAP, SAP runs the infrastructure and operations of your system, so SAP is part of delivery. The CIO needs a named SAP contact for platform escalations, service reviews and roadmap alignment. Put that person on the team roster from Prepare, not just on the steering committee invitation list.

Team size should match complexity, not headcount.

Company type	Typical team size	What drives complexity
Small (single entity, under 500 employees)	10-25	Mostly standard functionality, few integrations
Mid-market (multi-site, 500-5,000 employees)	30-75	More integrations, regional process variants, change at scale
Enterprise (global, 5,000+ employees)	100-500+	Multiple entities and integrations, compliance across jurisdictions

A 50-person plant running complex make-to-order manufacturing may need a bigger, more specialised team than a 500-person company running standard retail processes. Size by what needs to get done. My guide to resource allocation planning for SAP projects shows how to build the plan.

Joule now sits in SAP's implementation tooling (SAP Cloud ALM and the SAP Activate Roadmap Viewer). SAP Build Code uses Joule to help developers build extensions on SAP BTP. Microsoft Copilot drafts status reports, steering committee briefs and change communications.

Used consistently, these tools speed up workflow-heavy roles. They make a programme somewhat leaner than the same scope would have needed a few years ago, but not dramatically smaller.

Write the tools into role definitions. Functional consultants use AI for first drafts of requirements and fit-gap documents. Project managers use it for status reporting. Developers use it where it helps. What AI doesn't change is accountability: it drafts faster, and people still own what the draft says.

Most businesses combine an internal core team who know the business with a partner who brings technical and method depth.

The internal team must be genuinely involved, not attending status meetings. Otherwise the project delivers a system the partner understands and nobody inside the company can run.

What to expect from a partner: structure, faster decisions, and experience of your kind of mistakes. What not to delegate: scope decisions, process design sign-off and user readiness. Those need internal owners.

The model that works consistently is shadow pairing. Each consultant has an internal counterpart who will own that area after go-live. The consultant delivers, the internal person learns, and the knowledge stays when the consultants leave.

When vetting a partner, ask for references from companies of your size and industry, not the vendor's showcase clients. Ask about clean core experience with examples, and how they work with SAP on RISE programmes. Vague answers tell you who is current and who is selling the version of SAP they knew three years ago.

How many people are on an ERP implementation team?

It depends on complexity more than company size. Small businesses with straightforward processes typically need 10-25 people, mid-market companies with several sites 30-75, and global enterprises 100-500 or more. A manufacturer with complex engineer-to-order processes needs more capacity than a larger company running standard retail functions.

What new team roles do cloud SAP programmes need?

Two. A clean core architect or extension lead who decides where every extension lives and at what clean core level; on smaller programmes the solution architect takes this on. And, on RISE with SAP, a named SAP service contact for escalations and service reviews, because SAP runs your system's infrastructure and operations.

What is the role of the project sponsor in an ERP implementation?

The sponsor secures budget, clears roadblocks and decides when departments disagree. They are there to make the project manageable, not to manage it. The most important thing a sponsor does is stay engaged through stabilisation. Projects that lose executive attention after cutover develop workarounds that last for years.

Why do ERP implementations need business process owners?

Because people in finance, operations, HR and procurement know how work actually gets done. Without them the team designs a system that makes sense on paper and fails in practice. Involve them in workshops and design decisions from the start; by UAT it is too expensive to change what is wrong.

What should I look for in an ERP consultant?

Willingness to push back. A consultant who agrees with everything is making their own life easier, not yours. Good consultants challenge bad requirements, flag scope creep and explain why standard usually serves you better than custom. Then check clean core experience with examples, similar-size references you can call, and whether they are solving your problem or selling the engagement they already know how to deliver.

How do you handle data migration in an ERP implementation?

Give it a dedicated lead who owns the strategy, cleansing rules, loads and go-live validation. The business owns data quality: IT can move a vendor record, but only the business knows whether it is right.

What is change management in an ERP project and why does it matter?

Preparing people for a significant change to how they work, before, during and after go-live. It covers communication (what is changing and why, early), involvement (key users in design and testing) and support (champions who help colleagues adapt). Projects that treat it as a training calendar get the same result every time: workarounds, spreadsheets and a system nobody trusts.