WesolversBoutique web agency
Start a projectContact

Open standard · 0.9 (draft for review)

Do you actually own your website?

Most handover checklists are written from the agency's side and end when the passwords are sent. This one is written from the owner's side and ends where a competent stranger could keep the site running. Free to use, including in contracts and tenders.

Open the checklistSee the maturity model
A set of keys, licences and records being passed between two organisations.

Why this exists

The worst moment to discover what you do not own

The question almost never comes up while a relationship is working. It comes up during a dispute, an acquisition, a redundancy, or the week a supplier stops answering email, which is precisely when every missing item is hardest to recover.

Four answers usually settle how exposed an organisation is: whose name is on the domain, who is billed for the hosting, who administers the analytics, and whose account holds the commercial plugin licences. Teams who assume they know those answers are often wrong, because nobody has ever logged in to check.

This standard is deliberately boring and deliberately complete. It lists 53 items across nine categories, of which 12 are marked as the ones that are painful or impossible to recover later.

Four principles

  • The owner is the organisation

    Every account, licence and record belongs to the company that owns the website, registered in its name and its email domain. A supplier may administer them. A supplier should never hold them.

  • Access is not handover

    A list of passwords is not a handover. A handover is the point at which a competent stranger could keep the site running without asking anyone a question.

  • It is verified, not declared

    Each item is checked by signing in, restoring, or running it. An item nobody has tested is an item you do not have.

  • It is kept current

    A handover pack assembled during a departure is written under pressure by someone with little reason to be thorough. Keep it current while the relationship is healthy.

The standard

What must change hands

Work through it as an audit of your current situation, not only as a departure checklist. Items marked critical are the ones to verify first: they are the hardest to get back once a relationship has soured.

Domains and identity

The one category where a mistake is hard to undo. If a supplier holds the domain, nothing else on this list protects you.

  • Domain registrationCritical

    Registered to the organisation, in its name, at an address it controls. Registrar account owned by the organisation.

  • Registrar access

    Administrative login held by at least two people inside the organisation, with two-factor recovery that does not depend on one person's phone.

  • Domain renewalCritical

    Auto-renew on, payment card that will not expire with an employee, and the expiry date in a calendar someone reads.

  • DNS zone

    A current export of every record, and access to whoever hosts the zone.

  • Transfer lock and auth code

    Lock status known, and the authorisation code retrievable by the organisation.

  • TLS certificates

    Issuer, renewal method and expiry. Automatic renewal confirmed to be working, not assumed.

  • Email records

    SPF, DKIM and DMARC records documented, with their effect on transactional mail from the site understood.

Hosting and infrastructure

Where the site runs, what it costs, and who can change it.

  • Hosting accountCritical

    Owned by the organisation and billed to it, not resold through the supplier's account.

  • Environments

    Production, staging and any development environments listed, with their URLs and what each is for.

  • Server and runtime versions

    Platform, language runtime, database and web server versions, plus the upgrade path currently supported.

  • CDN and edge

    Provider, configuration, cache rules, and any firewall or bot rules that would break the site if lost.

  • Email delivery

    Transactional mail provider, API credentials, and the sending domain's verification.

  • Scheduled jobs

    Every cron task or scheduled job, what it does, and what fails if it stops.

  • Third-party services

    Every external service the site calls, with its purpose, owner, plan and renewal date.

Code and build

A site you cannot rebuild is a site you are renting from whoever last built it.

  • RepositoryCritical

    Full history, in an account owned by the organisation, including every branch currently in use.

  • Build and deploy

    How a change reaches production, documented well enough for a new developer to do it on day one.

  • Environment variables

    Every key the application needs, with its purpose, excluding the secret values themselves, which transfer separately.

  • Dependencies

    Lock files committed, and any private packages or registries named with their access.

  • Custom code

    Bespoke plugins, themes, modules or scripts identified as custom rather than third-party, with their source.

  • Local setup

    Instructions that let a developer run the site locally. The test of a handover is whether this works untouched.

Licences and subscriptions

The quiet failure mode: a licence lapses, updates stop arriving, and the site sits on an old version until something breaks.

  • Commercial plugins and themesCritical

    Each licence listed with its vendor, key, seat count, renewal date and the account that holds it.

  • Licence ownership

    Held in the organisation's account where the vendor allows it, not bundled inside an agency's developer licence.

  • Fonts and media

    Licence terms for typefaces, stock images, video and icons, including whether they cover the current traffic volume.

  • SaaS subscriptions

    Analytics, search, forms, chat, accessibility, backup and monitoring services with their plans and renewal dates.

  • Renewal calendar

    Every renewal date in one place, owned by someone who will still be there.

