SAP project recovery: rescuing a programme off track

SAP project recovery means stopping a migration or implementation that is off track, finding out what is really true about it, and re-planning from that truth. The first week decides whether it works: assess the programme status, review the design and assess what is actually deployed in the system.

Short answer: if those three checks agree with each other and with the plan, the programme needs a push, not a rescue. If they disagree, no amount of extra effort on the current plan will fix it, and you need a formal recovery with a new baseline.

This article is about that diagnosis and what follows it. It is a spoke of my ECC to S/4HANA migration guide, which covers paths, timelines and deadlines. Here the question is narrower: your programme is in trouble, so what now?

Most programmes that are late do not need rescuing. They need decisions made faster, a key user freed up or a vendor held to a date. That is a push.

A rescue is different. The signs come from the same three checks I run in week one, and the signal is simple: the status, the design and what is deployed do not agree with each other or with the plan.

Some patterns I would treat as rescue signals:

1. Status is green, the system is not. Reports say most of the build is done, but the test system cannot run a basic order to cash.
2. The design is signed, the build ignores it. Configuration was done from workshop notes, not from the approved design.
3. The plan has a go-live date, nobody can explain the path to it. Testing, data loads and cutover rehearsals have no realistic slot.
4. The scope only grows. The WRICEF list (reports, interfaces, conversions, enhancements, forms and workflows) is still rising long after the Explore phase.

Any one of these can be fixed with a push. Two or more at once usually cannot.

Week one is for finding out what is true. Not for fixing, not for blaming and not for writing a new plan. I assess three things, in this order: the status, the design and what is actually deployed.

This is what each check covers and what a disagreement tells you:

Check	What I look at	The question it answers	If it disagrees with the others
Programme status	Plan, status reports, RAID log, open change requests, spend against budget	What does the programme believe about itself?	Reporting is optimistic or disconnected from delivery
Design	Business process design, fit-to-standard outputs, WRICEF list, open design decisions	What was the business promised?	The build has drifted from what was agreed, or the design was never finished
What is deployed	The development and test systems, configuration, transports, custom code, data loads so far	What actually exists today?	Progress has been reported on work that is not in the system

The third check is the one most reviews skip. It means sitting in front of the system and running processes, not reading documents about the system.

Status reports and design documents are claims. The system is evidence.

Who should run the checks

The people who wrote the status reports should not be the people who verify them. That is not an accusation. It is the same reason auditors do not audit their own work.

I'd put someone independent of the implementation partner in charge of week one, with full access to the systems and the right to talk to anyone on the programme. If that is not possible, at least make the partner show you the deployed system live rather than in slides.

In 2018 I worked on the recovery of an aviation programme. The modules had been deployed, but nothing had been configured based on business requirements.

That is the situation the three week-one checks exist to expose. Deployed modules are not the same as a working design, and only looking inside the system shows the difference.

Airlines link maintenance, procurement and finance closely, so a gap in one area travels. I cover how SAP fits that industry in my page on SAP for aviation.

Across the 21 SAP programmes I have led or rescued, the biggest mistake I see is not planning properly at the start of the implementation. A rescue is often that missing planning, done late and under pressure.

Two other causes come up again and again:

1. The vendor controls the scope. When the system integrator writes the scope, it describes what the integrator plans to deliver. The gaps arrive later as change requests, priced by the same vendor.
2. Custom code overruns. In my experience custom code is the migration phase that overruns most often, and it is also the hidden cost that gets forgotten most.

The budget side of this, including why the Explore phase is where costs jump, is covered in my article on why SAP projects go over budget. I will not repeat it here.

Weak control is the other common thread. If the programme never had a weekly rhythm of tracking, escalation and change control, the rescue has to install one. My guide to SAP project planning and control sets out that cadence with owners.

Once you know what is true, the recovery has a clear sequence. Skipping a step usually means doing the rescue twice.

SAP programme recovery sequence

1. 01

   Diagnose

   Status, design and what is deployed, checked against each other.

2. 02

   Take scope back

   Client-owned scope, frozen, with every change priced.

3. 03

   Re-baseline

   One new plan built on evidence, with contingency on your side.

4. 04

   Gate the phases

   A quality gate at the end of every remaining phase.

5. 05

   Rehearse and cut over

   Full rehearsals before a go-live date is confirmed.

1. Take scope ownership back

Before anyone re-plans, decide who owns the scope. If the answer is still the vendor, the new plan will fail the same way the old one did.

Write the scope on the client side, compare it with what is deployed and freeze it. From then on, every change is a priced decision with an owner.

