Legacy ERP systems are expensive to maintain, slow to change, and often held together by institutional knowledge that lives in one or two people's heads. Everyone knows the system needs to go — but replacing it feels too risky to actually do.
The fear is justified. ERP replacements done wrong have derailed companies for months. Done right, they are almost invisible — operations continue, data is preserved, and the new system is adopted incrementally. The difference is approach.
Why Big-Bang Replacements Fail
The traditional approach — freeze requirements, build the new system for 12 months, cut over on a single date — has a poor track record. The problem is that business requirements change over 12 months. By the time the new system is ready, parts of it are already wrong. And the cutover date creates enormous pressure that leads to shortcuts, incomplete testing, and rushed training.
- Requirements gathered at the start are stale by the time the system ships.
- Staff learn a completely new system all at once, during peak pressure.
- Any bugs discovered post-launch have immediate operational impact.
- Rollback is nearly impossible — you cannot easily go back to the old system.
The Strangler Fig Pattern
The strangler fig pattern — named after the plant that gradually grows around a tree until the original is replaced — is the most reliable approach to ERP modernisation. Instead of replacing everything at once, you replace one module at a time, running old and new in parallel until confidence is established.
The core principle: the new system starts empty and gradually takes over business functions one by one, while the old system continues handling everything else. You never have a day-zero risk.
How We Structure a Phased ERP Migration
Phase 1: Audit and Document the Existing System
Before writing a single line of new code, we reverse-engineer the existing system. Every business rule, every calculation, every edge case gets documented. This is the phase most teams skip — and it is the reason most migrations fail. You cannot replace what you do not understand.
Phase 2: Start with the Lowest-Risk Module
Pick the module that is most painful, most self-contained, and least risky to migrate first. For most businesses this is reporting and analytics — you can build it alongside the old system with no operational risk, immediately delivering value while building team confidence in the new platform.
Phase 3: Data Sync Between Old and New
During the transition period, both systems need to share data. We build synchronisation pipelines that keep them in sync — so staff using either system see consistent information. This is temporary infrastructure; it gets retired when the migration is complete.
Phase 4: Module-by-Module Migration with Parallel Running
Each subsequent module follows the same pattern: build it on the new platform, run it in parallel with the legacy system, validate the outputs match, train staff, then switch. Staff only learn one new module at a time, and you always have a fallback.
What to Expect on Timeline
A phased ERP modernisation typically takes 6–18 months depending on system complexity — but value is delivered from month one, not month twelve. Businesses typically see the biggest operational improvements from the first 2–3 modules migrated, which justifies continued investment in the programme.
Rule of thumb: if you have been living with your legacy system for more than 5 years, budget at least 3 months of discovery before migration begins. The documentation phase is not optional — it is the insurance policy for everything that follows.
The Right Time to Start
The best time to start an ERP modernisation is when you still have runway — not when you are in crisis. A system that is barely functioning under load is the worst possible starting point for a migration. If your legacy ERP is causing daily pain but has not broken catastrophically yet, you are in the ideal window. The migration will take time, and you want that time to be on your terms, not dictated by an emergency.