Inventory domain, hosting and account ownership
Find the domain registrant, registrar and renewal date. The registrar may differ from the website host. Ensure your business can sign in with its own email rather than relying entirely on the former provider's personal account.
Do the same for hosting, CMS, licences, analytics, tag manager and external services. A store may depend on payments, shipping, invoicing and automated emails. A booking site may have separate calendars, alerts and platforms.
Build the inventory first, then agree a secure channel for access or ownership transfers. The aim is to know which accounts the business needs and who keeps them afterwards.
- Domain, registrant and registrar
- DNS directing the domain to website and email
- Hosting, database and CMS
- Analytics, forms and integrations
- Licences, renewals and billing
Get a backup you can actually restore
An image folder is not a complete website backup. Reconstruction commonly needs files, database, configuration and an external-service list. For a closed builder or platform, confirm what can be exported and what must be rebuilt.
Open or restore the backup in a test environment. Record its date, size and restoration method so the new provider can assess whether it is sufficient before an incident.
Keep original copy, uncompressed images, logo and brand files too. They may not be needed for the technical move, but avoid having to recover small website versions for later edits.
- Files and database
- Required configuration and variables
- Extension or module inventory
- Original text and images
- Completed test restoration
Protect business email before changing DNS
Email is easy to overlook because it is not visible inside the website, yet it shares domain settings. Changing DNS without preserving mail records can leave the site working while messages stop arriving.
List the mailbox provider, accounts, aliases, forwarding and automatic replies. Confirm how old messages are retained. Some migrations move mailboxes; others create new ones and need a separate history transfer.
Send and reply from an external account. Check website forms too, as they may use a technical sender different from everyday email. Verify sending and receiving before calling the change complete.
Prepare the migration and rollback
Build the new site or restored copy at a temporary address and test it before changing the domain. Agree each step's owner, timing and the signal that will trigger a rollback. Keeping a recovery route lets you restore service while investigating a fault.
Where appropriate, reduce DNS caching time in advance. The technical owner should decide the value and timing. Avoid improvising on migration day because different networks may show different destinations during propagation.
Choose a window with someone available to test website and email afterwards. Avoid a major campaign, important booking or closing time, when a problem would be left unattended.
- Approved test environment
- Owner for each step
- Agreed change window
- Clear rollback condition
- Backups available on both sides
Validate the website handover before closing accounts
After the move, test key pages and several old addresses. Review forms, search, bookings, payments, downloads and external links. Check the security certificate and visit on mobile and desktop while signed out.
Verify analytics and automated notifications. Sales and enquiries should be recorded in the right place. Check error pages too: a migration may preserve the homepage while losing routes that still receive visitors or bookmarks.
Then remove old access, change shared passwords and cancel duplicate services. Retain backups for the agreed period and leave a final record of ownership, renewals and responsibilities. The next intervention should start from that document.
- Website and email tested externally
- Forms, payments or bookings received
- Analytics and alerts active
- Redirects and old pages checked
- Access and billing closed in order
