Essential SAP implementation team roles and responsibilities

An SAP implementation needs eight roles with named, dedicated owners: executive sponsor, project manager, functional leads, IT lead, data migration lead, change management lead, implementation partner and an independent programme advisor. RISE with SAP adds SAP's own delivery contacts and makes ownership of clean core explicit. This guide is for sponsors and programme directors building a team or repairing one. It covers what each role owns, what breaks without it, team sizes by company size, and how to build the Centre of Excellence (CoE) before go-live. Start by checking which of the eight roles is held by someone who also has a day job. That is your biggest risk.

I have worked with dozens of SAP teams over the years. I have seen well-funded projects with experienced vendors fail because key roles were missing or split across people with other jobs. I have also seen underfunded projects succeed because the right people were in the room, fully committed, with clear accountability.

A global retailer I worked with had budget, leadership support and SAP as its chosen ERP. But its implementation team was a disaster. Key roles were missing. Nobody owned critical decisions. Communication ran in all directions without landing anywhere. Deadlines slipped, costs went up and confidence collapsed.

Every SAP implementation needs these roles filled. The title matters less than the accountability.

1. Executive sponsorDecisions, funding, escalation
   ERP programme advisorIndependent oversight, risk, executive alignment
2. Project managerTimeline, budget, coordination

• Functional leads and SMEsProcess design, module configuration
• IT lead and teamIntegration, development, security
• Data migration leadData quality, load sequencing, cutover
• Change management leadTraining, adoption, communication
• Implementation partnerArchitecture, integration design, delivery

Role	Primary accountability	What breaks without it
Executive sponsor	Strategic decisions, funding, escalation authority	Drift, scope fights, nobody breaks ties
Project manager	Timeline, budget, cross-team coordination	Delays, unresolved blockers, cost overruns
Functional leads and SMEs	Business process design, module configuration	Wrong configuration, post-go-live workarounds
IT lead and team	Integration, development, security, performance	Technical debt, broken interfaces, instability
Data migration lead	Data quality, load sequencing, cutover accuracy	Unusable data, failed go-live, months of cleanup
Change management lead	Training, adoption, communication	User resistance, parallel spreadsheets
Implementation partner	Architecture, integration design, delivery	Overbuilding, integration failures
ERP programme advisor	Independent oversight, risk, executive alignment	Decisions made in isolation, avoidable mistakes

Executive sponsor

The sponsor is not a name on a steering deck. They make the decisions nobody else can: budget, scope changes, resource commitments across departments. When the role is ceremonial, projects drift.

I worked with a company that skipped this role. The project drifted. No decisions, no progress, money down the drain.

Effective sponsors stay through hypercare. They attend monthly steering sessions after go-live and make small decisions that unblock things stuck for weeks. My guide to setting up an SAP steering committee covers how to structure that forum.

Project manager

The PM runs the day-to-day: timeline, risk log, coordination, updates. On a large SAP programme this is a full-time role for someone who has done it before.

I watched a client lose its lead developer mid-implementation. The whole project stopped for weeks while it scrambled to find a replacement.

The opposite problem is just as damaging. I worked with a company that had more than 30 people on its team. Nobody knew who owned decisions. Simple changes needed five meetings. The timeline stretched from 12 months to 18 from communication overhead alone.

Functional leads and subject matter experts

These people translate business operations into SAP configuration. They need to know the business well enough to challenge bad processes, and SAP well enough to know what is possible.

I worked with a manufacturing client whose team excelled because its functional leads spent time on the factory floor before designing processes.

SMEs who are half-committed always leave gaps. Either the project gets their attention or it gets their name on a sign-off sheet. Those are not the same thing.

IT lead and team

The IT team owns the technical foundation: development, Basis, security, integration and performance. On S/4HANA it also owns clean-core discipline, keeping custom code out of the core.

Integration is what most teams underestimate. Every connection to an external system needs to be designed, built, tested and owned. Interfaces break in UAT when nobody mapped the data flows. Put IT in the blueprinting sessions, not after the decisions.

Data migration lead

This role gets assigned late and under-resourced. By the time data problems surface, the programme is already under schedule pressure.

One client thought it could skip data cleansing. Big mistake. Its system was useless for months. Cleaning data under a live system costs more than a proper cleanse up front.

A dedicated migration lead runs reconciliations on every load, which is how structural problems surface before go-live. That does not happen when the role is held by someone with three other workstreams. My piece on why SAP data migration fails covers the method.

Change management lead

