A website can look finished whilst your domain, enquiries and recovery options still depend on someone else’s account. A website handover checklist helps you confirm business control before approving the launch.
For a small business, the handover should make everyday editing straightforward and emergency recovery possible. You need working access, tested customer journeys and a named person responsible for keeping things running.
Start with ownership, then verify the website does what your customers need.
Key takeaways
- Keep core accounts, recovery contacts and renewal payments under business control, even when a provider manages them.
- Verify access yourself, submit real test enquiries and watch a backup restoration before signing off.
- Record support boundaries, recurring costs and maintenance responsibilities so launch day doesn’t leave important jobs unassigned.
Start your website handover checklist with ownership
Ask your developer to prepare an account inventory. The business owner should check it against the actual accounts, accept invitations and confirm access personally.
Use this ownership record to distinguish client ownership rights from a provider’s day-to-day management access.
| Asset | Who should control it | What to verify |
|---|---|---|
| Domain registrar | Business owner | Registered name holder, account access, expiry and a business-controlled recovery contact |
| DNS control panel | Business or authorised provider | Record export, named administrator and change process |
| Web hosting | Business or contracted provider | Hosting account billing, backups, support access and exit arrangements |
| Website CMS | Business administrator | Working login and appropriate staff accounts |
| Custom code repository | Business, according to contract | Source access, ownership rights and deployment instructions |
| Marketing and payment accounts | Business | Ownership, permissions and recovery details |
For custom work, retain the contract and evidence of the business’s ownership rights, plus access to the code repository and deployment instructions.
A provider can manage these assets without becoming their sole owner. For managed website hosting, document how you obtain files, databases and assistance if you leave.
Also distinguish domain registration changes, registrar transfers and hosting moves. They’re separate tasks. Before changing records in the DNS control panel, save website and email records, including MX and authentication-related TXT entries.
Don’t accept a public domain lookup as proof of control. You must also be able to sign in to the domain registrar and manage the account.
Transfer credentials securely and assign sensible roles
Put recovery access under business control
The developer should invite named users into accounts wherever possible. Use a business-managed password manager for credentials that can’t be transferred through invitations.
Never send passwords, API keys or recovery codes through ordinary email, chat or an open spreadsheet. Enable two-factor authentication where available, then store recovery codes securely.
The owner should verify that the recovery contact is a business-controlled address and that recovery messages reach it. Keep an emergency access route available to another authorised person, so one absent employee can’t block recovery.
Give each person only the access they need
On standard WordPress sites, administrators can manage plugins, settings and users. Editors can publish and manage content but can’t install plugins. Extensions can alter permissions, so check the live configuration.
For shops, review WooCommerce user roles and permissions. A Shop Manager account may suit order management without giving people full administrative access they don’t need.
Retain developer access only where ongoing work requires it. Record its purpose and review date. Otherwise, remove it after handover because an unused administrator account remains another route into the site.
Rotate shared passwords and review connected access tokens without disrupting integrations that still rely on them.
Collect documentation another person can use
Request the technical handover pack
Your developer should provide a documented WordPress handover that another maintainer can use without guessing.
Record the CMS and hosting setup, where the source code is held in the code repository, deployment steps, backup schedule, restore procedure and known limitations. Explain how an authorised maintainer can locate and access the code repository. Make sure the deployment steps show a replacement maintainer how to release a change. For a custom build, document environment variable names and where authorised staff can retrieve their values securely.
Create an account inventory to cross-check connected accounts, owners and access. List every dependency and connected third-party services, such as premium plugins, fonts, booking tools, payment gateways, review widgets and email delivery services. For each third-party service, record the account owner, purpose, renewal date, cost and cancellation consequences. An agency licence may not transfer with the website.
Include operating instructions and approved assets
Keep editable brand files, approved copy, photographs and usage permissions together. These support consistent digital branding when someone changes the web design later.
Ask for a recorded training walkthrough covering content editing, image replacement and enquiry handling. Then have the intended editor complete an ordinary update independently.
Document connections to email marketing, CRM tools, social media feeds and other digital marketing systems. Automation and AI tools used by the small business also need an owner, credentials and a manual fallback.
Store the pack in a business-controlled folder. Credentials belong in the password manager, not in the training document.
Prove that backups can be restored
A backup schedule doesn’t prove recovery will work. Ask the technical provider to demonstrate a restoration before completing the website handover checklist.
Restore a complete copy away from the live site
The provider should restore website files, uploads, configuration and the database into a protected test environment. Keep at least one backup separate from the live hosting account.
During testing, disable outgoing customer messages, live payments and automated workflows. Restrict access to the restored copy because it may contain personal information.
Check important pages, images, logins and stored records. Record which backup was restored, its date, who performed the test and what failed. Fix problems and repeat the test before acceptance.
Agree what recovery can realistically deliver
Ask how much recent data could disappear and how long restoration should take. Daily backups may suit a brochure site, but frequent orders or bookings can require more frequent database copies.
Restoring yesterday’s database can remove today’s orders or enquiries. The recovery plan must account for records created after the backup.
Name who authorises recovery and who performs it. Schedule another restore test, with twice-yearly testing as a practical starting point, and recheck after major platform changes.
Run acceptance tests through real customer journeys
The developer should run technical checks. Meanwhile, the owner should verify business facts and customer outcomes on real phones and desktop browsers.
For each test, record the result, tester, date and evidence. Assign every failure to a named owner, then retest it after the fix.
- Read the main service and contact pages on a phone without zooming. Check menus, readable text and tap targets. Mobile-responsive layouts can still be awkward to use.
- Submit every enquiry form. Check required fields and confirmation messages, and confirm email delivery to the correct inbox. Make sure the named person can respond.
- Complete booking or buying journeys. For ecommerce, verify payment, stock, delivery, tax settings and customer emails using an agreed test procedure.
- Check telephone links, downloads, business email and connected workflows. Confirm lead data reaches the intended third-party services and CRM pipeline, including any automated follow-up.
- Review SEO essentials, including redirects for changed URLs, indexing settings and Search Console access. Compare the website with your Google Business Profile so contact details and service areas support local SEO.
- Verify analytics and agreed conversion events. For conversion optimisation, distinguish a completed enquiry from a button click that never produces a lead.
If a form reports success but an enquiry isn’t delivered, the technical provider should investigate stored submissions, spam folders, delivery logs and notification settings.
Finally, confirm permission to publish photographs, testimonials, logos and downloadable files.
Agree renewals and post-launch support
Ownership alone won’t prevent a plugin licence expiring or a failed update breaking a booking form. Name a person for each recurring task.
The business owner should approve renewal costs, including plugin renewals, and maintain payment details. The provider should explain which licences belong to the business, which sit under an agency subscription and what happens if that subscription ends.
Keep renewal reminders in a shared calendar, alongside an inventory of costs and cancellation terms.
Your launch support agreement should set out the support window, its start and end dates, how to request help, response commitments and covered defects. Separate fixes to agreed functionality from new pages, extra integrations and other web development requests.
For ongoing website care and maintenance, assign recurring maintenance tasks, including software updates, security monitoring, backup checks, uptime alerts and regular form testing. Keep a maintenance log for future providers, recording completed updates, checks and changes. Document recurring maintenance responsibilities and costs in the maintenance log, so the business can check what’s due.
Creative agencies should also name who communicates with clients and who authorises technical work. See how we collaborate with creative agencies when you need a technical delivery partner with clear responsibilities.
Keep a written sign-off record
Use one acceptance record, with the completed checks and evidence forming the acceptance checklist, rather than relying on scattered messages. The business approver and technical lead should provide written signoff once they confirm completion against the agreed work.
Record these decisions before final approval:
- Confirm the delivered pages, functionality, training and documentation against the agreed project scope, including deployment steps where relevant.
- Attach ownership evidence, account invitations, the account inventory, customer-journey results and the restoration test record. Where custom code is included, verify access to the code repository.
- List unresolved defects with an owner and deadline, noting whether each blocks launch.
- Record launch approval, the support window, maintenance owner and route for requesting paid changes.
Keep future improvements separate from unresolved defects. This makes approval clearer without treating every cosmetic issue as a launch blocker.
Frequently asked questions
Must I have every technical login?
You need control and a workable exit route, but you don’t need to manage every server setting. A contracted provider can hold operational access if responsibilities, recovery arrangements and transfer procedures are documented. Keep domain registration and business recovery contacts under your control.
Can my developer keep administrator access?
Yes, when they’re providing agreed maintenance or support. Use a named account with two-factor authentication where available, and review it regularly. Remove access when the relationship ends rather than leaving an old account active indefinitely.
What should stop final sign-off?
Missing business control, failed enquiry delivery, unusable customer journeys or an untested recovery process should block acceptance until resolved. Minor cosmetic issues can sit on an agreed completion list, provided both parties record responsibility and timing.
Finish with control, not uncertainty
A finished-looking website isn’t enough if nobody can recover it or confirm where enquiries go. Your strongest handover evidence is tested access and recovery, supported by clear responsibilities.
Before approving launch, verify the accounts, complete customer journeys and sign the acceptance record. Keep the written signoff current as staff, suppliers and systems change. Record who owns support after launch, including the support window and key dates.
