A hosting migration is a change to a live business system. It can affect website files, databases, enquiry forms, scheduled tasks, email and the DNS records that connect them. Copying the website successfully is only one part of the work. The migration is complete when visitors can use the right website, enquiries reach the right team and the business knows how to recover if something fails.
A hosting migration runbook turns that change into an ordered set of actions, checks and decisions. It records who performs each step, what evidence proves success and when the team should pause or roll back. For a small brochure website, the document may be short. For a website receiving bookings, orders or customer uploads, it should account for changing data and dependencies across several systems.
Separate hosting, domain registration, DNS and email
These services may appear in one control panel, but they perform different jobs. Hosting runs the website. The registrar administers the domain registration. DNS tells other systems where to find services associated with that domain. Email hosting handles mailboxes or email delivery. Moving one does not automatically require moving all four.
Write down which parts are changing. If the website is moving but Microsoft 365 email is staying where it is, the migration plan should preserve the relevant email records. If nameservers are changing, the new DNS zone must contain every required record, not only the record for the website.
A website supplier may offer to transfer the domain as part of the move. Treat that as a separate decision with its own access and timing requirements. Do not assume a registrar transfer is necessary simply because website hosting is changing.
Giraffe Digital's digital strategy service includes planning across hosting, domains, email and tools. Mapping those dependencies before the migration makes the sequence easier to understand and reduces avoidable disruption.
Build an inventory before choosing the migration method
Record what the current environment contains and what must be reproduced. Include the website platform, relevant software versions, database, media files, redirects, scheduled tasks and any services that receive data from the site. Identify storage outside the main website directory, including private uploads where applicable.
Next, list the website's important business journeys. For a service business, that might be browsing service pages, submitting an enquiry and receiving confirmation. For a booking website, it also includes availability checks, payment where applicable and appointment notifications.
- Access: confirm authorised access to the old host, new host and DNS administration.
- Configuration: record the settings the application depends on without placing passwords in a shared runbook.
- Data: identify files and records that continue to change while the website is live.
- Integrations: list CRM connections, mail services, analytics, payment tools and other dependencies.
- Ownership: assign a person to approve the change and a person to make each technical update.
A provider's migration tool can reduce the work involved in copying a site, but you still need to understand its scope. For example, 20i documents its migration options for website files, databases and mailboxes. Confirm which parts of your own setup are covered and which require separate work.
Take recoverable backups and record the starting state
Before making changes, create a backup that includes both website files and the relevant database. Store a copy independently of the environment you are changing. Record when it was taken and how it can be restored. A backup file is useful evidence only when the team understands the recovery process.
Capture the current DNS records, redirects and important configuration details. These records help identify what changed if a problem appears later. Keep sensitive credentials in the appropriate password or secrets system and refer to their location rather than copying them into the runbook.
Test restoration where practical, especially if the migration involves a business-critical application. Confirm that the restored copy contains the expected content and can run in the intended environment. A successful download is not the same as a successful restore.
Also record the current website's known problems. If a form already behaves incorrectly or a particular page is slow, note it before migration. That prevents an existing issue being mistaken for a fault introduced by the new hosting.
Prepare the new environment without redirecting visitors to it
Create the destination environment and confirm that it meets the application's requirements. Compare software compatibility, database support, file permissions and scheduled task capabilities. A hosting package that can store the files may still differ in ways that affect how the application behaves.
Copy the website and its database using the agreed method. For WordPress, be careful with configuration and stored URLs, particularly when testing through a temporary address. The official WordPress migration handbook explains platform-specific considerations. Use methods that preserve structured application data rather than treating every stored value as ordinary text.
Test the destination through a suitable preview method, such as a provider preview facility or an authorised local hostname mapping. Confirm that the method reflects the live domain sufficiently for the checks you need. A temporary URL can change how cookies, redirects or integrations behave.
Keep the preview environment away from public indexing and restrict access when it contains non-public information. These controls are part of preparing a realistic test environment, not a substitute for testing the customer journey.
Test enquiries and integrations before testing appearance alone
A website can look correct while silently losing enquiries. Make the first test a complete customer task. Open a service page, follow the contact route, submit representative information and confirm that it reaches the expected destination.
Check both website behaviour and the systems behind it. Does the confirmation page appear? Does the notification arrive? Is the sender configured appropriately? If the form creates a CRM record, does that record contain the correct service interest and source information?
Use approved test details and identify submissions clearly as tests. If a live payment or booking system is involved, coordinate a suitable test route with the relevant provider and business owner. Avoid assuming that a visually successful response proves the back-end action occurred.
Then check page content, downloads, image loading, redirects, secure connections and editing tasks. Include representative mobile journeys. Record results against specific checks rather than writing “website tested” as one undifferentiated tick.
Plan the final data copy and cutover window
The first website copy may be out of date by the time you switch hosting. Content edits, form submissions, customer accounts or orders can continue changing on the old system. Your runbook must explain how the final version will be captured and when writes will be paused if necessary.
Choose a migration window based on business activity and staff availability. The quietest hour is not useful if nobody can verify enquiries or make a recovery decision. Tell the relevant team what is changing and how to report unexpected behaviour.
DNS time-to-live, or TTL, influences how long a resolver may retain a record. Lowering the TTL before a planned change can help new answers be picked up sooner, but an earlier cached answer may remain until its existing lifetime expires. Changing the TTL at the moment of cutover does not erase that earlier cache. Cloudflare's TTL explanation provides useful background.
Record the exact DNS records being changed and the intended new values. If only the website is moving, avoid making unrelated email changes at the same time. Smaller, deliberate changes are easier to verify and reverse.
Give rollback a practical definition
“We can switch back” is not a complete rollback plan. Define the conditions that trigger it, who approves the decision and what happens to information created after cutover. Examples might include failed enquiries, unavailable customer journeys or an integration that cannot be repaired within the agreed window.
Keep the previous environment available for an appropriate transition period. However, do not allow two active copies to accept changing business data without a deliberate reconciliation method. That can create conflicting bookings or records that exist on only one system.
If you reverse a DNS change, some visitors may still reach the destination temporarily because of cached answers. Your team needs a clear response for that overlap. For a changing application, recovery may require a controlled data reconciliation rather than simply pointing visitors back to an older database.
Practise the decision sequence in a short discussion before migration day. Ask what the team will do if a test enquiry fails, if an administrator cannot access the new site or if the new host becomes unavailable. Resolve responsibilities while there is time to think.
Verify the live change from several useful perspectives
After cutover, check the public website and its important journeys again. Verify the secure connection, expected content, enquiry delivery and integrations. Confirm that the DNS answers are appropriate and that the website is reaching the intended environment.
Check from more than one relevant network or device where practical. Different cached DNS answers can make a change appear complete to one person while another still reaches the previous environment. This is a reason to collect evidence, not to assume every inconsistency is a new server fault.
Review redirects and important search landing pages. A hosting move should not unexpectedly change URLs, remove content or create duplicate public versions. If the move is combined with a redesign, maintain a separate URL and content change plan.
Giraffe Digital's SEO service connects technical checks with useful page structure and search intent. That is particularly relevant when migration work overlaps with changes to the website itself.
Close the migration only after monitoring and handover
Agree a monitoring period appropriate to the website and its normal trading pattern. Review error reports, successful enquiries, scheduled jobs and customer feedback. A task that runs weekly will not be proved by a check performed only on launch afternoon.
Update the technology register, backup arrangements, access records and support contacts. Remove temporary test configurations when they are no longer needed. Confirm that future renewals and alerts reach the right people.
Before closing the old hosting account, verify that no required mailboxes, files or services remain there and that the retained backups meet the business's needs. Record the business owner's sign-off and the evidence used to make that decision.
A successful hosting migration is therefore more than a new control panel and a website that loads. It is a controlled change with tested customer journeys, clear responsibilities and a usable recovery route. Build the runbook around those outcomes, and the move becomes easier to manage even when several suppliers are involved.
