After launch, who knows how to take over the website?

After launch, at least one person inside the business should be able to access the domain, hosting account, highest-level website administration and form notifications. They should also know how the website is backed up, updated and restored. If that knowledge remains only with the supplier or one former employee, the site may be online, but the delivery is not complete.

A website loading correctly does not mean the handover is complete.

If only the production team knows the domain account, hosting account, administrator access, backup method and form destinations, a change of staff or an unexpected failure can quickly turn the website into a system nobody can operate.

A website should not only look good. It should be usable and manageable.

Why launch and handover are not the same

Launch means the public URL works today. Handover means the organisation understands what the website depends on, who controls each part, how routine work is completed and what to do when something fails. The difference often becomes visible only when a renewal is due, a staff member leaves, a redesign begins or an incident occurs.

Common examples include:

• The domain is registered under a former employee or supplier's personal account, so nobody receives the renewal notice.
• Hosting is charged to an unknown card and the finance team cannot identify the service or expiry date.
• Everyone shares one super administrator account, making changes impossible to trace.
• Backups are described as automatic, but nobody knows where they are stored or whether they can be restored.
• A form submits successfully, yet nobody knows which mailbox receives the enquiry.
• The supplier holds all technical information and the business has no internal handover record.

The real question is not whether the website works today. It is whether the business can make the right decision tomorrow when people, services or systems change.

Six points to confirm before final acceptance

1. Who owns the domain, hosting and DNS accounts?

The domain is the website address, hosting is where the system runs, and DNS connects the two. The business should know the provider, account owner, renewal date, payment method and authorised contacts. If a supplier manages these services, the agreement should explain how ownership and data can be transferred.

2. Who has the highest level of access?

The business should retain an account able to create and disable users, change permissions and respond to emergencies. Editors should use individual accounts with only the access they need. When a role changes, one account can then be removed without changing credentials across the whole website.

3. How are backups created and restored?

Confirm whether backups include website files, the database and uploaded media. Record their frequency, location, retention period and owner. At least one restoration check should be completed; a successful backup notification alone does not prove the copy is usable.

4. How are articles, images and company details updated?

The handover should demonstrate the login location, draft and publishing workflow, image rules, editable fields and areas that still require technical support. If there is no CMS, document who receives change requests, expected response times and how versions are recorded.

5. Who handles a submitted form, order or booking?

A successful submission is only the start of the workflow. Name the primary recipient, backup recipient, response target and escalation route. Where possible, retain submissions in the administration system so an email delay or spam filter does not erase the customer's request.

6. Who handles incidents and where are they recorded?

Separate content errors, access problems, hosting failures, domain expiry, broken forms and security events. Assign an owner for each category. Record the time, impact, responsible person, actions and final outcome so the next incident does not begin with the same investigation.

Which accounts should remain under company control?

The goal is not to give every employee every password. The goal is to keep ownership with the company while granting daily access according to responsibility. Highest-level credentials should be restricted and stored in a controlled password process, not scattered through chat messages, personal notes or former employees' devices.

A complete handover has three layers

Asset handover

List the domain, hosting, database, source code, original design files, image rights, email, analytics and third-party services. For each item, record the owner, payer, administrators and transfer process if the relationship ends.

Operational handover

Explain how to create and publish content, route forms, process orders or bookings, prepare images and complete regular updates. Name a primary and backup owner for each workflow. This section should be usable by a non-developer.

Incident handover

Document the first steps when the website is unavailable, a form stops notifying, an account is locked, content is deleted, or a domain or certificate is near expiry. Where external support is required, include the covered scope, contact route and response window.

Practical scenario: the website owner leaves the company

Imagine a marketing manager created the domain, analytics property and website account using a personal email address. When that person leaves, the business discovers that renewal messages go to a private mailbox, two-factor authentication is tied to a personal phone, and only that person receives form enquiries.