This is the most consistently under-resourced role. I have watched million-dollar systems sit unused because nobody wanted to change how they worked.

I watched a technically perfect implementation fail because users hated it. The configuration was correct and the process design sound. But the people who used it daily had not been involved in the design. They did not understand why things had changed, and kept using their old Excel files.

One retail client succeeded because it listened to its cashiers' concerns about the new system and adjusted its approach.

The minimum for an enterprise programme is two dedicated change management people. One person cannot cover training design, communication, resistance management and adoption tracking at once.

ERP programme advisor

An independent advisor is not the implementation partner. The job is oversight and course correction: checking that the direction still makes sense, spotting risks the delivery team is too close to see, and closing the gap between what executives think is happening and what is.

I have played this role for clients with strong delivery teams but no independent voice. I worked with a manufacturing client that almost implemented the wrong modules because nobody had linked its growth strategy to its SAP roadmap.

Spotting trouble early is the other half. I once identified a critical skills gap in a client's data team three months before it would have delayed go-live. We fixed it before it became a crisis.

The eight-role model still holds. Three things need wiring into it in 2026.

SAP's own delivery contacts on RISE

On RISE with SAP private cloud, SAP runs the infrastructure and technical operations. Its roles and responsibilities document has customers agreeing services with an SAP Cloud Architect Advisor, a Client Delivery Manager or SAP's private cloud customer centre team. Put whoever SAP assigns on your roster next to the partner team, and name the person on your side who owns that relationship. On-premise, SAP is a software vendor and this does not apply.

Clean-core and extension ownership

On S/4HANA Cloud Public Edition, clean core is enforced by design: extensions go through released APIs, key-user tools or SAP BTP. On private cloud and on-premise, modifications are still possible, but every one makes upgrades harder. Someone has to own that line.

On larger programmes this is a dedicated clean-core architect or BTP extension lead reporting to the solution architect. On mid-market programmes the solution architect usually absorbs it, but the accountability needs to be written down. When you evaluate partners, ask how many BTP extensions they have delivered and ask to see examples.

AI changes productivity, not accountability

SAP Joule for Consultants (generally available since 2025) answers configuration questions from SAP's own knowledge base and explains ABAP code. SAP Build Code generates Java and JavaScript extension code on SAP BTP. Microsoft Copilot drafts steering committee briefs and status reports.

The gains show up on workflow-heavy roles such as requirements analysis, status reporting and custom development, and only when people use the tools consistently. Treat any productivity figure you are quoted as a claim to test on your own programme.

The team is somewhat smaller than the same scope needed before these tools, but not dramatically. Write the tools into the role definitions rather than treating them as a side activity. AI drafts faster. Humans still own what the draft says.

The table shows typical sizing for each role by company scale. Treat it as a starting point and adjust for scope and geography. For the same question outside SAP, see my ERP implementation team guide.

Role	Small enterprise	Mid-market	Large enterprise
Executive sponsor	Senior director	CIO or CFO	C-suite with steering committee
Project manager	1 full-time	1-2 full-time	Programme manager plus workstream PMs
Functional leads	1-2 per module	Dedicated per module	Several per module
IT team	2-3 (shared)	4-6 (dedicated)	8+ specialists
Data migration	1 lead	1 lead plus analysts	Dedicated workstream
Change management	1 minimum	2 minimum	3-5 dedicated
Clean-core or BTP extension lead	Solution architect	Solution architect	Dedicated role
SAP contacts (RISE)	Named contact	Named contact	Named contacts with quarterly reviews
Implementation partner	5-10 consultants	15-25 consultants	30+ with a programme director

Technical skills get the system built. Emotional intelligence decides whether people use it.

I worked with a manufacturing company where the warehouse manager smiled in meetings but undermined the project behind the scenes. A perceptive change manager spotted the signs early and turned him into an advocate. Finding it at go-live would have been far harder to fix.

One client's project manager was technically brilliant but could not adapt his message. A CFO needs different communication than warehouse staff. The result was low buy-in across the organisation and a painful go-live.

The answer to "employees or consultants?" is almost always both.

Employees know the business: the processes, the politics and the workarounds nobody documents. I worked with a manufacturing company whose employees spotted implementation issues that outside consultants missed completely. Those insights saved it from a disastrous warehouse configuration.

Employees often lack implementation experience. One retail client insisted on an all-internal team. Six months in, they were hopelessly behind because they were learning SAP while implementing it.

Consultants bring pattern recognition. I brought in a consultant for a client who immediately identified a data migration approach that would have crashed its go-live.

