Many companies run on a custom application built five, ten or fifteen years ago. Before deciding what to do with it, you need to know where it stands.
The warning signs
- Security updates are no longer done. The language, framework or server are no longer maintained by their publishers.
- Nobody knows the code. There is no documentation, or it dates from day one.
- Every small request becomes a project. Adding a field takes weeks.
- Hosting is a black box. You don't know exactly where the application runs or who has access.
- You work around the tool. A spreadsheet or a notebook fills in what the application can no longer do.
Three options
- Take over and stabilise, when the application still does the job but nobody masters it. The risk: postponing an update that has become urgent.
- Upgrade in steps, when the code is sound but the technology is no longer maintained. The risk: trying to update everything at once.
- Rebuild, when the business has changed and the tool no longer fits. The risk: rebuilding the old one's flaws identically.
In most cases the answer isn't “throw it all away”. You start by taking over: understanding the code, documenting, securing. Then you decide with full knowledge.
How a take-over works
- An audit: reading the code, listing the versions in use, spotting security risks.
- A backup and a test environment: production is never touched directly.
- Updates in small tested steps, rather than one big leap.
- Documentation that lets any developer pick up from there.
AI agents change the game here. Reading and documenting unknown code, writing the missing tests, migrating hundreds of files from one version to the next: what took weeks now takes days, under human control.
And then?
A taken-over application should no longer age in silence. A maintenance subscription keeps it updated, monitored and documented. You own your tool again: the source code is handed over and can be taken over by another developer.