The public website still works, but the company has lost three capabilities: it cannot verify ownership, safely revoke access or confirm whether customer messages are being handled.

A stronger setup would be:

1. Company-controlled accounts own the domain, hosting and analytics properties.
2. Every administrator uses an individual account that can be disabled separately.
3. Forms deliver to a role-based mailbox with a second recipient as backup.
4. Two-factor recovery methods for critical services are stored under company control.
5. Accounts, renewals, backups and contacts are reviewed every quarter.

With this arrangement, a new owner can use the records to take over instead of reconstructing the system from old conversations, browser passwords and support emails.

What to include in a website handover pack

A useful handover pack explains ownership and operations without placing plain-text passwords in an ordinary document:

1. Public website URL, administration URL and production environment name.
2. Domain, DNS, hosting and email providers.
3. Company owner, administrator and billing contact for each service.
4. Role and permission matrix, including account creation and removal.
5. Content guide covering images, drafts, previews and publishing.
6. Form, enquiry, order or booking workflows and backup contacts.
7. Backup frequency, location, retention and restoration steps.
8. Storage location for source code, design files, brand assets and usage rights.
9. Owners of GA4, Search Console, Bing and other analytics properties.
10. Third-party services, APIs, extensions and recurring fees.
11. Incident diagnosis, escalation order and technical support contacts.
12. Date of the latest backup review, access review and restoration exercise.

Passwords should be transferred through a controlled credential process. The handover pack should tell the next owner what exists, where it is managed and who has authority, without becoming a single file containing every secret.

Eight acceptance tests to perform together

• Sign in to the domain and hosting through a company-controlled account.
• Create a low-permission test administrator and confirm that the primary administrator can disable it.
• Create and preview a draft without exposing it publicly.
• Submit one internal form test and confirm where the primary and backup owners can find it.
• Locate the newest backup and confirm that it covers files and the database.
• Explain which backup would be used after an accidental homepage change and who would restore it.
• Confirm that company-controlled accounts own the analytics and search properties.
• Ask someone who did not build the website to complete one basic update using the handover guide.

The final test matters most. A handover is effective when the next responsible person can complete the work, not merely when the original supplier believes the document is clear.

Frequently asked questions

Is supplier-managed hosting or domain registration always a bad idea?

No. Managed services can reduce technical workload, but ownership, renewal, backup, termination and transfer terms must be explicit. The business should know who controls the account, how fees are calculated and what data can be obtained when a transfer is requested.

Does the company need every super administrator password?

The company should retain ownership and emergency control, but not every staff member needs super administrator access. Limit the highest privileges to a few authorised people and provide editors, support teams and operators with role-appropriate access.

Are automatic backups enough?

Not by themselves. Capacity limits, permissions, exclusions or retention rules can leave important data uncovered. Check the backup time and contents regularly, understand the restoration path and create an additional restore point before major changes.

Are technical maintenance and content updates the same task?

No. Content work covers articles, images, services and notices. Technical maintenance covers software, security, hosting, certificates, backups and incidents. One team may provide both, but the duties and acceptance criteria should remain clear.

How often should the handover record be updated?

Update it whenever staff, suppliers, billing, permissions or workflows change, and review it briefly every quarter. A handover document that is never maintained soon becomes a historical record that only described launch day.

Conclusion: delivery is complete when the next person can take over

A complete website handover allows the next responsible person to understand and operate the system even after a staffing change. A business does not need to perform every technical task internally, but it should know who owns each asset, who manages daily work, where backups live and how support is reached during an incident.

When accepting a website, review more than design, links and mobile layout. Verify accounts, permissions, backups, form delivery and operational records. Defining these responsibilities before launch reduces the business risk created by staff changes, service expiry and urgent failures.

Related reading: When does a business website need a content management system (CMS)?. If you are planning a new website or taking over an existing system, start a project with Stage of Me to include delivery, management and ongoing operations in the scope from the beginning.