The short version: if the system is still running, you still have time. What actually removes your options is not bad code, it is losing access. So the first thing to do is not to look for someone to take it over, it is to check whether the domain and the hosting account are in your name. The technical questions come after that.
I have taken over more than a dozen systems built by someone else. The calls sound the same: the vendor has stopped replying, the one engineer who understood it has left, and nobody dares change a field on a form.
And almost every time, the client has no technical material of any kind. No source code, no architecture diagram, no deployment notes. Sometimes the hosting provider has to be worked out from a bill. All that is left is a site that still runs and a contact who does not answer.
If that is where you are, this is written for you.
What should I do first?
Not get quotes. Work out what is still in your name, in this order:
- The domain. Who it is registered to, and whether you hold the password to the registrar account. This is the worst one to lose, because recovering it is an ownership transfer process, not a technical problem.
- The hosting or cloud account. Who opened the AWS, GCP or hosting account. If the vendor opened it under their own account, what you bought is a rented house.
- The code. Where it is, and whether you can read it. Plenty of people find out at this step that they were never given it.
- The data. Whether backups run is one question. Whether anyone has ever restored one is a different question. A backup nobody has restored is not a backup.
With the first two in your name you have full room to negotiate, and you can hire anyone. If one is missing, deal with that before you deal with finding a developer.
We have nothing. Is it hopeless?
No. Having no technical material is the normal case, not the exception.
The code and the database are the most complete documentation there is, the architecture can be reconstructed from them, and filling the documentation back in is part of the handover rather than a precondition for it.
What actually stops a takeover is not being able to get the code, which is a very different problem from not being able to read it.
Are you going to tell us to rewrite it?
No. Most systems can be taken over and maintained as they are, or improved in stages.
There is really only one situation where I recommend a rebuild: the system is hard to maintain and the code is too old. Both have to be true.
You can judge “hard to maintain” yourself:
- A small change, like adding one field to a form, touches many files
- Every fix breaks something else, so you fix one thing and another appears
- The previous vendor visibly slowed down towards the end
“Too old” is about whether the framework or language version still receives security updates, and you do not have to guess: the vendors publish it. PHP’s maintenance status is on php.net Supported Versions, Node.js is on Previous Releases, and most other frameworks are on endoflife.date.
Sitting on a version nobody maintains means vulnerabilities only accumulate. OWASP lists this as a top-ten risk in its own right (A06: Vulnerable and Outdated Components), and it gets more expensive the longer it is left, because there are more versions to cross.
The other way round: “the code is ugly” is not a reason to rebuild. An ugly system with a clear structure is much cheaper to maintain than it looks. Whoever tells you to rewrite may not be saying it because the system needs rewriting.
What does it cost to look at it, and how long?
From US$950 depending on the size of the system, with an answer within a week. If you go ahead, that fee is credited in full.
This is not selling you a report. It is me going through the code, the architecture, the hosting and the security so I can tell whether the system can be taken on as it is or should be rebuilt. Any price quoted before looking is a guess, so we do not quote one.
Afterwards you know three things: where the risks are, what taking it over costs, and whether it should be taken over at all. Even if you decide to hire someone else, the conclusions are yours.
How long until it is running normally?
About a week to look at it, then the handover: getting access to everything, filling the documentation back in, and setting up a deployment that can be run repeatably.
How long that takes usually depends on how fast the access comes back, not on the technology. Projects where the previous vendor is still reachable go much faster.
After the handover it moves into normal maintenance, with the same team doing the monitoring, the fixes and the changes.
What does the ongoing maintenance cost?
Monthly maintenance from US$220, depending on the size of the system and how fast you need us to respond, agreed after we have looked at it.
If work keeps arriving rather than being occasional bug fixes, a dedicated team usually costs less than a monthly plan, and maintenance is included in it.
If we switch vendors, will this just happen again?
No guarantees, but three things prevent it, and they cost nothing at signing:
- Open the accounts in your name. Cloud, domain and code repository created under your account, with the vendor given collaborator access only.
- Put the deliverables in the contract. Source code, database and deployment documentation, not just the words “system goes live”.
- Ask who maintains it after launch, before you sign. Most disputes do not happen during development, they happen after the warranty ends and nobody picks it up.
Writing those into a contract is free. The cost of fixing it afterwards is everything this article is about.