Website Handover Checklist

Last updated: October 11, 2026

Key Takeaways

• Within 24 hours, a clean handover lets the customer control the site, keep it live, and know what they own.
• Before you touch design changes or copy edits, transfer the domain, hosting, DNS, and admin access.
• The content handover should cover text, images, video, downloads, and metadata the customer can publish and reuse.
• First change ownership of customer-facing systems; after that, send only the notices customers actually need.

A website handover checklist after a sale is where ownership turns from paper into practice: miss the technical, content, or customer-transition steps, and you can strand logins, break revenue, or leave the customer unable to run the business on day 1. Messy handovers have a way of biting back.

What actually has to happen in a website handover?

Within 24 hours of closing, the customer should be able to control the site, keep it live, and understand what they own. Sounds straightforward. Usually, it isn’t. A website is really a stack of domains, hosting, CMS access, payment tools, analytics, email accounts, and content rights—not a single asset.

Selling a content site, an e-commerce store, or a lead-gen business changes the details a bit. A brochure site can move with fewer moving parts. A store with Stripe, PayPal, Klaviyo, Google Merchant Center, and a fulfilment app needs a much tighter checklist, especially on sale day.

Here’s the rule I follow: if the customer cannot restore, edit, bill, and measure the site without asking you for a password, the handover is still unfinished.

Situation	Best Path	Why Other Options Fail
Simple brochure site	Transfer domain, hosting, CMS admin, and content files in one pass	Leaving old admin accounts active creates avoidable risk
Content site with ad revenue	Add analytics, ad accounts, Search Console, and content inventory	Handing over only the CMS hides traffic and revenue dependencies
E-commerce store	Stage payment, shipping, tax, and app transfers before domain cutover	A “copy the site and hope” transfer breaks orders and customer emails
Business sale with customer data	Document consent, retention, and account ownership changes	Ignoring data controls can create legal and reputational problems

A practical handoff covers three things together: technical control, content ownership, and customer communication. Miss one, and the others wobble.

Quick check: if the customer asked, “Can I run this tomorrow without you?” and the honest answer is no, the handover is incomplete.

Which technical assets should be transferred first?

Start with the domain, hosting, DNS, and admin logins. Worry about design tweaks later. Those are the controls that keep the website reachable.

If the domain still sits at a registrar you control, begin there. Common registrars include GoDaddy, Namecheap, Cloudflare Registrar, and Google Domains’ successor arrangements through Squarespace for many users. The exact transfer method depends on the registrar, but the customer should end up as the registrant or fully controlling the registrar account. For DNS, confirm who controls the zone file and who can change A, CNAME, MX, and TXT records.

Then move hosting access. On WordPress, that may mean cPanel, Plesk, managed WordPress hosting, or a cloud server. On Shopify or Webflow, the platform itself is the hosting layer, so platform admin access matters more than a server login.

Use this order:

1. Inventory every technical account: domain registrar, hosting, DNS, CMS, CDN, SSL, backups, cache, security plugins, SMTP, and monitoring tools.
2. Verify the customer has owner-level access in each system, not just a shared login.
3. Change recovery email addresses and two-factor authentication devices to the customer’s control.
4. Export current backups, configuration files, and license keys, especially for paid plugins and themes.
5. Test the site from a fresh browser and an incognito window after each major transfer.
6. Confirm mail flow, forms, checkout, and redirects still work after DNS changes.

The biggest mistake is swapping accounts in the wrong sequence. Move DNS before the customer has the right SSL certificate, MX settings, and email host details, and you can trigger an outage that takes hours to unwind. ICANN and Cloudflare both point toward careful registrar and DNS changes rather than rushed swaps.

Quick check: if any login still goes to your email, your phone, or a password manager only you can open, the technical handover is not done.

What should be included in the content handover?

Everything the customer needs to publish, update, and legally reuse should be in the content handover: the site’s text, images, video, downloads, and metadata. That means more than the pages people see.

If the business sold includes original copy, photos, product descriptions, blog posts, lead magnets, or course material, the customer needs a content inventory with status notes. I’d split it into four buckets: owned outright, licensed, borrowed, and needs replacement.

