Platform modernisation
software engineering
Platform modernisation
We find the seams in a legacy platform and replace it piece by piece, running old and new side by side until each old part can be switched off with confidence.
In practice
what you end up working with
- Customer accounts 100%, old part switched off
- Statements 70%, old and new side by side
- Payments 40%, in progress
- Reporting 10%, planned
The problem
Every change to the core system feels dangerous, and the people who understood it are leaving.
What it usually looks like.
A core platform still works, but it is slow to change, expensive to run and understood by fewer people each year. A full rewrite has been proposed, and everyone remembers the last one that ran late.
When to ask for it
- Changes to a core system take months and carry real risk
- Support for the platform, or the people who know it, is running out
- A rewrite is on the table and you want an alternative assessed first
Scope
agreed in writing before work starts
What the work covers.
In scope
- A map of what the platform does, including the parts nobody wrote down
- A dependency and risk view of each part
- A migration plan in small, reversible steps
- Building the replacement parts, with old and new running side by side
- A decommissioning checklist for each part that is switched off
Not included
- Like-for-like rewrites with a single cut-over date
- Support of the legacy platform itself, beyond what the migration needs
Approach
small steps, each one reversible
How the work runs.
- Find the seams where one capability can be lifted out cleanly
- Move one capability at a time, reconciling old and new until they agree
- Keep a way back at every step
- Switch off each old part only when nothing depends on it
Every engagement also includes decision records, tested releases, documentation you own and a planned handover. How we work
Deliverables
each one ends with something you keep
What you keep.
Deliverables
- A dependency and risk map of the existing platform
- A step-by-step migration plan
- Incremental releases with a way back at each step
- A decommissioning checklist
What it is for
- A smaller legacy core with each step, and no single day where everything has to go right
- Risk that is visible and managed, step by step
- Knowledge of the platform written down, not held by a few people
Related
Where this shows up.
Patterns
- Untangling a legacy platform C: Illustrative
- Moving batch integrations to real time C: Illustrative
Often paired with
- Technical strategy Decide what to build, buy, keep or retire, with the trade-offs written down.
- Cloud and integration architecture Design how systems connect, where they run and what happens when parts fail.
The usual first step A landscape review : A short, fixed-scope look at your systems that ends with a map and a recommendation. You decide what happens next.
Next step
start with the problem, not the service
Bring us the tangled part.
Describe the situation in your own words. We will tell you where we would start, including when the answer is a small piece of work.