The 2027 SAP deadline has been on every CIO's calendar for years. The pattern of overrun has been visible in the public record for almost as long. A 2025 Horváth study among 200 SAP customers found only 8% of completed S/4HANA migrations finished on schedule, that the average overrun was 30%
What’s more: six in ten programmes missed budget, schedule or both entirely.
An SAP S/4HANA migration is an IT megaproject just like any other. In "How Big Things Get Done", Bent Flyvbjerg and Dan Gardner demonstrate that project overspends in IT megaprojects exhibit a 'fat tail'. The bigger the project, the bigger the probability of excessively large cost overruns, sometimes 200-400% of the original budget. Is that a mistake your business can afford to make?
In my fourteen years as a Forward Deployed Engineer at Palantir I worked on many migrations of varying flavours. These are some of the key lessons that I have learned over that time.
Value experienced technology
I was once asked to lead a deployment at a large government institution. They had invested heavily in the Palantir platform and had built a sizeable engineering team around developing capabilities for it. When the time came to bring their existing data into the tool though, the team wrote their own domain-specific language, ignoring the existing framework they could have used, opting for new technology instead.
Over the years, they paid for that choice in accrued technical debt.
Technology is the sum of human (and increasingly now, AI) experience. Having knowledgeable people in the room is important, but alone it's not enough for your migration to succeed. A migration platform that has run hundreds of cutovers in different organisations compounds that experience into yours. A custom build, however innovative the engineering, does not.
Think slow, act fast
On a Defence project the goal was to migrate audit from one SIEM vendor to another. The platform in question was mission-critical, with thousands of endpoints and strict uptime requirements. There was a hard deadline we had to hit, and immense pressure to deliver.
The migration succeeded in the end because the planning was thorough. We sequenced the cutover end-to-end on a whiteboard in our main conference room, which we kept there for the duration of the project, and we de-risked the hardest workstreams early in the planning phase.
The biggest unknown was how to get historical logs from the proprietary source system. Before we committed to a plan we ran a small proof of concept to prove the extraction worked at all. We did not assume the compression ratio would be like-for-like; we measured compression rates so we could more accurately capacity-plan our raw storage requirements. Hypotheses were tested, reworked and validated before any real work began.
The execution itself ran ahead of schedule and was unremarkable – and that’s a good thing. No fires to put out, no last minute surges, no need to bring in additional resource, just solid execution.
When a key deadline looms, a common instinct is to start building something to demonstrate progress. The correct move is to hold off until you are confident in a plan, rather than trying to build the plane while it’s already in the air.
Shorten the feedback loop
How can you test your migration earlier? Validation checks only get you so far – higher-order integration issues are much harder to validate against and more costly to fix. A pattern I've seen work well is to migrate data in functional units. Perhaps you can identify a suitably complex but less mission-critical workflow or business unit. As your experience grows, you migrate the more complex workflows progressively more easily and more cheaply.
Encouraging faster iteration can take many forms. Platforms like Palantir Foundry that support branching across the ecosystem allow you to test your new business logic and workflows away from production, potentially allowing for side-by-side comparisons with end-users. AI agents further scale your ability to stress test your solution, identify, and even remediate issues as they are encountered.
When it comes to large SAP migrations, the company’s own COO Sebastian Steinhaeuser named Palantir as the partner of choice. Timeline and cost reductions as high as 70%, validation accuracy above 99% within two weeks, two-thirds less scarce expert involvement. He framed an ERP migration as costing ten times the software it replaces, exactly the fat tail that Flyvberg and Gardner described.
At Valliance we believe large migrations are predictable in their failure modes; they are also predictable in what makes them succeed. We believe in using the right tool for the job. We choose proven technology over experimental tools, and we harness the ability of AI to leverage experienced technology to shorten the feedback loop. In this way we deliver migrations in weeks – not years – and under budget.
