Website Handover Checklist: What Should You Request From Your Developer?

A website handover is the step most projects rush, yet it shapes everything that follows. The design looks finished, and then the site goes live. However, whoever holds the domain, hosting, admin account and analytics still controls the site in practice. In this guide, Talha Aslan and team walk through every item you should have in hand on handover day.

In short, a handover means more than "the site is live." Imagine your developer becomes unreachable tomorrow. If you could still pass the site to another team without trouble, the handover is truly done. We suggest you read this checklist with that test in mind. Also, ask one question for each item: is this information with me, or only in someone's memory?

On the other hand, a handover check differs from acceptance testing. To test whether pages and features work, see our website acceptance testing checklist. Instead, this article answers a different question: what should you own, and what should you hold?

Why does a website handover mean more than a live site?

A site can look fine while critical parts sit in someone else's account. For example, the domain may live in a developer's personal account. Your hosting may run on an agency plan. The Google Analytics property may sit under the agency's own login. The site works today, but you cannot touch any of it once the relationship ends.

In our field experience, the most common cause is not bad intent. Instead, it is clutter. Projects move fast, everyone says "we will transfer it later," and later never comes. That is why we treat the handover as its own line item, just as important as the design.

If you already face this problem, and your site or domain is stuck with a former agency, read our step by step guide on taking back your website and domain from an agency. This article, instead, helps you avoid that situation in the first place.

When should you prepare the handover checklist?

The best time is the start of the project. If you leave the list for the final week, most accounts will already exist under someone else's name. Fixing that later adds work. If you share the list at the kickoff meeting, the team can create every account in your name from day one.

For example, during discovery it takes a few minutes to agree on where the domain lives, who owns the hosting and which account holds the analytics. Solving the same issue after launch can take days. So think of the list as an opening document, not a closing one.

Also, keep the list current throughout the project. When you buy a new plugin or connect a new service, fill in that row right away. Then on handover day you review a ready table together instead of building an inventory from scratch. Put simply, a good handover is not a last day task. It is a record that grows during the whole project.

How do you check domain ownership?

The domain is your address, and it comes first on the list. In practice, the check is simple. Is the registrar account in your name? Does the registrant record show your company? The contact email should also belong to you, because renewal notices and transfer approvals go to that address. If that email belongs to the developer, you may miss an expiry warning or a transfer request.

Next, learn about the transfer lock and the transfer code. ICANN's Transfer Policy sets the rules for the AuthInfo code and for transfer prohibited statuses when you move a domain between registrars. Specifically, you do not need the code on handover day. Still, you should be able to generate it from your own panel when you need it.

• The registrar name and login address.
• Proof that the account uses your email.
• The renewal date and auto renewal setting.
• The panel where DNS records live.

If a domain has already lapsed, our guide on getting an expired domain back offers a detailed path.

Do you have hosting access and server details?

Hosting is where your site files and database live. In the ideal case, you open the hosting account yourself, you receive the invoices, and the design team joins as an extra user. Then, when the relationship ends, you simply remove that user.

That said, some projects run on the agency's own plan. In practice, this is not wrong in itself. Even so, put in writing when and how fast you will receive migration support. Also store these details in a shared vault:

• The hosting panel address, username and two factor method.
• SFTP details for file transfer.
• Database name and database user.
• The PHP or runtime version in use.
• Plan end date and resource limits.

Tip: share passwords through a password manager, not as plain text in email. After the handover, change the hosting password yourself. Also check which inbox receives hosting invoices, because a missed payment reminder can take the site offline.

How should you take over the admin account?

The first admin account in the dashboard should belong to you. Of course, your developer can also use a separate account for daily work. However, the main admin role should link to your email, so password reset links land in your inbox.

Consider an example scenario. A business takes over its site with a single account called "admin," and the agency knows the password. When the project ends, nobody changes it. The former team can still log in. The right approach is to give each person a separate account and close the ones you no longer need. For instance, when a new employee joins, you create their account; when they leave, you close only that one.

So ask these questions on handover day. How many admin accounts exist? Who owns each one? Is two factor authentication on? Who removed the unused accounts? Written answers to these four questions prevent many security issues later.

Why do source files and design files matter?

The live site is really an output. The theme files, custom code, design files and original images that produce it are the real assets. Without them, even a small change also keeps you tied to the same team.

For custom coded sites in particular, ask for a current copy of the source code. If the code lives in a version control repository, such as a Git repository, ask the team to transfer it to an account you own. At minimum, request read access. The same logic applies to design files.

• Theme or application source code.
• Project files from the design tool.
• High resolution originals of the logo, icons and images.
• A list of fonts and where they come from.

As a result, you will not start from zero when you want a new page a year later. Moreover, if you switch teams, the new team can keep your existing design language intact.

How should you take and test a backup at website handover?

