How to change your SAP implementation partner mid-project

To change your SAP implementation partner mid-project, first confirm the partner is the problem, then secure every document, design, piece of code and system access before you tell them. Only then select the replacement and run a planned handover with overlap.

Short answer: switch when the partner cannot give you quality people and cannot fix it. Do not switch to escape problems that sit on your side, because a new partner inherits those.

This article is part of my guide on how to choose an SAP implementation partner. That guide covers picking a partner at the start. This one covers what to do when the partner you picked is not working out.

I have changed a partner during a programme. The trigger was resource quality: the partner could not provide quality people when the programme needed them.

That is the sign I would put first. A programme can recover from a bad phase, a missed date or a weak design. It struggles to recover from a partner that cannot put capable people on the work.

These are the signals worth acting on, roughly in the order I would weigh them:

1. Weak quality of the people on site. The consultants delivering the work are not the people you were shown, or they cannot answer basic questions about their own area.
2. Repeated failure to replace people. Someone leaves and the replacement takes weeks to arrive, or arrives less experienced.
3. Nobody can explain the architecture and the plan. Ask the partner's lead to walk you through the target design and the path to go-live. If they cannot, nobody is steering the delivery.
4. Deliverables that do not stand up to review. Designs, test scripts and build documents that are thin, copied from another client or missing.
5. Generic answers to specific problems. The same red flag as at selection: answers that could apply to any company.

A late phase, an overrun in Explore or a tense steering committee are not reasons to switch on their own.

Before you replace anyone, find out whether the partner is really the cause. My guide to SAP programme recovery sets out the three checks I run first: the programme status, the design and what is actually deployed in the system.

That diagnosis often shows the problem is shared. Budgets get hit in Explore as the WRICEF list (workflows, reports, interfaces, conversions, enhancements and forms) grows. If you let the partner control the scope, or your key users were never released to the programme, a new partner walks into the same hole.

So ask two questions honestly:

1. Would a strong team at this partner fix it? If yes, and the partner can supply that team quickly, a change of people may be enough.
2. Would a different partner face the same problems? If yes, fix the scope, decisions and governance on your side first.

If the answer to the first question is no, because the partner cannot find the people, you have your answer. Availability of quality people is not something a contract amendment fixes.

This is the part most clients get wrong. They announce the decision, and their bargaining power disappears with it.

The outgoing partner holds the knowledge you need to replace it. Until that knowledge is in your hands, keep the decision inside a small group: the sponsor, the CFO, the programme director and your legal or procurement lead.

Start with your current contract. Read the termination clause, the notice period, the ownership of deliverables and anything on knowledge transfer or exit assistance. If your statement of work is silent on exit, my article on what an SAP statement of work must contain covers what to write into the next one.

This is what to secure, and where it usually lives:

What to secure	Why it matters	Where it should live	How to protect it
Signed designs and decisions	The new partner builds on them rather than starting again	Your document repository or SAP Cloud ALM	Copy the latest approved versions now, with sign-off records
WRICEF list and specifications	The scope baseline and the build backlog	SAP Cloud ALM or your own repository	Export the list with status for every object
Custom code and configuration	The real work done so far	Your development and test systems	Confirm everything is in your systems, not on partner machines
Test scripts and results	Evidence of what actually works	Your test tool or SAP Cloud ALM	Export scripts, results and open defects
Data migration work	Mappings, cleansing rules, load programs	Shared drives and your systems	Collect mapping documents and load programs from the data team
System and SAP support access	Control of your landscape and your SAP support account	Your systems and SAP for Me	List every partner user, ready to remove on the day
Open issues and risks	What the next team must pick up first	RAID log and status reports	Take a dated copy of the RAID log

Keep project content in your own tools

The cleanest protection is structural. Keep the programme's documents, requirements and test evidence in tools you own, from day one of any programme.

SAP Cloud ALM helps here. Customers with SAP Enterprise Support, or with RISE with SAP, can request their own tenant at no extra fee, one per customer number, according to SAP's Cloud ALM FAQ. If the project documentation sits in your tenant, it stays with you when a partner leaves.

Plan the access change for the day you announce

Partner consultants often hold S-user IDs on your SAP support account, as well as user accounts in your systems. Your own administrators control the S-user IDs in SAP for Me.

SAP's user management help says customer administrators are responsible for deleting the IDs of users who have left. It also says IDs with special functions, such as software recipient or technical contact, cannot be deleted until SAP transfers that function to someone else. Find out now which partner users hold those functions, and move them to your own people first.

Once the material is secure and the replacement is chosen, tell the outgoing partner. Do it in writing, in line with the contract, and agree the exit plan in the same meeting.

A handover runs best in this order:

Changing SAP partner mid-programme

1. 01

   Secure

   Documents, designs, code, access and the RAID log in your hands before anyone is told.

2. 02

   Select

   References on similar projects and the real team in the orals, with effort quantified.

3. 03

   Overlap

   Outgoing and incoming leads work side by side on structured knowledge transfer.

