What I Wish I'd Known Before We Started Our SAP Transformation

Editor's note: this piece is written in the voice of a senior finance leader reflecting on a real transformation journey. Company and individual details have been generalized to protect confidentiality; the experiences and lessons described are genuine.

How It Started

I've sat through a lot of steering committee meetings in my career, but the one where we first discussed replacing our core finance system is the one I remember most clearly — not because of what was said, but because of what wasn't. We knew our legacy environment was creaking. Month-end close took eleven days. Every acquisition we made meant another spreadsheet bridge, another manual reconciliation, another person who quietly became indispensable because they were the only one who understood how the numbers actually tied together.

We approved the SAP S/4HANA business case on the strength of efficiency gains and a tidy ROI slide. In hindsight, that was the first mistake. We were solving for "replace the system" when the real question was "what does this business need to see, decide, and act on, three years from now?" Those are very different projects, and we only understood the difference about eight months in.

The Learnings

The technical migration was, honestly, the easier part. Where we underestimated the effort was in three places: data, ownership, and pace.

Data first. We assumed our master data was "good enough" because our old system had been running for over a decade without complaint. It wasn't. Cost centers with three different naming conventions across regions. Vendor records duplicated under slightly different spellings. None of it broke the old system, because the old system was too rigid to notice. S/4HANA noticed immediately, and we spent months on cleanup we should have started a year earlier.

Ownership second. As the finance leader sponsoring this, I assumed IT would drive the programme and finance would validate outputs. That's backwards for a transformation this material to how the business runs. The moment we shifted to finance genuinely owning the design decisions — not just signing off on them — the programme's quality visibly improved.

The Hard Lessons — Personally and Organizationally

Personally, the hardest lesson was accepting that my own team's resistance to change wasn't obstruction — it was fear, mostly reasonable, about whether their expertise would still matter once the system did more of the work automatically. I underestimated how much of my job, in the middle of that programme, was simply being present and honest about what was and wasn't changing for people's roles.

Organizationally, the hardest lesson was pace. We tried to sequence the rollout to minimize disruption to quarter-end reporting, which sounded sensible and instead meant we were running two systems in parallel far longer than planned, doubling the workload on an already-stretched team. A cleaner, faster cutover — even with more short-term pain — would have cost us less in the long run.

What "Doing It Right" Actually Looks Like

If I were starting this again, three things would change. I would insist on a data-quality audit before the business case is even finalized, not after kickoff. I would put a senior finance owner — not just a sponsor — inside the programme team from day one, with real authority over design trade-offs. And I would resist the instinct to protect business-as-usual at the cost of a clean cutover; the parallel-run period is where transformation programmes quietly bleed out.

None of this means the outcome wasn't worth it. Our close cycle is now measured in days, not weeks, and for the first time, our regional finance leads are looking at the same numbers, defined the same way, at the same time. That's the real win — not the system, but the shared truth it forces the organization to agree on.