How long a SAP migration takes in a large company, and what the timeline depends on

Short answer: for a mid-sized company a full move off SAP takes one to two years; for a large one, two to four. But those figures are nearly useless without unpacking what makes up the timeline: two companies of the same size can differ threefold.

Here is what actually determines it.

Why company size is a poor predictor

Intuition says more revenue and more staff means a longer migration. In practice the correlation is weak.

A company with revenue in the tens of billions that uses SAP as an accounting core without deep customisation migrates faster than a company half its size where hundreds of user developments accumulated over ten years and half the business logic lives in ABAP written by people who have left.

Four things determine the timeline, and none of them is size.

Factor one: how many modules are actually used

The most common discovery of the first audit weeks is that a substantial part of the deployed functionality does not work. Reports nobody opens. Reference books filled in once at rollout. Modules bought as part of a licence and never switched on.

In our experience of unpicking such systems, a third or more of the functionality turns out to be dead. It does not need replacing, and dropping it shortens the project more than any acceleration in development.

Hence a practical conclusion: taking inventory before estimating the timeline is not bureaucracy but the most profitable stage of the project. Until it is done, any estimate of duration is guesswork.

Factor two: the volume of customisation

Stock SAP migrates along a known path. The problem is that stock SAP does not exist in a living company — years of operation accumulate customisations for specific processes.

It matters to distinguish two types. Customisations that compensate for a missing feature usually carry across: the target system either has an equivalent or one gets built. Customisations that implement a unique business process require full development, and it is those that set the timeline.

A separate difficulty: part of the logic is documented nowhere and exists only in code. Unpicking such code takes time comparable to writing it again, and sometimes more.

Factor three: integrations

An ERP rarely stands alone. Attached to it are the warehouse, production, banking, electronic document exchange, marketplaces, supplier portals, BI systems.

Every integration goes through a full cycle during migration: work out how it works, reproduce it on the new side, test it on real data, switch over. Fifteen integrations are not fifteen small tasks but a substantial share of the project.

Factor four: the readiness of the client’s team

The most underestimated and most frequent source of slipped deadlines.

A migration needs people from the business: those who explain how the process works, check the result against their own data and decide to switch over. Those same people are simultaneously doing their actual jobs — closing the month, shipping, running payroll.

If such people are not explicitly assigned, the project stalls not on development but on acceptance. Developers deliver an area, wait for verification, and verification slips two weeks because of quarter-end. Five such slips turn a six-month plan into a year.

A practical sign of a realistic plan: it states whose time on the client side is required at each stage, and how much of it.

Benchmarks by stage

For a mid-sized company with a typical amount of customisation:

Audit and process map — three to four weeks. Inventory of live functionality, the integration map, priorities.

A pilot of one critical process — six to ten weeks. One process is moved to the target stack alongside the running SAP and checked on real data. The pilot answers what moving one area actually costs, and only after it does the estimate for the whole project stop being an assumption.

Phased migration — six months and up. Areas move in waves, each ending with reconciliation and switching users over. For a large company this phase takes years.

Decommissioning. Archiving history in a form accessible for inspections, closing licences, switching integrations over permanently.

How many people a migration needs

The question is asked almost always and appears in plans rarely. Benchmarks for a mid-sized company, per migration wave:

On the contractor side — four to seven people. An architect part-time, two or three developers, an integration engineer, a process analyst, a tester. On the pilot the team is smaller, two or three.

On the client side — three to five people, and this is the decisive part. The process owner who explains how things actually work; the key user who checks the result against their own data; a specialist in the accounting system; an IT representative for infrastructure and access. Plus whoever decides to switch over.

What is critical is not the number but the share of their time. A working benchmark is 20–30% through the wave, rising to half during acceptance weeks. If people take part on a leftover basis, gaps of one or two weeks appear between delivering an area and verifying it, and a six-month plan becomes a year without a single technical problem.

For a large organisation — a bank, a chain, a holding — what multiplies is not the contractor’s team but the number of parallel waves: areas migrate in groups, each with its own process owners. Hence timelines in years: not because development is slower, but because there are more waves and each needs its own people for acceptance.

Separately: migrating off SAP in banks