A generic handoff often misses the mark because it treats “content” as a page export. If that is your situation, it is worth getting professional legal or IP advice before closing. A WordPress XML export, a Shopify theme backup, or a CMS screenshot does not tell the customer whether the hero image came from a stock library, whether a testimonial can still be used, or whether an author bio is tied to the seller’s identity.

Use a document or spreadsheet with these fields: URL, content type, asset owner, source file location, license status, editing notes, and whether the item should be kept, rewritten, or removed. If you used Adobe Stock, Shutterstock, Envato Elements, or a similar service, confirm whether the license is transferable. Many are not in the way people assume.

Also hand over SEO-critical items:

• title tags and meta descriptions
• redirects, especially 301s
• sitemap status
• structured data snippets
• image alt text
• content calendars and draft posts
• brand style notes, if they exist

If the customer is taking over a site that relies on one author’s voice, that becomes a real transition problem. The content may transfer technically, but commercially it can still be fragile. The fix is not “keep writing like before”; it is to identify the 10 to 20 pages that matter most and rewrite them in the new owner’s voice before the old voice turns into a liability. That’s the bit people skip.

Quick check: if you cannot tell the customer which assets are safe to reuse and which need permission, you are not done with content handover.

How do you hand over customer accounts and email without chaos?

Change ownership first, then send customers only the notices they actually need. That order keeps support tickets and panic replies down.

If the site has a customer account area, login portal, support inbox, newsletter list, or order history, the customer needs control of each channel before any public announcement goes out. The same applies to Gmail, Microsoft 365, or any transactional email service such as Mailgun, SendGrid, Postmark, or Amazon SES.

Here’s where handovers often go sideways: the seller keeps one “shared” inbox alive for a month. It sounds helpful; in practice, it becomes a mess. Old billing questions, password reset requests, and unsubscribe complaints pile into the wrong mailbox, and nobody knows who should answer.

A cleaner path looks like this:

1. Move the primary support inbox to the customer’s domain or mail system.
2. Transfer mailing list ownership in the email platform and export suppression lists.
3. Update “from” names, reply-to addresses, and automated confirmation templates.
4. Check customer-facing triggers: password resets, order receipts, shipping notices, and subscription reminders.
5. Prepare a customer transition notice that names the new owner, effective date, and support contact.
6. Run a 7- to 14-day overlap only if the contract requires it, and define exactly who answers what.

The customer notice should be short. It should not read like a merger press release. Tell people who now runs the site, whether accounts or billing terms change, and where to send questions. If payment processors or subscription terms are changing, the customer may need separate legal review before sending anything.

For regulated businesses, privacy policy updates matter too. If the sale changes the data controller, the customer should review GDPR, CCPA/CPRA, or other local requirements with counsel before making promises to customers. The ICO and FTC both stress clear notice and lawful data handling.

Quick check: if a customer reply could still land in your inbox after closing, the communication handover needs another pass.

The 3 conditions that change everything

The site’s business model, regulatory exposure, and platform lock-in are the three conditions that change the handover plan the most.

If you are transferring an e-commerce store, then payments, tax settings, subscriptions, fulfilment apps, and refund workflows matter as much as the website itself. If it is a lead-generation site, forms, CRM integrations, call tracking numbers, and ad pixels are the fragile points. If it is a membership or course site, user access, gated content, and recurring billing need special care.

This is the part many generic checklists miss: a website handover is not one checklist. It is a different checklist for each revenue model.

Here is a practical comparison:

Situation	Best Path	Why Other Options Fail
E-commerce store	Transfer Shopify/WooCommerce admin, payments, shipping, tax, and inventory tools before domain switch	A content-only handover can break checkouts and payment capture
Lead-gen site	Move forms, CRM, call tracking, analytics, and ad accounts together	If leads still route to the seller, the customer loses revenue immediately
Membership site	Reassign access control, membership plugins, and billing subscriptions	A CMS export alone does not preserve paid access
Local business site	Update Google Business Profile, maps embeds, and contact routing	The website may transfer cleanly while calls still go to the old owner