2. Re-baseline once, on evidence

A recovery gets one new baseline, not a series of small slips. Build it from what the system shows, not from what the old plan hoped.

Re-estimate custom code first, because that is where overruns come from most often. Then data, since data migration is 30 to 40 percent of the effort and is usually behind in a troubled programme.

Hold 10 to 20 percent contingency on your side, released only against named risks. My sibling article on S/4HANA migration cost explains what drives the numbers.

3. Put a quality gate at the end of every phase

Programmes in trouble have usually moved from phase to phase on dates rather than on evidence. Put that right.

In SAP Activate, the Explore phase runs fit-to-standard workshops, and approved delta requirements go into the product backlog for Realize. If the programme left Explore without a finished design, go back and finish it. SAP Cloud ALM supports quality gates as checkpoints with checklists, shown on the project overview, so the gate does not have to live in a spreadsheet.

4. Rehearse before you commit to a date

On a brownfield conversion I plan three mock conversions before cutover. Troubled programmes often cut rehearsals to save time, which moves the risk to go-live weekend.

The cutover downtime I have seen ranges from a weekend to a week. A rescued programme should know its number from a rehearsal, not from an estimate.

5. Check the deadline you are really working to

For SAP ERP 6.0 on enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027, with optional extended maintenance to the end of 2030 at a premium of two percentage points (SAP News). A recovery that pushes an ECC migration past 2027 should budget for extended maintenance openly.

Do not let the 2027 date force a go-live the rehearsals do not support. A late go-live costs maintenance fees. A failed one costs far more.

A rescue often raises the question of whether to keep the current system integrator. Sometimes replacing the partner is right. Often the bigger problem is how the programme was set up, and a new partner inherits it.

These are the questions I'd ask before deciding:

1. Can you show us the deployed system, live, against the signed design? Not a demo environment and not slides.
2. Which WRICEF objects are built, tested and transported, and which are only reported as done?
3. What is your high-level design for finishing, and which references can we call where you recovered a programme like ours? References and the high-level design are the two things I ask any partner for before signing.
4. What do you need from us that you are not getting? Missing decisions and part-time key users are often half the story.
5. For RISE with SAP customers: which issues sit with SAP rather than the partner, and who escalates them?

The red flag is the same one that makes me walk away from a partner at selection: generic answers. If the recovery plan could apply to any company, it was not written for yours. My guide on choosing an S/4HANA migration partner covers the selection side.

If the programme never had a proper assessment of the source system, run one now. The SAP Readiness Check analyses your existing system, and SAP recommends running it in production for an accurate picture of real usage. My article on the SAP Readiness Check and migration assessment explains what it misses, starting with custom objects.

Book half a day with your programme director and SAP lead, and ask them to show you three things side by side: the latest status report, the signed design and the test system running one complete business process. If those three tell the same story, push. If they do not, start a formal recovery before the next steering committee.

If you want an independent view of a programme that is off track, I help organisations with exactly this kind of diagnosis. You can book a call with me.

What is SAP project recovery?

SAP project recovery is the work of bringing an SAP implementation or migration that is off track back under control. It starts with a diagnosis of the programme status, the design and what is actually deployed, then takes back scope ownership, sets one new baseline and adds quality gates to the remaining phases.

How do I know if my SAP project needs a rescue?

Compare three things: what the status reports say, what the signed design says and what is actually deployed in the system. If they agree with each other and with the plan, the programme needs a push. If they disagree, more effort on the current plan will not fix it and you need a formal recovery.

What should happen in the first week of an SAP implementation recovery?

Diagnosis only. Assess the programme status, review the design and assess what is actually deployed, ideally led by someone independent of the implementation partner. Do not write the new plan until those three checks are done.

Should we replace our SAP implementation partner during a recovery?

Not automatically. Ask the partner to show the deployed system against the signed design, and to give you a high-level design for finishing with references from similar recoveries.

If the answers are generic, that is a strong signal to change. If the real problem is scope ownership or missing decisions on your side, a new partner will inherit it.

Why do SAP S/4HANA migrations go off track?

The most common root cause I see is not planning properly at the start of the implementation. Letting the vendor control the scope is another, and custom code is the phase that overruns most often. Data migration, at 30 to 40 percent of the effort, is usually behind as well.

Will a recovery push our ECC migration past the 2027 deadline?

It might. Mainstream maintenance for SAP ERP 6.0 on enhancement packages 6 to 8 ends on 31 December 2027, and optional extended maintenance runs to the end of 2030 at a two-point premium. Budget for extended maintenance rather than forcing a go-live your rehearsals do not support.