Migrating off SAP: timeline, stages and budget without stopping the business

Short answer: a phased migration off SAP onto a local stack takes six to twelve months. The first step is a pilot of one critical business process, in six to ten weeks. Trying to replace the whole system at once — the big bang — is the most common way these projects fail: deadlines slip, the business stalls, the team burns out.

Here is the methodology that works.

Why you cannot simply “move to the new platform”

SAP in a mid-sized company is not one system but a tangle: the ERP core, ten to fifteen years of customisation, integrations with production, the warehouse, accounting and a dozen external services. A substantial part of the logic is documented nowhere — it lives in ABAP code and in the heads of key users.

Ready-made local systems cover standard processes. But the customisations and the specific workflows — the very reason SAP was brought in originally — have to be carried across by custom development. A real migration project is almost always a hybrid: a ready-made platform, custom modules and new integrations.

The stages

1. Audit and process map (three to four weeks)

An inventory: which SAP modules are actually used, which customisations are alive, what can be thrown away. The output is a process map with priorities: what is critical to the business, what an off-the-shelf product replaces, what needs development.

A typical audit result: 30–40% of the SAP functionality is not used at all. It does not need replacing, and that is a third of the budget gone immediately.

2. A pilot of one critical process (six to ten weeks)

Pick one process, usually the one where the licensing or support risk hurts most: procurement, production planning, warehouse management. Move it onto the target stack alongside the running SAP, exercise it on real data, reconcile the results.

The pilot answers three questions: whether the target platform copes, what moving one process actually costs, and whether the client’s team is ready for the change.

3. Phased migration (six to twelve months)

Processes move in waves by priority. SAP and the new system run in parallel with data synchronised. Each wave ends with reconciliation and switching users over. A rollback stays possible at every stage — that is the insurance you pay for by running double infrastructure for a few months.

4. Decommissioning SAP

Historical data is archived in an accessible form for analytics and tax inspections, licences are closed, and integrations are switched over permanently.

Where the budget goes

Line	Share	Comment
Audit and design	10–15%	Cheap insurance against expensive mistakes
Target platform licences	15–25%	Materially cheaper than renewing SAP
Custom development	30–40%	Carrying across customisations and specific processes
Integrations and data migration	20–25%	The most underestimated line
Training and stabilisation	10%	Without it users sabotage the switch

The starting point for a mid-sized business is the migration of one critical area. The upper bound depends on the number of customisations: every five years lived with SAP adds to the estimate.

Three usual mistakes

1. The big bang. Switching the whole company on one date. It works in presentations.
2. Migrating as-is. Carrying every customisation across one to one, including the dead ones. This is exactly where the audit pays for itself.
3. Skimping on the parallel period. Turning SAP off before the new system stabilises means having no plan B at the most vulnerable moment.

In short

• Start with the audit — it cuts the scope of replacement by about a third.
• Pilot one critical process before deciding on a full migration.
• Phased waves with both systems running: six to twelve months.

One caveat worth stating: in a bank or a critical-infrastructure operator the arithmetic is different, and three to five years is the honest figure, because of regulatory reporting and acceptance testing. More on that in how long a SAP migration takes.

We run these migrations end to end, from audit to decommissioning: replacing SAP and Oracle. The methodology in more detail is in our approach to system replacement.