SAP S/4HANA Project Rescue: How to Turn a Failing Implementation Around

Here is the truth about failing SAP S/4HANA projects that vendors will not put in a slide: most of them are rescued, and most of them are rescued by finance, not by IT. The program looks like a technical problem, a data problem, or a scheduling problem, and it is usually none of those at the root. It is a governance problem wearing a technical costume. Once you see that, the path back is clearer than the doom reports suggest, and it starts with the Finance Director, not with another consultant workshop.

I have been pulled into rescue situations on both sides of the table, as the diagnostician and as the accountable executive. This article is the playbook I wish someone had handed me the first time: how to tell you are failing before the vendors admit it, what to triage first, how to re-scope without losing face, and what actually separates rescued projects from the ones that limp to a costly end.

The first diagnostic: how to know you are failing

Projects rarely announce their own failure. They degrade. The early warning signs are visible in the finance data long before the steering committee admits to a problem, because finance is where every delay eventually lands.

Watch for these five signals:

1. The plan says one thing and the calendar says another: the go-live date has moved twice, and the second move was quietly decided in a room you were not in.

2. The change requests are piling up faster than the team can assess them, which means scope is being decided by whoever shouts loudest.

3. The data team keeps asking for more time on reconciliation, and the open items are not converging to zero.

4. The business users have stopped attending the workshops, which is the single most reliable sign that the project has lost its constituency.

5. Most telling of all, the reporting is getting prettier while the substance stalls: more dashboard, less decision.

None of these is fatal on its own. Together, they are the signature of a project that is spending money without converting it into readiness. The good news is that this is exactly the stage where rescue is cheapest.

The triage: what to fix first

When you take over a failing implementation, resist the urge to restart the whole machine. Triage means stabilizing the patient, not redesigning the medicine. There are three things to fix in the first two weeks, in this order.

Scope drift — boundaries sliding outward. The rescue starts by freezing scope, not by redesigning the machine.

First, freeze the scope. A failing project is almost always a scope project: too many requirements, too many interfaces, too many custom reports that nobody has actually asked for in writing. Declare a scope freeze effective immediately, and make it stick for thirty days. Every request goes into a backlog, not into the build. This single act buys you the air you need to see the project clearly.

Second, get the finance calendar onto the project plan. The most destructive gap I see is the one between the IT project timeline and the finance calendar: month-end, quarter-end, year-end, audit, tax filing. If the cutover lands in the middle of a fiscal year-end, or the training window collides with the annual close, the project will lose to the calendar every time. Move the plan around finance, not the other way around.

Third, force a hard conversation about the go-live date. The current date is probably someone's hope, not someone's calculation. Replace it with a date derived from the actual critical path: when the data will be clean, when the tests will be done, when the users will be trained. A realistic date is a gift, even when it is later than the one on the wall.

The re-scope that saves projects

Re-scoping is the part everyone dreads, and it is the part that actually works. The trick is to frame it as a decision, not a defeat. There are three moves, and you can do them in combination.

The first move is to cut custom code, not functionality. In a typical S/4HANA program, a large share of the budget goes to re-implementing custom code from the old ECC system. Much of it does not need to be rebuilt at all. S/4HANA handles a lot of what used to require custom development, and the standard processes are better maintained, better documented, and cheaper to upgrade. Every custom object you drop is a future upgrade that disappears. Ask the team to justify each piece of custom code against the question: does the business process genuinely require this, or does the standard system do it well enough? You will be surprised how much survives the question.

The second move is to split the program. The classic error is the big bang: everything goes live at once, because the system integrator prefers to bill it that way and the narrative says it is cleaner. Rescue programs split. Put finance first, put the highest-priority legal entities first, put the core processes first, and let the rest follow in a later wave. Phasing converts a stalled monolith into a series of smaller, achievable milestones, each of which rebuilds confidence.

The third move is to protect the audit and compliance scope. This is the one place where cutting is not a virtue. If your company is in a regulated environment, the audit trail, the tax reporting, and the compliance controls are not optional decoration; they are the reason the system exists. What you cut is everything that does not serve a named decision or a named control. Keep the rigor where it is real, and let the rest go.

Why the first close is the whole game

There is one event that reveals everything about a migration: the first month-end close after go-live. It is the moment when the abstract project becomes the concrete numbers the company lives on, and it consistently takes thirty to fifty percent longer than planned, even on good projects. Rescue programs treat it as a first-class workstream from day one, not as an afterthought.

Plan it as its own project. Define the close process in the new system, step by step: which transactions post, which reconciliations run, which reports replace the old ones, who signs off each step. Run it in the quality system as a full dress rehearsal before go-live, more than once if needed. A team that has closed the books in QA is a team that will survive the real thing.

And plan for hypercare, not just go-live day. The first two or three close cycles after go-live are where the real problems surface: the interface that breaks at the worst moment, the allocation that runs wrong, the report that nobody recreated. Budget for extended hypercare through at least two or three closes. The projects that fail do so not on cutover night but in the months after, when the support team has already been disbanded.

The go/no-go decision is yours

Here is the governance point that separates rescued projects from failed ones: the Finance Director must own the go/no-go decision. Not the IT director, not the system integrator, not the project manager. Finance is the customer of the financial system, and the customer has to sign for the goods.

The decision deserves a checklist, and it should be brutal:

