Every organisation has one — the service that predates everyone currently employed, that nobody volunteers to touch, and that quietly handles something important. It is slow, it is undocumented, and it works.
The temptation is always to rewrite it. Sometimes that is right. This run is about the decisions that determine which case you are in, and about the fact that you usually cannot tell from the outside.
No trivia and no right answers — a narrative run about deciding the fate of a system nobody understands.
Four archetypes, four starting hands. Your pick sets the stats you begin with — not the ones you end with.
Seven decisions, each one nudging skill, wealth, reputation, and wellbeing. No take-backs.
Your choices resolve into one of six outcomes — and an honest read on what that pattern costs.
Each archetype begins with a different balance of strengths. Your pick sets the stats you start with — not the ones you end with.
Below is the whole run — every chapter, every option, and where each one leads. Press Play this run above to take it as a game instead, with stats that move as you choose and an ending scored from how you played.
A billing component, eleven years old, four thousand lines, no tests, written by someone who left in 2019. It has failed twice in that time, both times catastrophically.
You have been asked to add one field to it. The estimate you give will set expectations for everything after.
Leadership will fund a rewrite if you can justify it. What they want is a delivery date and a benefit; what you have is an intuition that this thing is dangerous.
Intuition does not survive a planning meeting.
Four weeks in. You find a branch that rounds certain amounts in a way that is plainly a bug — except finance has been reconciling against it for years, and downstream reports depend on the wrong number.
It is not a bug any more. It is a specification.
Month three of an estimated four. About sixty percent done, and the remaining forty is the part nobody understood at the start — which is why it is still there.
Running both systems in parallel is costing real money, and the question is being asked.
The new path is ready. The old one still handles everything. Somebody has to decide how traffic moves, and the calendar says the quarter ends on Friday.
A clean switch is one line of config and no way back.
The new system has been carrying everything for six weeks. The old code is still in the repository, still deployed, still costing money — and nobody wants to be the one who deletes it.
Unremoved legacy is how you end up maintaining two systems permanently.
The replacement is now the thing people are slightly wary of. It has tests, documentation and one odd rounding rule with a comment explaining exactly why.
Someone proposes rewriting a different old service. They ask what you learned.
No ending is the “best” one — only the one your decisions earned.
You replaced it without breaking anyone.
A week of reading before an estimate, incremental strangling rather than a rewrite, bug-for-bug compatibility on the behaviour finance depended on, and a dual-run before any traffic moved. Nothing about it was fast. It is the only version of this that reliably finishes.
You made the case in a language that funded it.
Incident hours, lead time and near misses instead of arguments about code quality. You reported the real position at the halfway point and wrote the decision record before deleting anything. The technical work was ordinary; being believed was the hard part, and you solved it with numbers.
You cut it down to what was actually used.
Telemetry over assumption, remaining scope trimmed to live code paths, the old infrastructure torn down once nothing called it. You replaced less than you set out to and finished, which is a strictly better outcome than a complete rewrite that stalls at eighty percent.
You built the new one. The old one is still there.
The replacement works and the original is still deployed, still costing money, still the thing nobody will delete. You have added capability and doubled the surface area. In two years someone will find the old service and be exactly as afraid of it as you were in Chapter 01.
It was ready on Friday. It was not ready.
A rewrite proposed before the code was read, a rounding bug corrected on the way through, a halfway report that said on track, and a full cutover to hit a quarter boundary. Every individual decision had a defensible reason. Together they are the standard anatomy of a failed migration.
Replaced, documented, deleted, survivable.
Read before estimating, justified in business terms, compatible where it mattered, cut to what was used, moved gradually, and finished by removing the original. No part of it makes a good conference talk. It is what the successful version actually looks like from the inside.
The service, estimate, migration and outcomes in this run are fictional. It does not evaluate an architecture, calculate a rewrite budget, establish a security risk or recommend a migration strategy. A positive ending is not evidence that a rewrite is warranted; a negative ending is not evidence that a legacy system should be left untouched.
The useful question is what is known and unknown about the current behaviour. A system can have source code, logs, consumers, operational runbooks, contracts and unwritten workarounds that describe different parts of its real interface. Reading code alone is not enough; neither is a stakeholder's summary. The scenario uses undocumented behaviour to make that point, not to say that every existing behaviour must be preserved. Some behaviour is harmful or insecure and requires change. The change should be named, assessed and communicated rather than discovered accidentally during cutover.
The NIST SSDF and CISA sources provide secure-development principles. They do not prescribe a particular strangler pattern, parallel run, test suite or release sequence for this fictional service. Real systems have constraints around data, privacy, availability, procurement, customers and regulation that may make a technically elegant plan unsafe or impossible. Follow the organisation's engineering, change-management and security processes.
The deletion chapter is similarly a prompt rather than a rule. Removing an old path can reduce operational burden, but only after dependencies and rollback needs have been understood. Keeping an old system temporarily may be the safer decision; keeping it indefinitely without ownership may create a different risk. The game cannot identify the correct date.
Use this run to create an evidence list: known consumers, observed inputs and outputs, critical behaviours to test, compatibility changes to approve, rollback conditions, and a named owner for retiring the old path. That turns the story into a discovery exercise without pretending that a game has designed the migration. The references are general education, not engineering, legal or financial advice.
The alternative to a full rewrite or indefinite preservation may be one bounded change at a well-observed seam: add characterisation tests, improve telemetry, move a single consumer, or replace one responsibility while both paths have named owners. That approach is not inherently safer; parallel paths can increase cost and complexity, and some systems have no clean seam. The test is whether the smaller change produces evidence and a reversible boundary in the real architecture, not whether it matches a popular migration pattern.
Pick one bounded behaviour and document it from evidence: inputs, outputs, known consumers, source or monitoring evidence, tests that would detect a change, and the owner who can approve a difference. Mark assumptions separately from observations. Add a rollback condition before proposing a cutover. The exercise does not estimate a rewrite or certify compatibility; it gives a team a smaller, reviewable unit of knowledge than the claim that a whole legacy system is understood.
Ask which behaviours have direct evidence, which consumers depend on them, what change needs explicit approval, and how a failed cutover would be detected and reversed. Ask who owns the old and new paths during the transition. The answers may support an incremental change, a replacement or further discovery. They do not turn a generic scenario into a complete architecture review or a security assessment.
Use the authored links below to examine the main trade-off from another angle.
Two failure modes account for most legacy rewrites that go badly, and both happen before any code is written. The first is estimating from the outside — proposing a replacement for a system nobody has read, which reliably produces a number that is wrong by a multiple rather than a margin. The second is treating undocumented behaviour as a defect. When something has been in production for a decade, other systems and other teams have built on its output, including the parts that are wrong. Compatibility comes first; correctness is a separate, later, negotiated change.
The third pattern is quieter: a migration that is never finished. If the original system is still deployed, the rewrite has not reduced anything — it has added a second thing to maintain. Deleting the old path is not cleanup after the project. It is the last step of the project.
This is a narrative simulation for general professional education. It is not engineering, legal, or financial advice, and the stat effects are storytelling devices rather than predictions. Migration, change-management and deployment practices vary by organisation — follow your own.