Changing agencies or developers is common. The hard part is rarely the code. It is finding out which accounts exist, who controls them and what breaks if one of them is switched off.
Done in the right order, a handover is calm and the live site keeps running. Done in a rush, it can leave you locked out of your own domain, hosting or app store listing.
Start with an inventory
Before asking for anything, write down every service the product might use. Most businesses are surprised by how long the list is.
Domain registrar and DNS provider.
Hosting, servers and any content delivery network.
Code repository, such as GitHub, GitLab or Bitbucket.
Database, file storage and backups.
Email sending, business inboxes and newsletter tools.
Payment provider, analytics, error tracking, and any map or AI services.
Apple Developer and Google Play accounts, if you have apps.
For each one, note who owns the account, whose card pays for it and who can sign in. My free tech stack detector and domain lookup can reveal services you did not know about from the outside: hosting, CDN, email provider, frameworks and third-party scripts.
Ask for ownership, not just access
Being invited as a user is not the same as owning the account. Ask for each account to be transferred to your business, or for your business to become its owner and the previous team to be removed. Code repositories can usually be moved between accounts; GitHub’s guide to transferring a repository shows how, and other hosts have similar options.
Check your contract for who owns the code and designs. If it is unclear, settle it in writing before the relationship ends. This is not legal advice; if anything is disputed, speak to a lawyer.
What to request
Full source code with its history, in a repository we own: …
Ownership of the domain, hosting, database and service accounts: …
A list of environment variables and which service each one belongs to: …
A recent database export and a copy of uploaded files: …
Deployment steps and any scheduled jobs or scripts: …
Known problems and unfinished work: …
You do not need the secret values sent by email. Once you own the accounts, new keys can be created and the old ones retired.
Change things in a safe order
Take your own backup of the database and files before anything moves.
Move ownership of the domain and DNS first, without changing the records.
Move the repository and hosting next, and confirm the site still deploys.
Rotate passwords, API keys and tokens once the previous team no longer needs them.
Remove the previous team’s access only after everything has been checked.
Changing DNS, hosting and code on the same day makes it hard to tell what caused a problem. One step at a time is slower and much safer.
Check what you are taking over
Once you have the code, run a whole-site audit to find broken pages, missing titles and slow responses on the live site, so you know the starting point. A developer review of the code itself then shows what can stay, what needs attention and what was never finished.
Getting help with the handover
If you are changing developers, send me what you know about the product and who currently controls it. I can help plan the order of the handover, take over the code safely and keep the site running while it happens. My guide to working with a new developer on an existing project covers what comes after.