The handover checklist: what you should own when a project ends

The most expensive moment in a software project is often not the build. It's the day, months later, when you want to change something and discover you don't actually control it.

The domain is registered in a former developer's personal account. The hosting is billed to the agency's card. Nobody has the admin password for the analytics. The code exists, somewhere, but not anywhere you can reach.

None of this usually comes from bad intent. It comes from convenience. During a build, it's faster for the team doing the work to set things up in their own accounts. If nobody plans the handover, it never happens.

Here's the checklist I'd want any buyer to work through before paying the final invoice. It works whether the project was built by an agency, a freelancer or an internal team that's moving on.

The rule behind the checklist

You should own the accounts. Your partners should have access to them. Not the other way round.

Access can be given and taken away in minutes. Ownership, once it sits with someone else, can take weeks to recover, if you can recover it at all.

1. Code

• The source code is in a repository owned by your organisation, not a personal account. Your partners are added as members.
• You can see the full history, not just a zip file of the final version.
• Any private packages, plugins or themes the project depends on are either in your account or clearly listed with their licences.
• Someone on your side has successfully downloaded the code and confirmed it's complete.

2. Domains and DNS

• The domain is registered in your organisation's name, in an account you control, with a contact email you'll still have in five years.
• You know where DNS is managed and have admin access there.
• Auto-renew is switched on, with a card your business pays.

Losing a domain because a renewal reminder went to someone's old inbox is one of the most avoidable disasters in business.

3. Hosting, cloud and paid services

• Hosting and cloud accounts are in your name and billed to you.
• You have a list of every paid service the project uses (email sending, maps, payments, search, AI APIs, storage), who owns each account, and what it costs each month.
• Anything still billed through your partner is written down, with a date to move it across.

4. Credentials and secrets

• You have an owner-level login for every account above, stored in your organisation's password manager, not a spreadsheet or a chat thread.
• API keys and other secrets used by the application are documented: what each one is for and where it's stored.
• After handover, rotate them. Anyone who had them during the build shouldn't still have working copies. Agree this with your partner in advance so it's routine, not an accusation.
• Two-factor authentication on key accounts is tied to people in your organisation, not to a developer's phone.

5. Admin access to the product itself

• You have the top-level admin account in the application, CMS or store.
• Partner and developer accounts are separate, named logins, so they can be removed individually later.
• You know how to add and remove users yourself.

6. Data and analytics

• Analytics, tag manager, search console and advertising accounts are owned by your organisation, with partners added as users.
• You know where backups are, how often they run, and you've seen one restored at least once.
• If the project collects personal data, you know where it's stored and who can access it.

7. Documentation

Documentation doesn't have to be long. It has to answer the questions the next person will ask:

• How do I run this locally, and how is it deployed?
• What are the main parts, and what talks to what?
• What breaks most often, and how was it fixed last time?
• What's unfinished or known to be fragile?

One honest page beats a polished document that's out of date the week it's delivered.

8. Contracts and rights

• Your contract says the work, including code and design files, belongs to you once it's paid for, apart from clearly listed third-party components.
• Any ongoing support or maintenance terms are written down, including how quickly issues will be looked at.
• You know what it will cost, and what you'll need, if you decide to move to a different partner.

How to run the handover

1. Agree it at the start. Put "handover checklist complete" in the contract as a condition of final payment. This protects good partners too, because it makes expectations clear.
2. Set up ownership on day one. It's far easier to create the domain, repository and hosting in your accounts at the beginning than to migrate them at the end.
3. Hold a short handover meeting. Go through the list together. Tick each item only when someone on your side has logged in and checked.
4. Rotate and remove. Once you're satisfied, rotate secrets and reduce partner access to what ongoing support actually needs.
5. Keep the list. Update it whenever a new service is added. Next time, the handover takes an hour.

A word for the people doing the build

If you build for clients, offering this list unprompted is one of the easiest ways to earn trust. Clients remember the partner who handed them the keys without being asked, and they tend to come back to them.

The short version

Before the final invoice, make sure you can answer "yes" to one question for every part of the project: if our partner disappeared tomorrow, could we keep running this?

If the answer is no, that's what the handover is for.

Ahmed Vaseer is Founder & CEO - Ingenious Concepts, an AI-first technology and digital growth agency. 80+ projects, ISO 27001 certified via Global CB.