A website hosting migration moves the system that serves your website. It may also involve databases, email, DNS, certificates and background tasks. The practical objective is to keep customer journeys working and preserve business records while the underlying service changes. A successful copy of the homepage is only one part of that work.
This checklist is for a business coordinating a move with its technical team. It explains the decisions and evidence to request, rather than assuming every hosting platform has the same migration tool. For a detailed operational sequence, also read our hosting migration runbook.
Separate the services being moved
List the website application, uploaded files, databases, mailboxes, outgoing mail service, DNS provider, domain registrar and any external integrations. Record the account owner and authorised administrator for each. A domain transfer changes the registrar relationship; a hosting migration changes where the website runs. These can be coordinated, but they are not the same operation and do not automatically move email.
Record forms, payments, bookings, scheduled jobs, redirects and storage outside the normal website directory. Ask which secrets and environment settings the application needs, then transfer them through an appropriate secure process. A migration tool can copy selected files and databases without reproducing a server's background jobs or a separate email account.
Check migration tools and platform limits
Ask the receiving team what its migration method includes and excludes. Control-panel transfer tools depend on source access, supported versions, package limits and compatible configurations. Obtain a list of unsupported features and manual actions. An automated tool finishing without an error does not establish that a payment callback, custom rewrite rule or mailbox delegation works.
A hosted website builder may offer content exports without an exportable version of the complete website application. Check pages, products, media and design components separately. Where a rebuild is necessary, agree the new information structure and URL treatment before cancelling the old account. Keep a recoverable record of material that cannot be exported through the normal controls.
Create a recovery copy before making changes
Take a current backup of the application files and database, together with the relevant configuration and DNS records. Record when the backup was taken and which environment it belongs to. Verify that the authorised team can read and restore it. A backup stored only inside an account that is about to be closed is a weak recovery arrangement.
Choose who can approve cutover and who can invoke rollback. Define the conditions that would stop the move, such as missing orders or an enquiry form that cannot deliver messages. Specify where new records will be written during the transition. Returning DNS to the old server cannot recover transactions that were created only on the new server.
Handle WordPress URLs and structured data carefully
A WordPress move normally needs its files, database and correct database connection settings. Check the WordPress Address and Site Address values, media locations, redirects, plugin configuration and any custom application code. A temporary preview address may make testing convenient, but it can also change generated links or introduce an address that should never appear in public search results.
Some stored WordPress values use serialisation, which includes information about data lengths. An ordinary text replacement can damage that structure when an address changes. An experienced administrator can use an application-aware search-and-replace method, first making a backup and reviewing a dry run. Avoid changing identifiers merely because they resemble URLs. A Multisite installation needs its own migration plan.
Test the destination before changing DNS
Use the receiving platform's supported preview method or an authorised local hosts-file test. Confirm which environment is being tested and prevent public indexing of a staging copy. Check that forms and payment tests cannot accidentally create real customer transactions. Production credentials copied into a staging environment can produce genuine effects even when the website looks like a harmless preview.
- Open the main service pages and check images, downloads and internal links.
- Submit a controlled enquiry and confirm the right team receives it.
- Test account access, password recovery and essential customer journeys.
- Check the application version, database compatibility and background tasks.
- Test HTTPS, redirects and the final public hostname.
- Confirm monitoring and backup arrangements on the destination.
Plan the final data copy and cutover
An initial copy can become stale while the live website continues accepting orders or enquiries. Agree whether the application will briefly stop writes, synchronise changes or use another supported method. Record the point at which the destination becomes the authoritative system. Check totals and important sample records after the final copy, including relationships between records rather than only their headline count.
Change only the DNS records required by the agreed move. Lowering a TTL in advance can shorten later caching, but an earlier cached answer may remain until its existing lifetime expires. Keep the old service available for the agreed overlap period. Check website and email routing separately, using more than one ordinary visitor connection.
Verify email and search continuity
If mailboxes are moving, treat message history, delivery, aliases and account permissions as a separate workstream. An IMAP copy may not transfer calendars, contacts or rules. If email is staying where it is, preserve its MX and authentication records. Check outgoing website mail as well as staff mailboxes, because a form can store a message successfully while its notification fails.
When public URLs stay the same, preserve their normal response behaviour and inspect indexing signals after cutover. When URLs change, prepare an explicit old-to-new mapping and appropriate permanent redirects. Check the sitemap, canonical addresses and important campaign links. Do not assume changing hosting requires changing the domain or every URL.
Close the old account only after acceptance
Document the checks completed, unresolved issues and the team taking over support. Retain authorised recovery access until the overlap and recovery requirements are satisfied. Confirm cancellation notice, retention and export deadlines through your own contract. Closing an old hosting account can remove website copies, mail or backups that the team still needs.
For hosting and domain support, visit Giraffe Hosting. If the move forms part of a rebuild, Giraffe Digital's website design service can connect technical migration decisions with page structure, content and enquiry journeys. The useful handover is a tested service with clear ownership, not simply a transferred folder.
