Timeline
How Long Does a Full ERP System Replacement Take?
The most reliable answer I can give to "how long will an ERP replacement take" is a band: 6 to 18 months for a mid-size to large enterprise, and sometimes longer for a complex, multi-entity estate. That band is wide for a reason. The schedule is rarely set by the software, which a vendor can deploy in weeks. It is set by the surrounding work, the scoping, the data, the testing and the change management, and those are the parts that slip.
The realistic range
Understand the difference between a same-vendor upgrade and a true replacement, because it changes the answer. Lifting an existing SAP or Oracle estate to the latest version of the same product can take 6 to 12 months. Replacing one vendor's system with another, carrying your data and your business processes across, runs 12 to 18 months or more. Cloud-first, standard-configuration projects sit at the lower end; heavily customised, multi-entity ones push the top. The budget that goes with all of this is handled separately in how much a legacy ERP migration costs. SAP's own S/4HANA migration guidance reflects those same 6 to 12 month assumptions for a cloud-first, standard-configuration path.
Scoping and selection
The first two to three months are the quietest and the most important: requirements, current-state analysis, data profiling and vendor selection. People rush this to save time and end up paying for it later, because a bad scope guarantees a bad schedule. During this phase you also make the foundational choice about which implementation approach to use, which shapes every following month. Skimping here is how a twelve-month project becomes an eighteen-month one.
Design and build
The build phase, typically three to six months, is where configuration, process design and the integration work happen. It feels productive, because the screens appear and demos impress, but it is also where scope creep does its quiet damage. Every change request added here stretches the schedule, so this is where the change control board from our mistakes article earns its keep. The build is rarely what slips first, but it is what slips most easily.
Data and testing
Data migration and testing run in parallel with the build, and together they decide whether go-live happens on time. Data work should have started in scoping, not here, because dirty data is the biggest single schedule risk. Testing, meanwhile, is where optimism dies and realism is installed. A compressed test cycle, one that skips full end-to-end and user acceptance runs to protect the date, simply moves the problem past go-live.
I have never seen a project regret thorough testing, and I have seen many regret skipping it. The data and testing phases are the ones where a realistic plan holds its date and an optimistic one quietly lets it go. For the method behind the data work, see cleaning master data before you migrate.
A logistics client was told the platform could cut their replacement to eight months. What the pitch left out was that seven months in, the data team was still reconciling three legacy stock systems, and the test phase had to be compressed to hit the date. The go-live happened, then spent the next quarter catching up on the testing that was skipped. The real timeline was closer to twelve months, and the last three were the most expensive.
Cutover and stabilisation
Cutover itself, the weekend or weeks of parallel running and switchover, usually spans one to three months of planning with a concentrated execution window. After go-live comes stabilisation, and this is the phase companies most often forget to schedule. The first 30 to 90 days after cutover are when the real problems surface and get fixed, and teams that have already moved everyone back to their day jobs leave the system to fail quietly. A proper plan keeps a support and fix cycle in place for at least a quarter after go-live.
What actually drives the schedule
Four variables push your timeline more than anything else. The degree of customisation you carry, which converts directly into build and test time. The state of your master data, which determines how long data work runs. The number of business units and legal entities, which multiplies the change management and testing surface. And your appetite for change management, because the carefully phased project can be faster in the long run than the rushed one nobody adopts.
The schedule is a consequence of these choices, not a number a vendor hands you. Set them deliberately and the timeline follows, which is why the honest starting point is not "what date do we want" but "what is the full plan", the subject of how to plan an ERP migration step by step.
Frequently asked questions
How long does a typical ERP implementation take?
Usually 6 to 18 months for a mid-size to large enterprise. A same-vendor cloud migration can take 6 to 12 months, while a true replacement with data and process migration typically runs 12 to 18 months or longer for complex estates.
What takes the longest in an ERP migration?
Data migration and testing are the longest and most schedule-sensitive phases, followed by the design and build. The platform itself deploys quickly; the surrounding data, test and change work is what realistically drives the timeline.
Can an ERP migration be completed in six months?
For a small, vanilla, same-vendor deployment on clean data, six months is possible. For a genuine mid-size or large replacement with data migration, customisation and change management, it is rarely realistic, and a compressed date usually just moves risk past go-live.
Why do ERP timelines slip?
Mostly from underestimated data work, scope creep and compressed testing. Vendors can underestimate the surrounding effort, and teams often under-resource data and change management. A realistic plan with contingency avoids the predictable slip.
Sources and further reading
The argument in this article draws on public research. Where you want to go deeper, these are the sources cited in the text and further reading.