The risk with consultants is knowledge transfer. If nobody inside learns the system, the consulting fees continue long after launch.

The model that works: shadow pairs. One pharmaceutical client gave each consultant an internal counterpart who will own that area after go-live. The consultant delivers, the counterpart learns, and the knowledge stays. Around that model, six practices make the difference:

1. Build the team before selecting software. One client bought modules its team could not maintain, and six months of chaos followed.
2. Dedicate people fully. Part-time means the day job wins when pressure arrives. I have seen critical configuration wait weeks because someone was too busy.
3. Co-locate where possible. One manufacturing client saved weeks of back-and-forth by putting its team in the same room three days a week.
4. Define escalation paths early. One retail client had a one-page document showing exactly how decisions moved up the chain. It saved countless delays.
5. Write decisions down with their rationale. I worked with a company that recorded what it decided and why. That saved endless rehashing when new executives joined mid-project.
6. Mark milestones along the way. A manufacturing client held monthly recognition events. Small thing, but it kept morale up through a gruelling 18-month implementation.

The mistake companies make after go-live is disbanding the implementation team. That is exactly when the CoE needs to take over enhancements, upgrades, governance, new-user training and keeping configuration aligned with how the business actually runs.

Plan it during implementation. I had a manufacturing client that ignored this advice. Three months after go-live, its key configuration experts left. Nobody knew how to maintain what had been built, and the system started degrading immediately.

These are the CoE roles to plan from the first months of the implementation.

CoE role	Primary responsibility
CoE director	SAP strategy, alignment with business goals, CoE operations
Solution architect	Architecture, integration design, clean-core governance
Clean-core or BTP extension lead	Extension catalogue, upgrade impact analysis
Functional consultants	Module optimisation, process improvement
Technical consultants	Development, Basis, performance, security
Change and training lead	Adoption, training, capability uplift
Data governance lead	Master data quality and standards
Integration lead	Middleware, APIs, cross-system data flows
Support lead	Issue resolution, continuous improvement
SAP relationship owner (RISE)	Escalations to SAP, service reviews, roadmap alignment

One pharmaceutical company assigned module owners who had to approve any change that might affect their area. That governance prevented the uncoordinated changes that usually make systems hard to use after two or three years.

One client invested 10% of its CoE budget in continuous learning. Three years later it was implementing new features its competitors could not touch. That is what a working CoE looks like.

This guide is part of my SAP implementation hub, which links every topic from the business case to go-live.

Why do SAP implementation teams fail even when the plan looks solid?

Usually because the plan covers the technology and ignores the people. The common patterns are key roles held by people with other jobs, subject matter experts pulled back to operations mid-project, and change management treated as a training function. When nobody owns a decision and there is no escalation path, blockers sit for weeks and the project fails on coordination, not technology.

What roles are non-negotiable on any SAP implementation?

Six roles need dedicated, accountable people: executive sponsor, project manager, at least one functional lead per major module, an IT lead, a data migration lead and a change management lead. Remove any one and the gap surfaces in the final weeks before go-live. Change management is the most under-resourced. On RISE, add a clear owner for extensions and for the relationship with SAP's delivery contacts.

What changes in team design for RISE with SAP?

SAP runs infrastructure and technical operations, so you work with SAP-assigned contacts such as a Client Delivery Manager or Cloud Architect Advisor. Put them on the roster and name your own relationship owner. Clean-core ownership also needs to be explicit: a dedicated architect on large programmes, or the solution architect on mid-market ones.

Should an SAP project team use employees or consultants?

Both. Employees bring business context consultants cannot replicate quickly. Consultants bring implementation pattern recognition employees usually lack. Pair each consultant with an internal counterpart who will own that area after go-live, so the knowledge stays when the consultants leave. Companies that skip this often pay for years of support they should have handled internally.

When should you start building the SAP CoE?

During implementation, ideally from the first months. Your best CoE members are usually your strongest implementation contributors, and if you wait until go-live they move on before you have identified them. One manufacturing client that waited lost its key configuration experts three months after go-live, and nobody knew how to maintain what had been built.

How does AI change SAP team design in 2026?

Tools such as SAP Joule for Consultants, SAP Build Code and Microsoft Copilot raise productivity on workflow-heavy roles when people use them consistently. The team is somewhat smaller than the same scope needed before these tools, but not dramatically. Build the tools into role definitions, and keep accountability with people: AI drafts faster, humans still own what the draft says.