Somewhere in your building is a system with a name staff say the way sailors mention a reef. It is twenty years old, it runs something essential, the vendor’s consultants have become de-facto members of your organisation, and the file that explains its logic retired with the person who wrote it. Everyone agrees it must go. It has survived three plans to make it go.
It survives because both standard exits are traps. The big-bang replacement stakes years of budget on one cut-over night, and the graveyard of such nights is well populated: scope balloons, data migration humbles everyone, and the new system arrives just in time to be the next legacy. The eternal-maintenance path is quieter but bleeds forever — integration by integration, invoice by invoice, risk compounding annually. One path is a cliff, the other a leak.
The strangler pattern, institutionalised
Software engineering solved this locally decades ago with the strangler fig: grow the new system around the old, route traffic to it path by path, and let the old one atrophy safely. What institutions lacked was a way to do this at the speed of policy rather than the speed of custom development. A governed platform changes the arithmetic: when a replacement service is a fourteen-day configuration cycle instead of an eighteen-month project, strangling stops being a metaphor and becomes a schedule.
The exit looks like this. Choose one service the legacy system performs — one permit type, one request flow, one register. Configure it on the governed platform, integrate read-only against legacy data through governed APIs, and go live in parallel. Move intake. Watch the numbers for a cycle. Then cut the legacy path for that one service and mark one line item on the retirement ledger closed. Repeat, at whatever cadence your institution can absorb.
What makes it stick
Three disciplines separate a real exit from a slow accumulation of a second estate. First, an explicit retirement ledger — every service on the old system, named, owned, dated; progress reviewed like revenue. Second, data leaves by service, not by big-bang migration: each configured service takes ownership of exactly the records it needs, validated in production, so the terrifying “migration weekend” dissolves into small, reversible steps. Third, the configuring is done by your certified team — because an exit executed by a new set of external consultants is not an exit; it is a change of landlord.
The ninety-day first service is not a pilot in the decorative sense. It is the proof that changes the politics: leadership sees a queue disappear, finance sees a maintenance line shrink, staff see that the reef can be sailed. Momentum, in institutions, is compounded evidence.
Year seven, again
There is a final test for whichever platform hosts your exit, and readers of the year-seven question already know it: make sure the staircase leads somewhere you own. Leaving one vendor’s legacy for another vendor’s subscription rebuilds the same trap with better fonts. The exit is only real if the destination — platform, services, data, definitions — is a state asset, extensible by your team, on infrastructure you choose.
The system nobody dares to touch will not fall to courage. It falls to cadence: one governed service every cycle, one ledger line at a time, until the reef is a story the veterans tell.