Status: Initiating. This is a programme we have scoped and priced, not one we have completed. It is published because how a firm plans a migration is worth as much to you as a finished story — and because the plan is specific enough to argue with.
Context
A telecoms group running eleven legal entities on a single shared ERP database. Around forty-seven daily users across accounting, purchasing, HR, helpdesk and a hospitality operation belonging to one of the entities.
The system had been in place long enough to accumulate the things that make an upgrade hard: core-level low-code customisations, custom report layouts bound directly to internal view records, five bespoke modules, five live integrations, and a server stack — operating system, database and language runtime — all below the floor the target version requires.
The problem
- The target version was three major releases away, so every risk in the system had to be crossed at once under the conventional approach.
- Low-code changes had been made at core level, including to ledger balance behaviour and document rendering — precisely the areas where a silent break is expensive and slow to notice.
- The accounting tables carried over a million journal lines, and report layouts change substantially between versions.
- A single stored-signature table had grown to roughly half the database because binary content was being held in the database rather than the file store.
- A scheduled helpdesk routine referenced fixed company identifiers and custom fields, against an interface that changed twice in the intervening versions.
- Backups ran, but the file store had no schedule and there was no written recovery plan.
What we proposed to build
A parallel system, not an in-place upgrade
A correctly sized new instance stood up beside the live one, on a current operating system, database and runtime.
A routing layer
A reverse proxy that sends each company's users to the old or new system as they are moved. Rollback for any wave is a route change, not a restore.
One-way data movement
Reference data — contacts, products, chart of accounts — copied forward through lightweight ETL. Transactional data moved once per company at switch-over, so there is one source of truth and nothing is duplicated.
Rebuilt customisation
The five bespoke modules, the low-code core changes, the custom document layouts and the scheduled routines rewritten against the new version's interfaces — the part standard upgrade tooling does not cover.
A cleanup pass before anything moves
Binary content relocated to the file store, tracking messages trimmed, closed fiscal years archived, dormant users deactivated, unused modules removed, and a file-store backup schedule and recovery plan written.
How it is sequenced
- 1
Discovery (1–2 weeks)
Separate genuine requirements from habits inherited from the old system; review every custom module, core change, report and scheduled job; confirm wave order and access.
- 2
Foundation (1–2 weeks)
Three environments, source control, deployment pipelines, the routing layer, and the cleanup pass.
- 3
Pilot wave (2–3 weeks)
HR for the smallest entity. Chosen because it proves the entire mechanism — pipeline, routing, copy, switch-over and rollback — where the consequence of failure is small.
- 4
As-is waves (6–10 weeks)
Company by company and module by module, lowest risk first, the two largest entities and their accounting last. Accounting waves are timed to a fiscal-period boundary.
- 5
Redesign and stabilisation (4–8 weeks)
The inventory process reworked rather than carried forward broken; performance, documentation and recovery hardened; the old system retired only once every wave is proven.
How it was phased
Total 4–6 months, with the as-is movement and the customisation work overlapping.
Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.
What the client keeps
- A migration runbook
- Per-wave rollback procedures
- Reconciliation reports
- The rebuilt custom modules in their own repository
- Integration documentation
- The pre-migration audit, as a permanent record of what the system contained before it moved