Standards and compliance also matter. If the site handles card payments, look at PCI DSS responsibilities through the payment provider and the merchant account. If the site stores personal data, review what the current privacy notice says and whether it matches the new ownership structure. Because of that, I would not treat this as a technical-only problem; if the business is regulated, consult a qualified professional before closing.

The handover path is usually staged in practice, even if the exact order varies. First comes control of the systems that create revenue. Then the visible website changes hands. After that, update customer-facing messaging and legal pages. The customer should never discover a broken checkout after the seller has already handed over the keys.

Quick check: if the site earns money through orders, leads, or subscriptions, the handover must protect those flows before anything cosmetic.

What should a seller do on the final 48 hours?

Freeze changes, export evidence, and leave the site in a known state 48 hours before closing. That is the cleanest way to avoid “last-minute” edits that nobody remembers later.

If you are the seller, stop routine publishing, plugin installs, theme changes, and campaign launches unless the contract says otherwise. Export what can be exported: full backups, user lists, settings screenshots, analytics snapshots, ad account references, DNS records, and billing receipts for important tools. Save them in a shared folder the customer can open immediately.

Then run a final checklist:

1. Confirm domain, hosting, CMS, and all key app logins are listed in the transfer document.
2. Record current versions of WordPress, plugins, themes, or platform apps.
3. Document active redirects, forms, automations, and payment subscriptions.
4. Note anything temporary: promotional banners, discount codes, staging sites, or redirects.
5. Verify that backup restoration instructions are written in plain language.
6. Hand over support contacts for hosting, developers, designers, and domain registrar.

If there is a content schedule in flight, decide what happens to drafts, queued emails, social posts, and ad campaigns. A queued newsletter from the old owner can create confusion even when the site itself transfers cleanly.

The trade-off is obvious: freezing changes can slow a live business for a day or two. Honestly, I still prefer that to handing over an unstable site with no reliable snapshot of what was live at close.

Quick check: if there is no final backup date and no written freeze point, the last 48 hours are not controlled enough.

What are the edge cases where the normal advice breaks down?

The normal advice breaks down when the site depends on third parties, hidden contracts, or regulated data. In those cases, the handover has to be narrower, slower, or lawyered.

1. The site is built on a freelancer’s private account.
   What changes: the CMS, graphics, or code may sit inside one person’s account and cannot be “transferred” cleanly.
   Instead, rebuild ownership around a company account, export source files, and confirm license rights before closing.

2. The seller and customer are in different countries.
   What changes: tax, privacy, and consumer law can affect emails, terms, and data handling.
   Use local counsel to review transfer language and any customer notices before the switch.

3. The site uses third-party content the seller did not create.
   What changes: stock photos, guest posts, embedded video, and republished articles may not transfer.
   Itemise each asset and remove or relicence anything with unclear rights.

4. The business depends on a single ad account or agency relationship.
   What changes: revenue can vanish even if the site stays online.
   Transfer ownership of Google Ads, Meta Business Manager, Merchant Center, or agency permissions before closing.

5. There is a pending migration or redesign.
   What changes: the site may have two states—current and future—which confuses the handover.
   Lock one version as the official live site and document any unfinished work separately.

6. Customers have subscriptions or stored payment methods.
   What changes: billing continuity becomes the main risk.
   Coordinate with the processor, confirm token portability if applicable, and test renewal notifications with care.

These are not rare enough to ignore. They are the cases that turn a tidy asset sale into a support nightmare.

Quick check: if any part of the site relies on someone else’s account, contract, or license, assume the standard handover checklist is incomplete.

The handover document I would insist on

I would insist on a single handover document that lists every asset, owner, login, dependency, and open risk in one place. The website handover checklist after a sale is much easier to execute when everyone is working from the same sheet. Include domain registrar details, hosting credentials, DNS records, CMS roles, backups, analytics access, payment tools, email platforms, content inventories, and customer-transition notes.

If the customer wants a short version, give them that too. But keep the full record somewhere durable. A handover that lives in five inbox threads and two spreadsheets is not really a handover; it is a trail of clues.

Drafted with AI; not yet reviewed by a person.