A small business homepage is not just one HTML file. It depends on a domain registration, DNS, hosting, content system, images and licenses, analytics, forms, email delivery, search verification, and accounts that may belong to different people. A safe transfer preserves public continuity while moving control to the new device, tool, or owner in a documented order.
Build an ownership inventory
List the registrar, registrant, DNS provider, hosting account, repository or site builder, content files, image licenses, analytics, Search Console property, form destination, email service, certificates, billing owner, and recovery contacts. Record organization-controlled usernames, not passwords in the inventory. Identify personal accounts that must be replaced and confirm which assets the business actually owns.
Export before changing access
Create a current copy of source files or builder export, media, page text, metadata, redirects, DNS records, environment configuration without secrets, and recent analytics settings. Capture the existing homepage with screenshots and a URL-level checklist. Test the export in a safe location before revoking the old owner's access. Keep secrets in an approved password manager and transfer them through account features rather than email or a shared document.
Handle the domain deliberately
ICANN explains that only the registered name holder, administrative contact, or an explicitly authorized person can initiate certain transfers and that an AuthInfo code is used for inter-registrar transfer. Contact-information changes can also trigger a 60-day transfer lock in some circumstances. Verify the current registrant and recovery contacts before any handoff, document whether the task is an account change, registrant change, DNS change, or registrar transfer, and avoid combining them blindly.
Rebuild and test privately
Set up the new hosting or tool using a preview URL or hosts-file test. Check layout, mobile behavior, accessibility basics, forms, email delivery, analytics, privacy notice, structured data, and error pages. Compare the new page with the inventory rather than relying on memory. Do not point the public domain until the new owner can sign in, deploy, restore a backup, and receive form submissions.
Preserve URLs and search signals
If URLs change, create a one-to-one map from old URLs to their closest new destinations. Google recommends preparing that mapping, using server-side permanent redirects where possible, testing redirects, updating canonical and robots rules, and submitting the new sitemap. It advises keeping redirects for at least a year and avoiding blanket redirects to an irrelevant homepage. If only the owner or hosting changes and URLs stay the same, verify that the content and response behavior remain stable.
Switch control in a recoverable order
Add the new owner and verify recovery methods before removing the old one. Lower DNS time-to-live in advance if appropriate, schedule the cutover, preserve the previous hosting for a rollback window, and record the before-and-after DNS values. Rotate credentials after access is confirmed. Update billing only through the provider's official flow and require the owner to enter payment or identity details.
Complete an acceptance test
From a device not signed in to administrator accounts, load the homepage and key links, submit a test form, verify email delivery, inspect HTTPS, and check analytics or logs. The new owner should demonstrate login, content editing, deployment, backup download, and restoration instructions. Close the handoff with an asset list, unresolved risks, renewal dates, rollback deadline, and signed or written acceptance.
Sources
- 5 Things Every Domain Name Registrant Should Know About ICANN's Transfer Policy — Internet Corporation for Assigned Names and Numbers
- Site Moves and Migrations — Google Search Central