Data and backups

Backups are a promise about the future. The promise is only worth what the last restore proved.

  • Backup locationsCritical

    Where backups are stored, how often they run, how long they are kept, and who can reach them.

  • A verified restoreCritical

    A restore performed into a working environment, dated, with the person who did it named. Not a backup report.

  • Database export

    A current export handed over, with its schema and character set documented.

  • Uploaded media

    The full media library, with its directory structure intact and total size noted.

  • Personal data

    What personal data the site holds, where it is stored, how long it is kept, and under which lawful basis.

  • Data processing agreements

    Agreements with every processor, so the chain survives the change of supplier.

Accounts and access

The handover is the moment to remove access, not only to grant it.

  • Administrator accountsCritical

    Every account with elevated access listed, with its owner and the date it was last used.

  • Credential transferCritical

    Secrets passed through a password manager or vault, never by email or chat, and rotated after transfer.

  • Departing access removed

    The outgoing supplier's accounts disabled on an agreed date, and their API keys revoked.

  • Shared accounts eliminated

    Any shared login replaced with individual accounts before the supplier leaves.

  • Recovery paths

    Password reset and two-factor recovery that route to the organisation, not to an individual's personal phone or inbox.

Documentation and knowledge

What the outgoing team knows that the site does not show.

  • Architecture overview

    One page describing how the pieces fit together. Diagrams help; prose is acceptable.

  • Known issuesCritical

    An honest list of what is fragile, what is a workaround, and what should not be touched without care.

  • Deliberate decisions

    Why things were done the unusual way, so a successor does not helpfully undo them.

  • Editor documentation

    How the people who publish content are meant to use the site.

  • Runbooks

    The procedures for failures that have already happened once.

  • Open work

    Work in progress, agreed but unstarted, and anything paid for but not delivered.

Analytics, search and marketing

Easy to forget during a technical handover, and painful to reconstruct afterwards.

  • Analytics propertyCritical

    Owned by the organisation, with historical data intact and an administrator inside the company.

  • Search console and webmaster tools

    Ownership verified by the organisation, not only by the supplier.

  • Tag manager

    Container ownership, plus a list of what each tag does and who asked for it.

  • Tracking and consent

    Which tools run, what they collect, and how consent is obtained and recorded.

  • Advertising accounts

    Ad accounts, pixels and conversion events, owned by the organisation.

  • Redirects

    The current redirect map, which is usually the single most valuable undocumented asset on an older site.

How to use it

Three ways this earns its keep

  1. As an audit, today

    Go through the critical items on your current site. You are not looking for perfection, you are looking for the two or three that would hurt. Most organisations find at least one.

  2. As a schedule in a contract

    Attach it to the agreement and make the verified items a condition of final payment. A supplier who objects to that is telling you something useful.

  3. As a living pack

    Keep it current while the relationship is healthy. A handover assembled during a departure is written under pressure by someone with little reason to be thorough.

Help shape version 1.0

This is a draft at 0.9 (draft for review). If something is missing, or an item is wrong in your corner of the industry, tell us what and from what experience. Practitioners should shape it before it gets a 1.0 on it.

Agencies and hosts who want to endorse the standard, or adopt it in their own onboarding, are welcome to. Attribution and a link back are all we ask.

Send feedback

0.9 (draft for review), last updated 2026-11-13.

About the standard

What people ask before putting this in front of a supplier.

Who is this standard for?

The organisation that owns the website. Most handover checklists are written from the agency's side and stop at the point where credentials are sent. This one is written from the owner's side and stops where a competent stranger could run the site.

Can we use it in a contract or a tender?

Yes, and that is the most useful place for it. Reference the version, attach the checklist as a schedule, and make the verified items a condition of final payment. It is free to use and adapt, with attribution.

What if our current supplier will not cooperate?

Start with the items you can check without them: domain registration, registrar access, hosting ownership, analytics administration, licence accounts. Those four or five answers usually tell you how exposed you are, and they are also the ones that are hardest to recover later.

Is a handover pack only for leaving an agency?

No. The healthiest time to build one is while a relationship is working, because it is written carefully rather than under pressure. A good supplier will help you build it. That willingness is itself a useful signal.

How do we contribute or object to something?

Tell us what is missing or wrong, and from what experience. The draft is at version 0.9 precisely so that practitioners can shape it before it is numbered 1.0.

Want someone to run it with you?

We run this checklist as a fixed-price audit and give you the gaps in writing, whether or not you end up working with us.

Ask about an ownership auditScore your operations