01
First plan
What stays, what changes
Rebuild, wrap, or retire, decided per component. What must stay identical is written down. So is every intentional change.
Modernization
A new core under the screens your customers already use.
The business cannot pause. The system still has to change. A swarm rebuilds the core in parallel while one principal makes sure nothing your customers rely on breaks.
Why rewrites stall.
The team grows, the deadline moves, and the old system keeps running because nobody trusts the new one.
Live
The system makes money every day. A traditional programme asks it to wait eighteen months.
Regression
Nobody can list what must not break. So everything is tested by hand, or not at all.
Drift
The rewrite becomes a second product with its own backlog. The old one is still the one customers use.
While it runs
What you can see at any point.
Where it lives
Your cloud. Your repository.
- 01 Application Web, mobile, and reports run in your accounts.
- 02 Repository The first commit is already yours.
- 03 Hosting We never host it. There is nothing to unwind when we leave.
The work
How it runs, in order.
02
Contracts
Lock the interfaces
APIs, events, and reports are fixed first. The swarm builds to them. The new core cannot invent them later.
03
Parallel rebuild
Highest risk first
The journeys you would most regret breaking are rebuilt first, each with tests that prove the old behaviour still holds.
04
Switch
Turn off the old core
Traffic moves component by component. The old path is turned off only when your team has accepted the files.
01
Checks
What must not break is a test, not a hope.
Every named customer journey gets a test before the swarm touches the core. The tests run on every change. A miss stops the release, whatever the date says.
Checks
What a failed check blocks
- 01 Release A failed build is not released. Not even to staging.
- 02 Live A failed security or performance check does not go live.
- 03 Cutover No cutover without a written, rehearsed rollback.
02
Risk
You do not run the rewrite and then own every failure.
One principal owns the result until your team accepts. Not a project you manage, not a vendor you chase.
Who holds it
Delivery risk has one owner
- 01 Hours Many vendors, many hands. You own every miss.
- 02 UNIT01 One principal owns the result until you accept.
- 03 Live You decide when traffic moves. We make sure you can.
03
Acceptance
The old core stays until your team accepts.
A deployment is not a handover. Runbooks, monitoring, and open risks are in your repository first. Then the old core goes dark.
Acceptance
What is in your repository before you sign
- 01 Tests Written with the code. Running in your pipeline.
- 02 Runbooks How to operate it. Who to call. How to roll back.
- 03 Risks Every open item has an owner. Nothing is discovered later.
In the first plan
What is written before work starts.
The first plan names each of these. It is a document you can accept, edit, or decline.
Map
Rebuild / wrap / retire
Decided per component in the first plan. Not discovered in month six.
Checks
What must still work
Named journeys have pass criteria before we touch the core. They are tests, not a list.
Changes
Intentional change list
Acceptance names what is new. An unlisted change is a defect.
Principal
One named person
The engineer in charge is named in the contract. You meet them before you sign.
Files
In your repository
Code, tests, runbooks, monitoring, and open risks. There before acceptance.
IP
Code and brand stay with you
Assigned in the contract. We never host or keep the product.
Questions we get asked
Common questions.
01
How is this faster than our own team doing it?
Your team has a day job. A swarm does not. It rebuilds components and writes their tests in parallel, and the principal keeps it inside the interfaces you locked.
02
Is this a user-interface refresh?
Only if the risk is in the interface. Usually it is in services and data. We say which in the first plan.
03
Do you keep every behaviour?
We keep what you name, and we prove it with tests. Everything else is a listed change you accept.
04
Can we keep parts of the old system?
Yes. Wrap and retire are first-class choices, not failures.
05
What if the old vendor stays?
Fine, if the result still has one owner. We say in week one if the split is unsafe.
06
When does operations take it?
When they accept the files in your repository. Not when a deployment happens.
Other work
The same way of working, on a different system.
Next step
Tell us what must go live, and when.
We come back with a first plan: what done means in your words, what it costs, and when. Then it is your call.