What a good website handover includes

Most websites change hands at some point: you move to a new developer, bring the work in-house, or the agency that built your site closes. A handover is when everything that runs the site passes to you, or to whoever looks after it next.

A good handover is uneventful. Nothing is rebuilt, the site keeps running at its usual address, and at the end every account is in the owner's name, with the owner deciding who else has access. If you haven't hired anyone yet, who owns your website covers what to check before you sign.

What should change hands

The domain

First, check who is listed as the domain's registrant, its holder of record: it should be you or your business. If the domain sits in your own registrar account, you just remove the developer's access. If it's in theirs, ask the registrar whether it can move the domain into an account of yours, or transfer it to a registrar you choose. If the DNS is managed elsewhere, that account needs handing over too.

A transfer between registrars follows ICANN's transfer rules. You unlock the domain at the current registrar, ask it for the authorization code (also called an AuthInfo or transfer code), which it must provide within five calendar days, and start the transfer at the new registrar. Under the current policy, a registrar can refuse a transfer within 60 days of a domain's registration or its last transfer. Changing the registrant's name, organization or email address also locks the domain against moving to another registrar for 60 days, unless the registrar offers an opt-out and you take it beforehand. ICANN is revising these rules, so check the current policy when you plan a move.

The hosting or cloud account

The account the site runs in should be in your name and paid for by you. Then the handover is only about access. A Firebase project is a Google Cloud project, whose access is managed on the IAM page of the Google Cloud console. Have the developer grant you the Owner role, which can manage everyone else's access and set up billing. For someone outside the developer's organization, Google allows this only through the console (Google's roles overview). Remove the developer's own roles there last.

If the project is linked to the developer's billing account, link it to one in your name. Google says the switch shouldn't interrupt service, and earlier usage stays on the old bill (changing a project's billing account). And if the project sits inside the developer's own Google Cloud organization, anyone with roles at that organization's level keeps access until the project is migrated out.

The code repository

The code should end up in a GitHub account or organization you control, with its full history. A repository transfer moves the repository itself, not a copy: issues, pull requests, wiki, stars and watchers go with it, the commit history is preserved, and links to the old address redirect to the new one.

The person transferring needs administrator access, and the receiving account can't already have a repository with the same name. A transfer to a personal account must be accepted within one day; one to an organization needs permission to create repositories there. Afterwards, GitHub adds the original owner as a collaborator, and webhooks, secrets and deploy keys stay attached, so review them and remove anything that belongs to the old developer.

The deployment connection

If the host builds the site straight from the repository, that link has to follow the code. On Firebase App Hosting, all the backends (deployed sites or apps) in a Firebase project share one linked GitHub account or organization. So when the repository moves to a different GitHub account, the project's GitHub connection is switched to that account and the site is reconnected to the repository there. Firebase's App Hosting FAQ covers both steps. Plan it as a short cutover, and check afterwards that a small change deploys.

Secrets and API keys

Sites hold keys for the services they use: payment and email-sending API keys, service account keys, webhook signing secrets. Anyone who has seen one can use it until it's revoked. Once you have control, issue new keys, update the site, then revoke the old ones. Keep keys in the host's secret storage, never in the code or an email thread.

Payment, email, analytics and search accounts

Everywhere else, the email-sending service included, the account should be in your business's name with you as owner or administrator, and the old developer removed once you're in. Some services have steps of their own:

• Stripe. If the developer opened the account, its owner can transfer ownership to a team member with the Administrator or Super Administrator role, so you join the team first. If the owner is no longer available, you can request a transfer through Stripe Support and verify your identity and your relationship with the business.
• Google Search Console. Become a verified owner yourself first: if every verified owner is removed, everyone else loses access after a grace period. When you remove the developer, also delete their verification tokens (an HTML file, meta tag or DNS record), or they can verify again (Google's instructions).
• Google Analytics. Take the Administrator role at the account level, the only level where users can be deleted (Google's instructions).

Documentation and backups

Ask for a short written note: how the site is deployed, where each piece lives, what it depends on, and anything unusual. Ask too for a recent backup or export of the site's data and files, kept somewhere you control. If the data already sits in an account of yours, it doesn't need to move.

The order to do it in

1. Take an inventory. Every account the site uses, who holds it, and whose card pays for it.
2. Add the new owner everywhere. Confirm you can sign in to each account before anyone loses access.
3. Transfer the code and reconnect deployment. One short, planned cutover.
4. Move the domain, if needed. Allow for the registrar's steps and any 60-day lock.
5. Rotate secrets. New keys in, old keys revoked.
6. Remove the old developer's access last. Everywhere on the inventory, including repository collaborators and Search Console tokens.
7. Check that everything works. Load the site, try its forms, put a small order through if you sell online, and confirm that a small change deploys.

Warning signs

• Access that never arrives. A developer who won't add you to your own accounts, or keeps putting it off.
• A platform with no export. If the platform your site is built on can't export it, moving it means rebuilding it.
• A fee to release your own domain. A registrar's transfer price is normal. A developer charging to let go of a domain that should already be yours is not.

How we hand over at Titus Apps

Our sites are set up so that most of this is settled from the start. Each runs in a Google Cloud project on the customer's own billing account from day one, with us invited in as administrator, and the domain and any Stripe or email-sending accounts are in the customer's name. So when a customer leaves, the site keeps running where it is, and their data stays in their project.

The one thing that moves is the code. It lives in our GitHub organization while we manage the site, the customer can read it from day one, and it moves to their GitHub, free, whenever they ask once the build is paid for. When a customer leaves, we transfer the repository with its full history, reconnect the site to it in a short, planned cutover scheduled with them, remove our access to their Google Cloud project and any account they invited us to, and hand over any credentials we hold. There's no fee for the handover. Hosting & ownership explains the whole arrangement.