Website Handover Checklist: What You Should Receive at Launch

Short answer: at launch you should hold the owner role on every account the website depends on, a copy of the code and data, a written list of tests that passed, and enough documentation to edit the site or hand it to someone else. If any of those is missing, the launch is not finished. The checklist below is what to ask for, in order.

Which accounts must be in your company name?

Ownership is decided by whose name is on the account, not by who paid the invoice. Check each of these before the site goes live.

Two details catch people out:

• Domain renewal notices go to the registrant email. ICANN's Expired Registration Recovery Policy requires reminders about one month and one week before expiry. If that email is the agency's, you will not see them.
• Search Console verification by DNS record or HTML file is tied to the site, not to a person. Verify with your own Google account using Google's verification methods, then add the agency as a user.

Which logins and files should you receive?

Ask for one shared document that lists every item below, with the date it was handed over.

• Code. Repository access or a full export of the source, including build configuration.
• Environment variables and keys. Every API key, with the service it belongs to and who can rotate it.
• Database export. Customers, leads, orders and content, in a standard format such as CSV or SQL.
• Form submissions. All enquiries received during testing and soft launch, so no lead is lost in the move.
• Design source. Figma or equivalent files, fonts with licences, icon sets.
• Images. Originals at full resolution. A list of stock images with licence numbers.
• Third-party services. Every service the site calls (maps, email sending, analytics, chat, payments) with login, plan and renewal date.
• Redirect map. The old URL to new URL list used at launch.
• Access list. Who has access to what, so you can remove the agency later in one pass.

If a lead sits only in a third-party form tool's dashboard, it is in that vendor's database, not yours. A build where every lead writes to a database you own is simpler to hand over and simpler to keep.

What should be tested before launch?

A launch test is a list of pass or fail checks, done on the live domain, with the result written down.

• Forms. Submit a test enquiry from a phone. Confirm it reaches the inbox and the stored record, and that the sender gets any confirmation message.
• Redirects. Every URL in the redirect map returns a 301 to the right page. Google's site move guidance is the reference.
• HTTPS. Every URL loads over HTTPS; the http and www variants redirect to one canonical form.
• Security headers. Content-Security-Policy, Strict-Transport-Security, X-Frame-Options and X-Content-Type-Options are present.
• Mobile speed. PageSpeed Insights on the home, one service page and the contact page meets Google's Core Web Vitals thresholds.
• 404 page. A branded page with navigation, returning a real 404 status.
• Sitemap and robots. Sitemap submitted in Search Console; robots.txt does not block the site.
• Analytics. GA4 page views and the enquiry event fire once per action, not twice.
• PDPA. Privacy notice linked from every form, purpose stated at the point of collection, and a contact for access requests. See the website PDPA checklist.
• Email authentication. SPF, DKIM and DMARC records exist so form notifications and business email are delivered.
• Content. Prices, address, opening hours, phone and WhatsApp number are correct on every page that shows them.

What documentation should come with the site?

Documentation is what lets your team run the site without calling anyone. Four short documents are enough.

1. How to edit. Where content lives, how to change text, images and prices, and how a change goes live.
2. How it is built. Platform, hosting, framework, the services it depends on, and how a developer deploys a change.
3. Where the data is. Where leads, orders and customer records are stored, who can see them, and how to export them. State the retention period, since the PDPA's retention limitation obligation requires personal data to be disposed of once it is no longer needed for a business or legal purpose.
4. Renewals calendar. Domain, hosting plan, certificates if not automatic, paid services, and who pays each.

Add the test results from the section above and the redirect map. Store all of it somewhere your company controls.

What happens if you change agency later?

The handover decides this. If the accounts, code and data are yours, a new agency or an internal developer picks up where the old one stopped.

• Domain. Remove the old agency's contact. Avoid a registrant change if you can, because of the 60-day transfer lock.
• Hosting. On Vercel, transfer the project to a team you own if it is not there already. Domains, environment variables and deployments move with it; integrations and log drains do not, per Vercel's documentation.
• Code. Remove the agency's collaborator access from the repository and rotate any keys they held.
• Search Console, GA4, Business Profile. Downgrade or remove the agency user. Your owner role stays.
• Forms and leads. If leads are already in your database, nothing moves.

If instead the site lives on an agency's builder account, with a domain in the agency's name and leads in a form tool the agency pays for, there is little to transfer and the realistic option is a rebuild. That is the cost of a bad handover, and it is why the questions in how to choose a web design company ask about ownership before price.

What cense does

At launch the client owns the domain, code, hosting and data, with S$0 monthly maintenance and every lead stored in the client's own database. Sites run in Next.js on Vercel or Google Cloud with HTTPS and security headers. The website infrastructure page lists what is set up and handed over.