Banks ask about this more than anyone, and their answer is different: three to five years, with team size counted in parallel waves rather than people. There are three reasons, and none of them is about data volume.

First: SAP in a bank is not what serves customers. The core of banking automation is the core banking system, and that is almost never SAP. SAP in a bank sits on bookkeeping, treasury, procurement, HR and sometimes consolidated reporting. Hence a consequence that changes the estimate substantially: what migrates is not “everything” but the perimeter around the core — and that perimeter is tightly stitched to the core banking system and to the reporting areas. The project looks smaller than the name suggests and is simultaneously harder on integrations.

Second: regulatory reporting cannot be migrated “later”. A bank has mandatory forms and a hard calendar for filing them. Every migration wave must end such that the next reporting date passes without a failure, and parallel calculation in the old and new systems runs longer than usual — not a month but one or two full reporting cycles. That adds weeks to every wave which do not exist in projects at manufacturing companies.

Third: a bank is usually a critical infrastructure operator. That changes the procedures more than the technology: change approvals, requirements for security tooling, certification of environments. The work runs alongside development, but it is what slows acceptance.

Headcount. The benchmarks per wave are the same as above: four to seven on the contractor side and three to five on the bank’s. The difference is that several waves run at once — by area and by process owner — plus roles appear that do not exist in an ordinary project: a regulatory reporting specialist and an information security representative. In practice that means the total team runs to dozens of people, but no individual wave gets larger: their number grows, not their size.

Hence the main practical conclusion: timelines in a bank shorten not by hiring developers but by the number of process owners the bank is prepared to assign to acceptance simultaneously. That constraint is not technical, and a contractor cannot remove it.

An honest caveat: we have no completed project in a bank. The above is an analysis of the factors, not our case study. Our experience is manufacturing and trading companies, and there the difference from the average timeline is explained by the same four factors from the start of this article.

Where to look at other people’s migrations, and how to read them

The question “how long did this take other large companies” is asked almost always, and it is a fair one: there is nothing to calibrate a first project of this scale against. Public sources exist, though not many:

• project databases at industry analysts — deployment cards naming the client, the contractor and the year;
• trade press — reviews and interviews with IT directors;
• conference talks by vendors and integrators, usually with slides published;
• deployment pages from the vendors themselves.

But these materials need a correction applied, or they misinform. Almost every public case is written by whoever delivered the project, and the timeline is counted from a convenient point. Four questions worth asking of any case study:

1. What exactly moved — the core or the satellites? “We left SAP” often means reporting and a couple of adjacent modules were replaced while the financial area stayed. Those are different projects by a wide margin.
2. From what date is the timeline counted? From contract signature, from the start of development, or from the end of discovery — easily six months of spread.
3. Does the timeline include pilot operation? Launch and stable running are not the same thing; the parallel period and reconciling discrepancies rarely make it into a press release.
4. How many legal entities, plants and warehouses are in scope? One site and fifteen sites are not “the same project, bigger” but a different number of waves.

What public cases almost never contain: failed projects. A company that spent two years and went back to the original system does not talk about it. So in open sources the average migration timeline always looks shorter than reality — you are seeing a sample of successes only.

What doubles a project

Three scenarios occur more often than the rest.

Trying to move everything. Without an inventory, dead functionality gets into the plan and a third of the budget goes on reproducing what nobody uses.

A single cutover instead of waves. It seems faster. In practice the risk is so high that the preparation stretches longer than the waves would have taken, and if a discrepancy surfaces after go-live you are rolling back under load.

No assigned people on the client side. Development runs to plan, acceptance does not. Timelines double without a single technical problem.

More on the order of stages and parallel running in migrating off SAP: timeline and stages, and on the methodology in replacing a system without stopping the business.

In short

Asking “how long does a SAP migration take” without inputs is like asking the price of a house without the number of floors or the region. The answer is determined by the share of live functionality, the volume of unique customisation, the number of integrations and the availability of people for acceptance.

The only way to get a meaningful estimate is to start with an inventory rather than with choosing a target platform. Three or four weeks of audit turn “somewhere between one and four years” into a plan with stages.

If this is live for you, look at replacing SAP and Oracle and the WMS replacement case with accounting integration and on-premise deployment.