How businesses end up here
It rarely starts as a crisis. A freelancer built the system years ago and moved on. An agency finished the project and the retainer lapsed. The one developer who understood it left, and their replacement never quite did. Meanwhile the software kept running, the business built its habits around it, and nobody touched anything that worked.
Then something needs to change, or something breaks, and it turns out nobody can safely do either. Sometimes the build was left half-finished. Sometimes it is finished, but on a version of everything that stopped receiving security updates some time ago.
The first job is finding out what you have
Before anyone writes a line of code, we establish the basics. It is surprising how often they are not known:
- Where the code is, and whether the copy in the repository is actually what is running
- Who holds the accounts: the hosting, the domain, the database, the email service, the payment provider. Too often at least one is in the previous developer's personal name
- Whether there are backups, and whether anyone has ever restored one
- How it gets deployed, which in a rescue is frequently "by hand, from one laptop, in a particular order"
- What it depends on, and how far out of date those dependencies are
If access to something is missing, getting it back comes before anything else. The who owns the code guide covers why, and what to ask for.
Stabilise before improving
The temptation with inherited software is to start fixing the parts that are annoying. That comes later. The first phase makes the system safe to work on:
- Backups that run and a restore that has been tested
- Deployment moved from memory into a pipeline, so a release is repeatable
- The tests that should have existed, starting with the parts where being wrong costs money or embarrasses you in front of a customer
- The worst of the security and dependency problems dealt with
- Written notes on how it works, for whoever touches it next
At the end of this you have the same system, doing the same things, but one that can be changed without holding your breath.
Modernise in place, not from scratch
Rewriting everything from zero is the most expensive option and the riskiest. The old system encodes years of decisions and exceptions that nobody wrote down, and a rewrite rediscovers them one at a time, in production. So starting again is the last resort, not the opening position.
Most of the time the right approach is to replace the system in pieces, each one live before the next begins. For a construction and M&E group, one piece of the work was rewriting a legacy estimating workflow onto the web, as one application among eight on their platform.
Sometimes a clean replacement really is the right call. For an accountancy practice whose system had reached the end of its useful life and could not be extended, we built Fortium to take its place. The brief was not to rebuild the old system; it was to build what the practice actually needed now, and to make sure the practice would never be trapped by one system again.
What we are honest about
We will tell you what we find, including when it is worse than you hoped and when it is better. Sometimes the code is fine and the only real problem was that nobody could deploy it. Sometimes the kindest advice is to stop spending on the old system and put the money into a replacement.
Pricing follows the same rule as all our work: we look before we quote, then fix the price off a written scope. Engagements start from £4,000. Everything we set up or recover goes into your name as we go, so the next time a developer leaves, you are not starting from here again. If that sounds like your situation, describe it to us.