A domain or website handover is complete only when the new owner can control, operate, measure, and recover the asset without relying on the previous owner. This reusable website transfer checklist covers registrar access, DNS, hosting, email, CMS administration, analytics, code, databases, licenses, backups, payment systems, documentation, and post-handover testing.
Overview
Transferring a website is more than sending files or changing a login email. A typical digital asset depends on several connected services, and ownership may be split across a registrar, hosting provider, content management system, email platform, analytics tools, advertising accounts, repositories, payment processors, and third-party subscriptions.
Before closing a sale, acquisition, rebrand, or technical migration, create an inventory of every system that affects the asset. Assign each item an owner, transfer method, deadline, and verification step. Keep a written record of what has been transferred, what remains pending, and who is responsible for resolving access problems.
For a domain-only transaction, the registrar and DNS records may be the main priorities. For a content site, ecommerce store, or SaaS product, the handover can also include customer data, applications, databases, source code, payment settings, operational email, and recurring software licenses. Use this checklist as a base, then remove irrelevant items and add platform-specific tasks.
Transaction planning should also match the payment arrangement. Use the agreed marketplace escrow service or another documented safe payment process, and do not treat a screenshot of a payment or transfer request as proof that funds have cleared. For additional transaction guidance, see the marketplace escrow and secure payment guide.
Checklist by scenario
1. Domain-only transfer
- Confirm the exact domain name, spelling, extension, and registered owner.
- Record the current registrar, expiration date, transfer status, lock status, and applicable authorization requirements.
- Decide whether the domain will move to a new registrar or remain at the current registrar with a change of account ownership.
- Verify that the transfer contact details and destination account are correct before initiating the move.
- Export or document all DNS records, including A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, verification, and redirect records.
- Confirm which services depend on the domain, such as email, subdomains, APIs, certificates, advertising verification, and third-party logins.
- Record the renewal date and enable the new owner to manage renewal, billing, and recovery settings.
Do not cancel the previous registrar account or delete DNS records immediately after a transfer. Keep a controlled transition period so unexpected dependencies can be identified and restored.
2. Website or content business handover
- Create administrator access for the buyer or receiving operator in the CMS, then test that access before removing the previous administrator.
- Transfer hosting control, server access, deployment settings, control-panel access, database credentials, storage buckets, and scheduled jobs where applicable.
- Provide a clean backup of website files and databases, along with instructions for restoration.
- Transfer code repositories, deployment pipelines, environment-variable documentation, and approved production branches.
- Document themes, plugins, extensions, custom scripts, integrations, cron jobs, redirects, forms, and security tools.
- Transfer analytics properties, tag-management containers, search-console properties, advertising accounts, and business-profile access where they are part of the deal.
- Review software and image licenses. Some licenses may be personal, non-transferable, tied to an account, or subject to a new purchase after ownership changes.
- List every recurring subscription, renewal date, billing account, and cancellation dependency.
For an acquisition, compare the technical inventory with the commercial due diligence record. The website acquisition due diligence checklist can help connect operational access with traffic, revenue, ownership, and risk checks.
3. Ecommerce, SaaS, or application transfer
- Identify the store, application, hosting, database, repository, customer-support, and monitoring accounts included in the transaction.
- Transfer payment-provider administration only through the provider's approved process. Do not share personal passwords or retain unnecessary access to customer payment data.
- Document product catalogs, fulfillment settings, tax configuration, shipping rules, webhooks, API keys, and notification addresses.
- Review privacy, data-retention, customer-consent, and access-control obligations before moving customer or employee data.
- Rotate API keys, database passwords, deployment tokens, SSH keys, webhook secrets, and other credentials after the new owner confirms that services work.
- Test account creation, login, checkout, payment confirmation, refunds, transactional email, subscriptions, cancellation, and administrative reporting.
4. Agency, contractor, or internal team handoff
- Replace shared credentials with named accounts and appropriate permission levels.
- Collect documentation, design files, content calendars, issue trackers, deployment notes, and support procedures.
- Confirm who owns domains, code, creative assets, analytics data, and paid tools.
- Remove access from former operators only after the receiving team has verified control and recovery options.
- Record unresolved bugs, planned renewals, technical debt, and known limitations.
What to double-check
Access and authentication
Test every new login in a private browser session or separate device. Confirm that the account uses the correct email address, multifactor authentication method, recovery phone, backup codes, and password manager entry. Remove former owners from administrator groups, delegated access lists, API consoles, support tools, and billing profiles.
DNS and email
Compare the live DNS zone with the documented zone before changing nameservers. Pay particular attention to MX records and authentication records because a website can remain online while business email silently fails. Check subdomains used for staging, support, forms, applications, and APIs. DNS changes may take time to appear across networks, so plan monitoring rather than assuming an immediate global result.
Analytics and search visibility
Confirm that tracking is still firing on key page types and that the new owner can access historical data. Test search-console ownership, sitemap access, robots settings, canonical tags, redirects, structured data, and indexability. Preserve existing measurement definitions where possible, but document any changes so future reports remain understandable.
Backups and rollback
Keep at least one backup made before the handover and verify that it can be opened or restored. Write down the rollback decision maker, restore location, DNS reversal steps, and communication plan. A backup that has never been tested should not be treated as a complete recovery plan.
Payments, licenses, and legal scope
Check whether payment accounts, customer records, trademarks, stock media, fonts, software subscriptions, and advertising profiles are actually included in the agreement. The operational handover cannot transfer rights that the seller does not own or that a provider does not permit to be reassigned. Record exclusions clearly and arrange replacement accounts before the old ones are closed.
Common mistakes
- Transferring the domain but not the DNS. The domain may be registered correctly while email, subdomains, or verification services still point to the former setup.
- Using one shared administrator password. Shared credentials make accountability, recovery, and later access removal difficult.
- Changing everything at once. Staged changes make it easier to identify the cause of an outage and restore the previous configuration.
- Forgetting non-obvious accounts. Monitoring, image delivery, form processing, email sending, backups, repositories, and certificate management are common dependencies.
- Deleting the seller's access too early. Remove access after verification, but retain a documented, limited transition path when the agreement requires support.
- Failing to rotate secrets. Transfer documents can expose credentials. Rotate sensitive keys after confirming the replacement configuration.
- Skipping real-world tests. A homepage test is not enough. Test forms, logins, checkout, email, redirects, analytics, mobile layouts, and critical workflows.
- Ignoring renewal ownership. Record domain, hosting, plugin, certificate, software, and advertising renewals so an overlooked billing date does not interrupt operations.
For domain-specific records and renewal controls, use the domain portfolio management checklist. If the asset is being sold, the domain selling guide also provides related preparation and transfer considerations.
When to revisit
Revisit this checklist before every domain sale, website acquisition, rebrand, hosting migration, major platform change, or seasonal planning cycle. Review it again when a registrar, host, CMS, analytics platform, payment provider, or security tool changes its transfer process or authentication requirements.
At the start of each review, export the current inventory and mark each item as verified, pending, not included, or needs owner confirmation. After the handover, schedule a short follow-up test: review uptime, DNS, email delivery, forms, analytics, search visibility, payments, backups, and access logs. Keep the final checklist with the transaction records and update it whenever a new service is added.
The practical finish line is simple: the new owner can sign in, renew, publish, measure, recover, and operate the asset without the previous owner. If any of those actions still depend on an unlisted account or undocumented person, the handover is not finished.