4. 04

   Re-validate

   The new partner reviews designs, build and tests against what is deployed.

5. 05

   Re-baseline

   One new plan from the evidence, signed off before the next phase starts.

Select the replacement properly

The temptation is to rush, because the programme is burning money while you choose. A full selection takes about 12 weeks in my experience, with at least three partners on the shortlist. A replacement under pressure may move faster, but do not skip the steps that protect you.

When I choose a partner for a client, I weigh client references most. On reference calls I ask about the partner's experience on projects like the buyer's. Mid-programme, that means asking references about taking over work another firm started.

Two things make me walk away from a bid: weak quality of the proposed resources, and a partner that cannot explain the architecture and the plan. After a switch caused by resource quality, apply both tests harder, not softer.

Ask candidates for the certification badges of the people they propose. SAP issues its certification badges on Credly, as its digital badges help page explains. A badge confirms an exam was passed, so check the experience through references as well.

My guides to writing an SAP implementation RFP and the SAP implementation partners by tier cover the rest of the selection.

Contract the new partner differently

The commercial model I recommend is time and materials, with the effort quantified. The contract states the estimated effort by phase and role, so you can track actual effort against it every month.

The statement of work also needs detailed assumptions and exclusions. Clients often leave these out, and on a takeover they matter even more, because the new partner will want to exclude problems it inherited.

Name the key people in the contract too. My notes on ERP contract negotiation explain the named resource clause and why it stops senior people disappearing after signature.

Overlap, then re-validate

Plan a period where the outgoing and incoming leads work together. The outgoing team walks through each design area, each open defect and each half-built object, with the incoming team asking questions.

Then let the new partner re-validate what exists. Expect them to find gaps, and expect some of those findings to be a negotiating position for more effort. This is where an independent view of the outgoing partner's deliverables is worth having.

Map the takeover to the SAP Activate phase you are in. SAP describes six phases: Discover, Prepare, Explore, Realize, Deploy and Run (SAP Activate).

A switch during Explore mostly costs design rework. A switch during Realize also costs build and test rework, because code has to be understood before it can be finished.

There is no free switch. I will not put a number on it, because it depends on the phase, the quality of what was delivered and how much the outgoing partner cooperates.

These are the costs to budget for:

1. Overlap. You pay two teams during the handover.
2. Re-validation and rework. The new partner checks designs, configuration and code, and some of it gets redone.
3. Contract exit. Notice periods, termination terms and any payment for work in progress, as your contract sets out.
4. Selection effort. Your own team's time on the RFP, orals and reference calls.
5. Your people's time. Key users repeat workshops and testing they thought were finished.
6. Delay. Every week of delay keeps the old systems, and your internal team, running longer.

Weigh those against the cost of staying. A partner that cannot staff the programme does not get cheaper as the programme gets harder, and Realize, testing and cutover are harder than what came before.

I advise clients to bring in an independent consultant at three points: the contracting stage, the design, and assessing the partner's documents and deliverables. A partner change touches all three at once.

An independent reviewer can tell you what the outgoing partner's deliverables are actually worth before the new partner prices the rework. They can also check the incoming partner's contract and its view of the design. My article on SAP partner vs independent consultant sets out who does what.

This week, find out where your signed designs, WRICEF list, test evidence and custom code actually live, and who controls access to each. Do it whether or not you plan to switch. If any of it sits only with your partner, move a copy into systems you own.

If you are weighing a partner change and want an independent view of the deliverables or the contract, you can talk to me here.

Can you change SAP implementation partner in the middle of a project?

Yes. Check your contract's termination, notice and deliverable ownership terms first. Secure the designs, code, test evidence and system access before you announce the decision, then run a planned handover with a period of overlap.

When should you switch SAP implementation partner?

Switch when the partner cannot provide quality people and cannot fix that, or when its leads cannot explain the architecture and the plan. Do not switch only because a phase ran late. Diagnose first, because problems with scope ownership or your own decisions will follow you to a new partner.

What should you get from your SAP partner before terminating the contract?

Signed designs and decision records, and the WRICEF list with the status of each object. Custom code and configuration in your own systems, test scripts and results, data migration mappings and the RAID log. Also list every partner user in your systems and your SAP support account, so access can be removed on the day.

How much does it cost to change SAP partner mid-project?

There is no standard figure. Budget for overlap between the two teams, re-validation and rework, contract exit terms, your own selection effort and delay. The later the phase, the more rework there is, because code and tests have to be understood before they can be finished.

How long does it take to replace an SAP implementation partner?

A full partner selection takes about 12 weeks in my experience, with at least three partners on the shortlist. A replacement under pressure may move faster, but keep the reference calls and the orals with the real team.

Who owns the documents and code from an SAP implementation?

Your contract decides that, so check the deliverable ownership clause. In practice, protect yourself by keeping documents in your own repository or SAP Cloud ALM tenant, and code and configuration in your own SAP systems rather than on partner servers.