Somewhere in your building, or in a cloud account nobody logs into, an application is running that nobody dares touch. The developer left, the documentation is a README from 2016, and the machine it lives on has an uptime everyone brags about, because nobody is sure it would come back if rebooted.
If that system matters to your business, here is the path we walk with clients, in order.
Step one: stop the bleeding, change nothing
Before improving anything, remove the ways it can be lost. Get the code into version control if it is not. Get a tested backup of the database and the server configuration. Document how to restart it. None of this changes behavior; all of it converts “catastrophe” into “bad afternoon.”
Step two: write down what it actually does
The system’s real specification lives in its code, including the parts that will surprise everyone. We read it, trace the data, and interview the people who use it, then produce a plain-language document of what it does and why. This is where AI tooling has changed the economics: mapping an unfamiliar codebase now takes days instead of weeks, which makes rescue projects viable at a price that used to kill them.
This document is valuable on its own. Even if you never modernize, you now know what you own.
Step three: triage, honestly
With the map in hand, the options get concrete. In rough order of cost:
- Stabilize and keep. The system is sound; it just needed a bus-factor fix and a maintenance arrangement.
- Contain and connect. The core is fine but isolated, so wrap it in an API so modern tools can talk to it without touching its internals.
- Replace incrementally. Migrate one module at a time, old and new running side by side, comparing outputs until the new one has earned trust.
- Rewrite. The last resort, chosen only when the platform itself is dead. Even then, the document from step two is what keeps the rewrite from losing a decade of business rules.
The one thing not to do
Do not commission a ground-up rewrite from scratch on day one, before anyone has documented the current system. It feels decisive. In practice it means a long silence with nothing to show, a terrifying cutover, and the slow rediscovery, in production, of every edge case the old system handled quietly for years.
Old software that still runs is not a failure. It is an asset with deferred maintenance. Treat it that way and the path forward is rarely as expensive as feared.