On website handover day, take a full backup of the site, meaning files and database together, and store it in your own storage. However, a backup that merely exists is not enough. You also need to see that it restores. A backup you have never tried can surprise you in a crisis.

Therefore, ask the team to add a restore note to the package. Where does the backup live? Which tool created it? Which steps restore it? If automatic backups run, the note should also state their frequency and retention period.

For a wider view of backup planning, our website backup strategy guide covers copy count, location and frequency in detail. For the handover, one short rule applies: keep at least one copy outside the hosting provider and under your control.

Whose name should licenses and paid plugins carry?

Paid themes, plugins, fonts and stock images are quiet dependencies. If a license sits in the agency account, update rights may end the day the relationship ends. As a result, the site keeps running, but it can stop receiving security updates.

So for every paid component, ask for a table that lists the license holder, the renewal date and the terms of use. Some licenses can move to a new owner and some cannot. So check this on the product's own license page. If a license cannot move, know up front what a new license in your name will cost.

Also, do not overlook stock image and font licenses. Without proof of usage rights, you may struggle to respond if a rights holder contacts you later. This is general information, not legal advice; consult a legal professional about license terms.

How do you take over analytics and Search Console ownership?

Measurement accounts carry your site's history. If the agency created the Google Analytics property under its own account, you can lose access to years of traffic data when you part ways. So ask for the property to live in your account, or for you to hold the top permission.

Google's access and data restriction management page describes five Analytics roles: Administrator, Editor, Marketer, Analyst and Viewer. At handover, your role should be Administrator. The agency can keep a narrower role if it still needs one. Also save screenshots of core settings such as data retention and key events.

In Search Console, however, ownership matters even more. According to Google's guide to managing owners, users and permissions, a verified owner proves ownership with a token on the site. Even after you remove that user, they can verify again while the token stays in place. In other words, you must clean up tokens when you remove former owners. For the steps, see our guide on removing an old owner from Search Console.

Website handover table: who should hold each item?

The table below summarizes the ideal owner of each website handover item and what to request. You can print it and bring it to the handover meeting.

Should you check tag management and ad connections too?

Yes, because these accounts often come last to mind. A Google Tag Manager container, conversion tags and links to ad accounts are also part of the site. If the agency set up the container in its own account, you may lack the right to change tags.

So make sure your account holds the top permission in the container. Also ask for a simple list of the measurement codes on the site: which tag, for what purpose and with which trigger? Then you can easily spot unused or duplicate tags later. In addition, note which tags your consent tool runs and under which consent.

Likewise, the ad accounts themselves should belong to you, with the agency connected only through manager access. The logic stays the same across every tool: the account is yours, and the team gets access.

What should the documentation include?

Documentation is the user manual for your site. However, it does not need to be long. Still, it should be clear enough for a new team to understand the site in one day. In our projects, the handover note usually has two parts: a usage guide for the content team and an infrastructure note for the technical team.

1. Steps to add pages and posts, plus recommended image sizes.
2. The email addresses that receive form notifications.
3. Which plugins are installed, why, and which ones are critical.
4. A summary of cache and security settings.
5. The backup and restore method.
6. Third party services and where their API keys live.

In addition, a short screen recording helps a lot. A written note plus a few minutes of walkthrough answers most future questions. Do not write it once and forget it, though. When you make a major change, update the matching section too.

Should you check email, forms and third party services?

Absolutely. Contact forms, newsletter signups, live chat widgets and payment gateways all run on separate accounts. If the agency opened those accounts in its own name, even your form messages may land in someone else's dashboard.

Here is an example scenario. A company sends its contact form through a delivery service on the agency account. When the contract ends, the service shuts down and forms reach no one for weeks. To prevent this, open each service in your own account, or ask the team to transfer the account at handover.

Also, your business email depends on your domain's DNS records. Therefore, export the current email records before you change any DNS settings. Otherwise, a site migration can cut off your email too.

What should you verify for security and SSL?

On handover day, confirm that the site loads over HTTPS, that the certificate is valid and that renewal runs automatically. Our SSL checker tool shows the expiry date and the covered domain names in seconds. Also find out which account renews the certificate, since a hosting change may require a new install.

Next, add these security checks to your handover list:

• Strong passwords and two factor authentication on every admin account.
• Closure of temporary accounts from the build phase.
• Staging sites blocked from search engines.
• Core software and plugins on current versions.

That way, the site does more than look good. It also stands on a secure base from the first day.

Should you ask for an accessibility and quality report?

We recommend it, because a site that everyone can use is a natural part of the handover. The W3C WCAG 2.2 standard defines three conformance levels for accessibility: A, AA and AAA. At handover, ask in writing which level the team targeted and which checks they ran.

In practice, the report does not need to be long. It is a fine start if it shows checks on keyboard navigation, color contrast, image alt text and form labels. You can also add a summary of speed and mobile layout tests.

