AR5: Legacy modernisation: strangler fig, anti-corruption layers and safe migrations
Plans with a way back
🎯You'll be able to
Write a modernisation plan in which every step has a change, a check and a rollback, with staged rollout and measures of success.
🏠The everyday picture
A mountain guide plans each day's climb with a turn-back time: if the group hasn't reached the ridge by 1 pm, they go back down. The decision is made before anyone is tired.
📘What it really is
- Each step: what changes, how you'll check it worked, and how to undo it. "None" isn't a rollback.
- Order steps so early ones are safe: boundaries before services, services with no traffic before services with traffic.
- Parity checks: while both paths exist, check they give the same result (the same message text either way).
- Success measures with numbers, decided before the rollout: delivery rate, extra delay on orders, outbox size, duplicates.
- Turn-back rules: what figure makes you set the flag back, decided in advance.
📝A worked example
Input: moving RasoiRoute's notifications.
Steps:
- Front door and boundaries (rollback: revert the pull request).
- Service built to the contract, no traffic (rollback: stop it).
- Templates migrated (rollback: delete the service's copy).
- Remote path, deadline and outbox behind the flag at 0% (rollback: leave at 0).
- Rollout 5%, 25%, 50%, 100% (rollback: previous stage or 0).
- Remove the old sender after two weeks at 100% (rollback: restore it from the previous release).
Expected output: a Steps table with change, check and rollback for every step, a Rollout section and Success measures.
🌍Where it's used
- Production changes in regulated industries need a written rollback plan before approval.
- Site reliability teams set error-budget rules that pause rollouts automatically.
- Release managers use "go/no-go" checks at each stage.
📝Case scenario
A bank moved card payments to a new processor at 20%. The plan said to roll back if declines rose by more than 0.5 points. Declines rose by 1.2 points on the first afternoon; the team set the flag to 0 in two minutes, found a currency-code bug, and resumed the next week.
🖱️Try it
Write a three-step plan for a change in a project of yours, with change, check and rollback for each. Success: someone else could carry out the rollback without asking you.
⚠️Common mistakes
- Rollback: none. Sign: a step you can't undo. Fix: split it until each part can be undone.
- Measures chosen afterwards. Sign: "it seems fine". Fix: numbers and turn-back rules before the rollout.
- Forgetting the clean-up. Sign: no step to remove the old code. Fix: a dated final step.
🛠️For your project
Project 2's test 10 checks the plan's sections, at least five steps with change, check and rollback, at least three rollout stages ending at 100%, and success measures with numbers.
✅Quick check
What three things does every step of the plan need?
Show the answer
What changes, how you'll check it, and how to undo it.
Why decide turn-back rules before the rollout?
Show the answer
So the decision is made calmly, not under pressure when things go wrong.