1. The balances reconcile between legacy and S/4 within tolerance, not "mostly."

2. The business users have signed off on acceptance testing, not the IT team signing on their behalf.

3. A simulated period-end close has been completed successfully in the quality system, not just planned.

4. All open items in general ledger, receivables, payables, and asset accounting are verified and migrated.

5. Tax reporting is verified for the current period.

6. There is a rollback plan that is documented, tested, and executable within twenty-four hours.

7. At least ninety percent of impacted finance users are trained, not seventy, not "we'll train them after."

8. The critical financial interfaces, bank reconciliation, payment runs, intercompany postings, have been tested end-to-end.

If any one of these is not true, the answer is no. Every finance migration that failed badly had the same root cause: the Finance Director was consulted, informed, or present, but did not actually hold the authority. In one rescue I know well, the finance leader used that authority to delay go-live by three weeks, fixed a data problem that would have poisoned the first close, and the project shipped clean. The delay was the cheapest three weeks in the program's history.

The vendor pressure you need to recognize

Failing projects attract a specific kind of pressure, and you need to name it before it works on you.

The first is artificial urgency. The 2027 maintenance deadline is real, but it is often used to force multi-year signatures in a single quarter. The deadline does not require you to sign a bad plan; it requires you to have a plan. A realistic one that starts next quarter beats an unrealistic one that starts next week.

The second is the overscoped cleanup. Custom code cleanup is real work, but it is frequently sold as mandatory when the migration approach would handle it anyway, adding twenty to forty percent of unnecessary cost. Ask which cleanup items are genuinely on the critical path and which are nice-to-have modernization. Price them separately, and decide separately.

The third is the license conversation. SAP license audits and true-ups have a way of appearing six to twelve months before a migration discussion, and the cloud pricing discussion deserves its own analysis. RISE with SAP can cost two to three times the on-prem equivalent for a mid-market company in the early years, and the total cost of ownership story only makes sense modeled over several years. Model it, with your own assumptions, before you sign anything.

The fourth is the migration approach itself. The industry narrative pushes greenfield: new system, clean start. The rescue instinct should be the opposite. Brownfield, migrating your existing system to S/4HANA, delivers most of the core benefit at a fraction of the cost and timeline, provided your chart of accounts is not genuinely broken and your custom FICO code is under control. If your CoA is clean and your regulatory environment is stable, brownfield is the rescue play. Greenfield belongs to the programs where the chart of accounts is a disaster, the company is merging, or the processes need rebuilding from scratch.

What the numbers actually say

The benchmarks are useful because they calibrate your rescue plan against reality. A brownfield migration for a mid-market company runs twelve to eighteen months and costs half a million to two million euros. Greenfield runs eighteen to thirty-six months and two to fifteen million or more. Selective data transition sits in between. The finance rule of thumb: clean chart of accounts and no regulatory change means brownfield; a fragmented chart of accounts beyond a few thousand accounts, or heavy custom FICO code, means you should think seriously about greenfield or selective.

The real project data tells the same story as the theory. A mid-market manufacturer, eight hundred million in revenue, ran a brownfield in fourteen months for 1.1 million. The first close took twelve days against a planned four, because the close cycles had never been rehearsed in QA. A large utility ran a greenfield over twenty-eight months for fourteen million; rationalizing the chart of accounts from eight thousand accounts down to 2,200 took fourteen months alone and added a six-month delay. A professional services firm of five hundred employees ran brownfield in ten months for 650,000, and it succeeded because the finance director exercised go/no-go authority and delayed three weeks. A retail group of three thousand employees ran a big-bang greenfield for thirty-six months and twenty-two million, failed the first cutover, and lost four months; the root cause was a finance director who was not involved in cutover planning at all.

Notice the pattern. The projects that succeeded treated finance as the owner of the outcome. The projects that failed treated finance as a stakeholder to be informed.

The rescue sequence, in one page

If you take one thing from this article, take the sequence. Week one: freeze scope and name the realistic go-live date. Week two: put the finance calendar on the plan and kill the custom code that does not earn its place. Month one: re-scope into phases, finance first, and protect the audit and compliance scope. Then build the close as a project of its own, rehearse it in QA until it is boring, and hold the go/no-go authority in the hands of the person who will live with the result.

And here is the part nobody tells you when the project is failing: this is the moment where you are most useful. A stalled S/4HANA program is not a career hazard; it is an opportunity to be the person who made the hard calls, protected the calendar, cut the custom code, and shipped a system finance can actually close the books on. That reputation is worth more than any project that went smoothly.

The tools are all there. The standard processes are strong, the migration approaches are proven, and the consultants who know S/4HANA finance command a premium because the demand is real. What the failing projects lack is not expertise; it is ownership. Take the decision rights, use the checklist, and let the calendar and the close be your referees. You will know within one quarter whether the rescue is working, and so will everyone else.

Sources

• SAP ECC Support Ends in 2027: What Leaders Should Do (Crowe)

• The Economic ROI of SAP S/4HANA Cloud Public Edition (SAP, Forrester TEI)

• SAPinsider S/4HANA Migration Benchmark Report 2025

• IDC Business Value of SAP HANA Cloud

• Forrester TEI: Total Economic Impact of SAP Cloud ERP Private Edition

• SAP Help Documentation: New Asset Accounting S/4HANA