A website hosting migration checklist for business owners

Inventory the site and the services around it

Start with the public domain, current host, website platform and the person responsible for each account. Identify whether the site uses a database, uploaded files, scheduled jobs, custom server rules or connections to third-party services.

Also list the services people depend on beyond the homepage: inquiry delivery, bookings, payments, customer logins and downloadable files. Write down the current behavior so the destination can be checked against it. Do not copy account passwords or private customer data into a planning document.

• Website files, database and uploaded media
• Application and server requirements
• Domain registration and DNS management
• Email provider and any other services using the domain
• Forms, scheduled tasks and external integrations

Keep email and domain changes explicit

A domain can direct web traffic and email to different providers. Changing where the website is hosted is therefore a different decision from moving mailboxes. Record what is changing and what should remain with its current provider.

Before changing DNS, have the person managing the move review the existing records and retain the ones needed by email and other services. Ask who will make the changes and how the website and email will be checked afterward. Do not assume a hosting provider will handle services that are outside the agreed migration scope.

Further reading: Cloudflare: how email depends on DNS records

Define the backup and rollback plan

Ask what will be backed up, where it will be kept and how it can be restored. Website files alone may not include the information stored in a database. A backup is useful only if the team understands what it contains and how to use it.

Agree on the problems that would trigger rollback and who makes that decision. If the site accepts orders, submissions or content changes during the move, the plan also needs to account for new information arriving at the old or new system. Returning to an older copy without that consideration may lose recent changes.

• Identify everything required to restore the current site
• Keep the current service available for the agreed transition period
• Set a content freeze or data-transfer approach if needed
• Name the decision-maker and rollback checks

Check the destination before switching traffic

Use an appropriate preview or test setup to review the destination. Check key pages on a phone and desktop, follow navigation links and verify that images and downloads load. Inspect the agreed forms and integrations with controlled test data.

Treat the visible success message and the downstream result as separate checks. For an inquiry form, the migration plan should define how accepted submissions and intended delivery are verified. For payments or bookings, use supported test methods rather than creating unintended real transactions.

• Key pages, navigation and redirects
• HTTPS and the intended domain behavior
• Forms and required integration outcomes
• Images, downloads and access-controlled areas
• Permissions and configuration needed by the application

Confirm responsibility after the switch

Choose a change window with the business’s needs in mind and discuss any expected interruption. The migration method and application determine what disruption is possible; a plan should not rely on an unsupported promise of zero downtime.

Afterward, recheck important customer tasks on the public domain. Record who owns ongoing hosting, backups, software maintenance and support. Do not cancel the old service until the agreed checks, transition period and data-retention needs are satisfied.