Leave the old system without a rewrite.
You have an ERP. It works, more or less, and it is expensive, closed, and two versions behind because upgrading means re-doing the customisations. Modernisation moves you off it in slices, with both systems reconciling to each other the whole way — never as one weekend everybody dreads.
Slice by slice·Both systems reconcile·Customisations kept as code
The signs that a modernisation is overdue.
This programme is for businesses with an incumbent that has to keep running while it is replaced. If there is nothing to replace, the implementation programme is the shorter route.
The licence is the largest line
Per-seat or per-record pricing that rises whether or not you get more from it, and a renewal conversation that is really a hostage negotiation.
You cannot upgrade
Years of customisation sit outside version control, so every upgrade is a re-implementation and the system stays where it is.
The data is trapped
Reporting means an export, a warehouse, and a delay, because the vendor's idea of an API is a nightly file.
Satellite systems everywhere
Every gap has been filled with another tool, and the integration between them is a person.
How a modernisation runs.
The principle throughout is that the incumbent stays authoritative until a slice is proven. Nothing is switched off on the strength of a demonstration.
- 01Weeks 1–3
Read the incumbent
We document what the current system actually does — including the customisations nobody has looked at in years — and separate the behaviour you depend on from the behaviour you have merely got used to.
What exists at the end of it
- Inventory of customisations, reports, and integrations in use
- Data model and volumes profiled from the live database
- Behaviour split into required, replaceable, and abandoned
- Slice plan, ordered by risk rather than by convenience
- 02Weeks 3–6
Build the seam
An integration layer keeps the two systems in step while the first slice moves. This is what makes the migration reversible, and it is built before anything is switched.
What exists at the end of it
- Bidirectional sync for the masters both systems need
- A reconciliation report comparing the two, run daily
- The first slice configured, with its customisations rebuilt as code
- A documented rollback to the incumbent for that slice
- 03Per slice
Move in slices
One slice at a time becomes authoritative on the new platform while the rest stays where it is. The reconciliation report is what says a slice is ready, not a meeting.
What exists at the end of it
- Each slice cut over on its own evidence
- History migrated behind the live data, not before it
- Customisations rebuilt as versioned, upgradeable code
- The incumbent's licence count falling as slices move
- 04At the end, deliberately
Retire
The old system is read-only before it is off, and off before the licence is cancelled. Historical access is preserved as an archive you control rather than a subscription you keep paying for.
What exists at the end of it
- Full historical extract in an open, documented format
- Read-only archive under your own control
- Integrations repointed and the seam decommissioned
- Licence terminated at a boundary you chose
The order slices usually move in.
Ordered by risk rather than by ease. The slices that are hardest to reverse move last, once the pattern has been proven on something that can be undone quietly.
Reporting and read access
The new platform reads the incumbent's data and produces the reports, before it owns any of it. Nothing is at risk, and the business starts trusting the numbers early.
1 module in this wave
Buying and stock
Usually the first slice to become authoritative, because a purchase order is easier to reverse than a payroll run and the benefit shows up immediately.
Selling and the customer front end
Orders, delivery, and invoicing move once the stock position is authoritative on the new platform, because one depends on the other.
The ledger and the people
Last, because they are the hardest to reverse and the least forgiving of a bad week. Both move at a period boundary with a tested rollback in place.
What changes when the programme closes.
The point of a modernisation is not a new logo on the login screen. It is that the next change becomes cheap, which is the thing the incumbent had made expensive.
- Customisations as versioned code
- Rebuilt as apps in source control that survive an upgrade, rather than as configuration nobody dares touch.
- An upgrade path you can take
- Upgrading stops being a project. That is usually the single largest change in the running cost of the system.
- The historical archive
- Everything from the incumbent, in an open format, under your control — not accessible only while a licence is live.
- Integrations repointed
- The satellite systems you are keeping now talk to a documented REST API rather than to a nightly file.
- A licence you have left
- Terminated at a boundary you chose, with the count having fallen slice by slice rather than in one negotiation.
- Reconciliation working papers
- The daily comparisons that justified each cutover, kept, because that is what an auditor will ask for.
The terms this programme runs on
- Authority
- The incumbent stays authoritative until a slice is proven
- Evidence
- A daily reconciliation decides readiness, not a meeting
- Reversibility
- A documented rollback per slice, exercised before cutover
- Customisations
- Rebuilt as versioned code, not re-created as configuration
- History
- Open-format archive under your control before the licence ends
- Order
- By risk — the ledger and payroll move last
What this programme is usually pointed at first.
Next step