It usually starts quietly. Emails take a week instead of a day. A small fix that used to take an afternoon sits for a month. Then a phone number stops working, or a contract is not renewed, or a company simply stops answering. Meanwhile the site is still running, still taking orders or applications, and still one failed deployment away from being your emergency.
This happens often enough that it deserves a practical checklist rather than sympathy. If the agency that built your system has gone quiet, here is how to establish what you actually control, get the system back under your authority, and make it maintainable again.
First: take inventory before you take action
The instinct is to find a new developer immediately. Do the inventory first, because what you own determines which options exist, and a new supplier's first question will be this list anyway.
Work through five things, in this order.
- The domain name. Who is the registrant on the WHOIS record: your organisation, or the agency? Do you have login access to the registrar account? This is first because it is the only item on the list that cannot be rebuilt.
- DNS control. Where are the nameservers pointed, and can you edit the records? Domain ownership without DNS control is only half of it.
- Hosting. Whose account is the server or hosting plan in, and whose card is paying for it? If it is the agency's, you are one unpaid invoice from an outage you cannot fix.
- The source code. Is there a repository you can reach? Do you have a copy anywhere other than the running server?
- The database and its backups. Are backups being taken, where do they go, and has anyone ever restored one to check?
Write down the answers honestly, including the ones that are "I don't know". The pattern of gaps tells you how urgent this is. Missing documentation is a nuisance. Missing registrar access is an emergency.
What if you do not have the source code?
This is the common case and it is not hopeless, but be clear about what you are dealing with.
If the system is running on a server you control, the code is on that server. For a PHP application such as Drupal or WordPress, what is deployed is the source: you can copy it down, put it in a repository, and work from it. What you may be missing is the build tooling, the deployment configuration, the commit history and any documentation, which makes the code harder to work with but does not make it unusable.
If the system is running on the agency's infrastructure and you cannot get in, your options narrow sharply. Try the contract first: many development agreements assign ownership of the delivered work to the client even when the practice around handover was sloppy. A letter from a solicitor citing that clause resolves this more often than people expect.
If the code is genuinely unrecoverable, you are looking at a rebuild, and the single most useful thing you can preserve is the data. A database export, or even a full crawl of the public site, keeps your content and history alive through a rebuild. Do that early, while you still have whatever access you have.
Secure the four things that cannot wait
Before any development work starts, get these under your own name.
- The registrar account. Transfer the domain into an account your organisation owns, with billing on your card and recovery to an address your organisation controls.
- The hosting account. Either move it into your name or migrate to hosting you control. Renewals paid by an absent third party are a scheduled outage.
- Every administrative credential. Rotate them. Site admin accounts, server access, the certificate authority, the mail service, the payment gateway, the analytics property. Disable accounts belonging to people who no longer work on the system.
- A backup you have personally verified. Not "backups are configured". A file you have downloaded, and ideally restored somewhere, so you know it is complete.
Until those four are done, everything else is building on ground you do not own.
What happens in a takeover, technically?
When we take over a system someone else built, the first phase is not development. It is an audit, and it produces the thing that was missing: a written picture of what you have.
Typically that means establishing which platform version is running and how far behind it is, what custom code exists and what it does, which contributed modules are in use and whether any have been modified in place, what integrations the system depends on, where the security exposure is, and what is undocumented enough to be dangerous.
The output is an honest assessment, including the parts that are bad news. Sometimes the answer is that the system is in reasonable shape and needs updating and documenting. Sometimes it is that a component was built in a way that will not survive the next platform upgrade and should be replaced on a planned schedule rather than in an emergency. Both of those are more useful than an optimistic quote.
This is the work described under support and maintenance, and it deliberately covers systems we did not build. Where the system is on an end-of-life Drupal version, the route forward is usually a Drupal migration rather than an indefinite patching exercise.
How do you avoid being here again?
The reason this situation is so common is that the arrangements that prevent it are all made at the start, when nobody is thinking about the end. Four of them do most of the work.
Own the code from day one, not at the end. "You will own the code on final payment" is a clause that only helps if the handover actually happens. Ownership from the start, with the repository in your own account throughout, means there is no handover event to miss. Every engagement we take on works this way, for exactly this reason: the full argument is here.
Hold your own domain, DNS and hosting accounts. Let your supplier have access to them. Do not let them have ownership of them. This costs nothing and removes the worst failure mode entirely.
Insist that documentation is a deliverable. Not a wiki that the supplier maintains on their own infrastructure. Documentation in the repository, written for a developer who has never met the team that wrote it. If it is not written for a stranger, it is written for people who may not be there.
Ask what happens if the supplier is unavailable. A supplier who has thought about this will have an answer. One who has not will change the subject. That reaction is the useful part of the question.
A note on blame
Agencies disappear for many reasons, and most of them are not villainous. Small studios close. Key people leave and take the only working knowledge of a codebase with them. A company pivots to a different market and quietly stops supporting older work. Sometimes a business simply fails.
The point of the arrangements above is not to guard against bad actors. It is that the ordinary lifecycle of small companies should not be able to take your system with it. If your supplier remains excellent for a decade, you will never notice that you owned the domain and the code all along. If they do not, that is the difference between an inconvenience and a rebuild.
If you need a hand with this
We have picked up systems built by other people, and we work on systems we did not build. If you are mid-way through the inventory above and stuck on a specific item, or you want an audit before you decide whether to repair or rebuild, tell us what you are looking at. Support and maintenance describes the ongoing arrangement, and our pricing page sets out the bands so you can see roughly where this kind of work lands before you speak to anyone.