As a result, you document the state of the site on the day you receive it. When an issue appears in later months, you use this report as your baseline. Then you can quickly tell whether the issue existed before the handover or came from a later change.

Where should you store the handover package?

The details you receive only help if they live in the right place. We suggest you keep passwords, access details and license keys in your company's password manager, inside a shared vault that a few authorized people can open. After all, data that sits in one employee's personal inbox disappears when that person leaves, because nobody else can open it.

Meanwhile, create a company cloud storage folder for backups, design files and documentation. Split it with a simple structure: access, backups, source files, licenses and documents. Then a new colleague or a new agency finds what they need in minutes.

• Passwords: a shared vault with per person access.
• Backups: outside the hosting, in dated folders.
• Licenses: purchase receipts and renewal dates.
• Documentation: one editable master document.

Also review this setup at least once a year. Remove access for people who have left, renew expiring licenses and prune old backups based on your retention plan.

Which contract clauses should cover the handover?

A handover checklist works best when the contract backs it. If you define in writing which items you will receive at the proposal stage, no dispute arises at the end. When you compare offers, our guide on evaluating a web design proposal helps you look for this clause.

• In whose name the domain, hosting and measurement accounts open.
• The transfer of source files and design files.
• Ownership and renewal duty for paid licenses.
• The length and scope of post launch support.
• Conditions for migration support when the relationship ends.

This is general information, not legal advice; consult a legal professional about the contract text. Still, here is a practical tip. If you attach the handover table to the contract, both sides know from day one what they will check at the end.

Does the checklist change for a website redesign?

The core items stay the same, but two extra topics gain weight: an archive of the old site and URL redirects. Before the new site goes live, store a full backup of the old site in a separate folder. Then you have a source to return to when you need an old page or image.

Also ask for a mapping table that shows how each old URL redirects to its new URL. Above all, this table is one of the most important documents for protecting search visibility. It also becomes a reference for future changes.

On the other hand, list the services the old site used that the new site no longer needs. An unused form service, an old tag or an open account means extra cost and a security gap. So in a redesign, the handover also includes a cleanup step.

What is the shortest handover list for a small business?

That said, not every business needs a full documentation set. Even for a one page brochure site, these seven items solve most future problems up front. In other words, the list can be short, but it should never be empty.

1. A domain account under your email.
2. Your own user login for the hosting panel.
3. A main admin account in your name.
4. A full backup in your own storage.
5. Top permission in analytics and Search Console.
6. A list of paid components.
7. A one page usage note.

Example scenario: a cafe owner uses the site only for the menu and contact details. In that case, a complex technical report adds little value. Still, those seven items should be in the owner's hands. Then, as the site grows, the list can grow with it.

How should handover day run, step by step?

Handover day works far better as an ordered meeting than as a scattered email thread. Here is the flow we suggest:

1. Open each item in the table and see ownership on screen.
2. Log in to every panel with your own account, not someone else's session.
3. Download the full backup and save it to your own storage.
4. Collect the license and service list, then add renewal dates to your calendar.
5. Receive the documentation and the screen recording.
6. Close temporary accounts and change shared passwords.
7. Have both sides sign off on a handover record.

After that, try to run the site on your own within a week. Update a piece of content, test a form and open a report. That way, you spot any missing item before the support period ends.

How do you plan maintenance after the website handover?

The work does not end after the website handover; responsibility simply changes hands. For example, updates, backup checks, security scans and content edits need regular attention. Decide at handover whether your own team will handle this or whether you will set up a maintenance agreement.

To see which tasks make up monthly care, review our website maintenance checklist. To keep all your digital accounts in one order, our digital asset management guide offers a practical framework. If your own team takes on maintenance, name the owner and a monthly check day up front.

In short, the maintenance plan continues the handover checklist. The list secures today, and maintenance protects tomorrow.

What are the most common website handover mistakes?

In our field experience, most mistakes follow a few repeating patterns. Knowing them helps you use the checklist with more care. Moreover, almost none of them need technical skill; most come from not asking the right question at the right time.

• Leaving the domain in the developer's personal account.
• Sharing one admin login with everyone.
• Keeping backups only on the hosting server.
• Never asking whose name the licenses carry.
• Leaving old verification tokens in Search Console.
• Skipping documentation because "we already know it."

So a handover is not a test of trust; it builds order. A good team puts this list in front of you before you ask. If your team avoids these topics, take that as a signal and request the missing items in writing.

Can we set up this handover structure for your site?

Yes. In our web design service, we open the domain, hosting, admin account and measurement tools in your name from the start. At the end of the project, we deliver the completed table above along with written documentation. In other words, you own the site before it even launches.

If you want to bring order to an existing site's handover or start a new project, share your needs and request a web design quote. Then, in the quote, we list item by item what transfers to you.

Finally, a checklist does not signal distrust. Instead, it protects both sides and keeps the work professional.