Insights — for transformation leadership
Inside an SAP S/4HANA Transformation: Stakeholders, Trade-offs, and the Six Phases to Go-Live
An S/4HANA transformation isn't an IT project with a finance chapter attached — it's a company-wide programme running on a fixed budget, with developers, program managers, business decision makers and business users all pulling in different directions. Here's how that programme actually gets delivered, phase by phase, and where interim finance leadership earns its place in each one.
Most write-ups of an S/4HANA transformation focus on the technology. That's not where it actually lives. It lives in a room with program managers holding a timeline and a budget, developers who can build almost anything if given enough time and money, business decision makers who have to choose what's actually worth building, and business users who will spend years living with whatever gets decided. Layer finance's own share of the budget on top, and the transformation stops being a technology question and becomes a governance one: who decides what, on what basis, and how do you keep the whole thing moving without it either stalling on indecision or shipping something nobody can actually run.
A note on scope: this is a brief overview, written from where an interim finance leader actually sits inside a programme like this — not a full account of it. The real thing is massive, with far more complexity and far more workstreams running in parallel than any single article can hold.
It's a programme, not a project
A programme this size pulls in more roles than most finance leaders expect to be negotiating with directly. Developers and the systems integrator, who can extend or customize almost anything the business asks for — at a cost and a maintenance burden that outlives the project team. Out-of-the-box SAP functionality, which is free in the sense that it's already built, but comes with a fixed way of working that the business may or may not actually fit. Best-in-class point solutions — a specialist consolidation tool, a dedicated tax engine, a purpose-built planning platform — that do one thing better than SAP's standard, at the cost of another integration to build and maintain. Business requirements gathered from people who know their current process intimately but haven't yet seen what standard S/4HANA does differently. Program managers accountable for a date and a number, not for whether the resulting process actually works for the people using it. And underneath all of it, a finance budget that doesn't expand just because the ambition does.
None of these parties is wrong to want what they want. The job of governing the programme is making sure all of it gets resolved against the same yardstick, instead of each stakeholder winning their argument in a different meeting.
Everything comes down to cost and feasibility, not "what's best"
Every design decision in a transformation like this has the same shape: someone wants something (a custom report, a bolt-on tool, a process that mirrors what's always been done), and the question is whether it's worth building at the cost it will actually take. "Best" is rarely the right question, because best is usually available — at a price and a timeline the programme doesn't have. The right question is where the genuine interest in a piece of functionality meets what's actually feasible at a defensible cost point, and that's a judgment call, not a checklist.
The programmes that stay on budget are the ones that make this trade-off explicit and revisit it on purpose — not the ones that never say no. Every "yes" to a custom build or a bolt-on tool is a small, reasonable decision in the room where it's made. The budget only breaks when nobody is adding those decisions up.
This is where finance needs a seat that isn't just "the business signs off." Somebody has to be able to look at a proposed custom development or a best-in-class add-on and immediately understand what it actually costs to build, run, and reconcile — not just what it costs to buy.
Minimum viable, workarounds, and the step-back-before-step-up problem
Not everything needs to be right on day one. Most transformations eventually have to define a minimum viable scope for go-live — the smallest set of processes that let finance close, report, and operate correctly — and separate it from the list of things that would be nice to have but can wait. That distinction only works if someone is willing to say, deliberately, that a workaround is acceptable for now: a manual step, a temporary report built outside the system, a configuration that isn't the target design but functions.
That's a genuine trade-off, not a failure. Sometimes the business has to accept a step back from the ideal design to hit a date, with a clear plan to step up to the better version afterward. The risk isn't taking that step back — it's doing it without naming it, so the workaround quietly becomes permanent because nobody owns the follow-up. Deciding which corners can be cut, and holding the line on coming back for them, takes someone senior enough in the finance process to make that call and be believed.
How the programme actually moves: six phases
SAP's own implementation methodology, Activate, breaks the work into six phases. The names are useful less as a mandatory framework and more as a shared vocabulary for what finance needs to bring to the table at each stage — and where an interim finance leader, brought in for the length of the transformation, can carry weight a permanent team stretched across business-as-usual usually can't.
-
01 · DiscoverUnderstand what actually changes
Early scoping: what S/4HANA's standard capabilities look like against what the business runs today.
- Key business input
- An honest account of the current process — including the informal workarounds finance quietly depends on, not just the documented version.
- What an interim can do here
- Bring the "as-is" finance reality into the room, clearly enough that the scope decisions the business makes are grounded in how the close actually runs, not how the org chart says it runs.
-
02 · PrepareGovernance and capacity
Project standards, environment setup, and a plan for data, testing, and training take shape — including who the future super users and business process owners will be.
- Key business input
- Naming the finance people who can genuinely be pulled off business-as-usual, and starting to identify which of them will become super users or business process owners once the system is live.
- What an interim can do here
- Show up fully dedicated to the programme with no BAU competing for their time — often the single biggest capacity unlock finance can offer — and help the business think through who needs to be trained, and as what, well before go-live.
-
03 · ExploreFit-to-standard workshops
Requirements get mapped against SAP's standard, preconfigured processes, workshop by workshop.
- Key business input
- Finance needs to show up ready to say, honestly, where the business genuinely can't run on standard — versus where "we've always done it this way" is the only reason.
- What an interim can do here
- Help the business tell the difference between a real requirement and an attachment to the old way — usually the single biggest cost driver in the whole programme — so the call the business makes is an informed one.
-
04 · RealizeBuild, migrate, test, train
Configuration, custom builds, legacy data migration, iterative testing cycles, and the first training materials all take shape here, usually in sprints.
- Key business input
- Finance stays close to reconciliation and validation strategy — GL-to-subledger, intercompany, group reporting — rather than delegating it entirely to an IT test script, and confirms who its named super users and business process owners will actually be.
- What an interim can do here
- Support the finance-side test scripts and data-cleansing priorities, and help shape training content around how the close will really run, freeing permanent business users to keep today's close going in parallel.
-
05 · DeployTraining, cutover, and hypercare
End-user and trainer training, dress rehearsals, the production cutover itself, and the first weeks of hypercare support.
- Key business input
- Super users and business process owners trained and genuinely ready to support their teams from day one, and named decision-makers who own the go/no-go call during the cutover weekend.
- What an interim can do here
- Make sure the numbers behind that go/no-go call are clean and clearly presented, so the business can decide quickly and with confidence — the call itself stays with the business — and stay close through hypercare as questions surface.
-
06 · RunStabilization
Operating the new system, and closing out whatever "step up" backlog got deferred at go-live.
- Key business input
- Keeping the step-up backlog alive on purpose, rather than letting go-live workarounds quietly become permanent.
- What an interim can do here
- Stay through the first few real closes post-go-live to help validate that the new numbers hold up, supporting the super users and business process owners as they take on the first real questions, before handing over to permanent staff on a system that's proven, not just live.
The thread underneath the phases: data, testing, cutover, validation
Data cleansing, testing, migration, cutover and validation don't belong to a single phase — they run underneath Explore, Realize and Deploy as one continuous thread, and treating them as a late-stage checklist is one of the more common ways transformations lose their timeline.
- Data cleansing has to start as early as Prepare and never really finishes early enough — open items, stale master data, and orphaned records that the old system tolerated all surface here, and the longer they're left, the more expensive they are to fix.
- Migration happens across several rehearsal loads before the real one. Each mock load is a chance to catch what cleansing missed, which is exactly why skipping rehearsal cycles to save time is a false economy.
- Testing moves from unit tests as configuration lands, to integration testing once modules start talking to each other, to UAT once the business can actually touch the system — finance needs to own its slice of every one of these, not just show up for UAT.
- Cutover is a sequencing plan, freeze windows, and rehearsal runs, built specifically so the live weekend itself is boring instead of chaotic.
- Validation means reconciling what actually loaded against what should have loaded, immediately after cutover, before anyone downstream starts trusting a number.
- Stabilization — the weeks after go-live, often called hypercare — is the real test: whether finance can close on the new system without quietly falling back to the old workarounds nobody officially approved.
Why this is exactly where interim finance leadership earns its keep
I've now been through three major ERP/S/4HANA rollouts from inside the finance function, most recently from the Close & Consolidations workstream of a global S/4HANA transformation across 29 EMEA entities. The value isn't generic finance knowledge — that's the baseline, not the differentiator — it's having sat close to these specific decision points enough times to recognise which fit-to-standard battles are worth raising, which workarounds are reasonable to live with for now, what reconciliation ownership actually needs to look like, and what a stabilization period needs before the business can trust it. An interim is rarely, if ever, the one with the authority to decide any of this on the business's behalf, and that's as it should be — but authority and influence aren't the same thing. What experience like this offers is the standing to ask the right question at the right moment and be heard, and the pattern recognition to help the business reach the right call faster and with more confidence, rather than working it out live, on the company's own numbers, for the first time.
This is a brief, high-level pass over the shape of the programme, not the full picture. Every phase and every thread named here — fit-to-standard, data cleansing, migration, testing, cutover, validation, stabilization — has its own depth underneath it, with detail and decisions this piece doesn't attempt to cover.