List what the software depends on, and who holds each account
Every system relies on a set of accounts. Start by finding each one:
- The domain name and the registrar it is held with.
- The hosting or cloud account where the system runs.
- The source code repository.
- The database and its backups.
- Connected services such as payments, email sending, text messages, maps and analytics.
- App store accounts, if there is a mobile app.
For each one, note whose email address it is registered under, whose card pays for it and who knows the password. Anything registered to the developer personally needs to move to an account the business controls.
Transfer ownership while the developer can still be reached
A password gives access. Ownership decides who can recover the account, change the billing or close it. Ask for the domain to be transferred into the business's registrar account, the repository into an organisation the business owns, and the business to be made owner or administrator on the hosting and each connected service.
Most developers cooperate when the request is early, specific and polite. It is also the moment to check the contract. If it does not say who owns the code, ask for written confirmation, and take legal advice if the answer is unclear.
Get the handover in writing while the knowledge exists
The details that matter most live in the developer's head. A short document and a recorded call or two are enough if they cover:
- How a change is released to the live system.
- Where the system is hosted and how the servers are set up.
- Scheduled jobs that run in the background, and what happens if one fails.
- Manual tasks done each month or year, such as renewals and clean-ups.
- Known weak spots and unfinished work.
- A full list of credentials, handed over through a password manager.
Change the keys once the handover is complete
When the business holds every account, change the passwords and access keys, and remove the former developer's access to the servers, the repository and each service. This is routine whenever someone with access leaves, in the same way a business collects office keys. It also protects the developer, who can no longer be held responsible for what happens next.
When the developer cannot be reached
Accounts can often be recovered without them. Registrars and hosting providers have recovery procedures for a business that can prove its identity and show it has been paying the bills. Keep paying every invoice in the meantime, so nothing is switched off.
For most web applications, access to the server is enough to copy the code and the database from the live system. A mobile app is harder, because the published app does not contain its editable source.
Without the server or the source code, the remaining route is to rebuild, using the live system as the reference and exporting the data through its own screens. It costs more, and the business ends up owning everything.
A new developer starts by making the system safe to change
Before any new feature, a developer taking over reads the code, gets the system running on a separate copy, restores a backup to prove it works, and checks which versions need security updates. They set up a release process they can repeat and write down what they learn.
Expect this takeover phase to be scoped and paid for as its own piece of work. After it, changes can be made and reversed safely, and estimates for new work become reliable.
Arrangements that prevent a repeat
A few arrangements keep the business in control, whoever does the work:
- Register every account to an email address the business owns.
- Keep credentials in a password manager the business controls.
- Hold the code in a repository the business owns, with the developer as a member.
- Maintain a one-page description of the system and update it when something changes.
- Test backups by restoring them.
- Make sure more than one person, or a company, can release a change.
Most inherited systems are in better shape than their owners fear
Once access and knowledge are back with the business, the picture usually improves quickly. The system was working before the developer left, and it still is.
If your developer has moved on, or is about to, tell us what the system does and what you have access to today. We will reply in writing with the first steps we would take.