Skip to main content
Migration and Launch

Website Migration and Launch Checklist

Move the website without losing control of the domain, email, forms, search paths, data, or recovery options.

13 minute read Reviewed 2026-08-30 HostAvvy editorial team

A website migration is a dependency project. Files and databases matter, but so do domains, DNS, certificates, email records, forms, analytics, redirects, licenses, scheduled jobs, webhooks, account ownership, backups, and the ability to restore the previous state. Inventory first, then move through a controlled acceptance plan.

HostAvvy growth system view for Website Operations
The guide focuses on the highlighted part of the wider HostAvvy Growth System.
01

Inventory the complete operating surface

Record the current domain registrar, DNS host, nameservers, hosting, control panel, application version, database, email provider, certificate, CDN, forms, SMTP or mail delivery, analytics, tag manager, search verification, call tracking, payment tools, CRM, scheduled jobs, APIs, storage, and licensed components.

For each item, name the business owner, technical owner, access method, renewal date, cost, dependency, and recovery path. Test credentials before the migration window. Do not assume the current provider can recover an account quickly after a relationship ends.

Access

Verify administrator, hosting, database, registrar, DNS, email, analytics, and provider access with business-controlled recovery methods.

Dependencies

Map forms, SMTP, APIs, webhooks, storage, scheduled work, licenses, embeds, fonts, media, and external scripts.

Baseline

Capture current URLs, redirects, metadata, search data, analytics, performance, forms, screenshots, and known defects.

02

Prepare the destination and migration copy

Build the destination with appropriate runtime versions, storage, database settings, HTTPS, access controls, backups, mail handling, and monitoring. Keep it protected from public indexing while testing. Avoid exposing a duplicate production copy on a temporary domain.

Copy files and data using an appropriate method, then update configuration and secrets carefully. Search for environment-specific paths and URLs with structured tools where available. Freeze or reconcile changing data such as orders, bookings, comments, form submissions, and customer records during the final move.

Protected staging

Require authentication and noindex while preserving the ability to test real routes and assets.

Data plan

Choose a content freeze, incremental sync, or final delta method based on how the source changes.

Secrets and permissions

Move credentials through a secure channel, use least privilege, and remove temporary access after acceptance.

03

Test customer and search journeys before cutover

Test the homepage, priority landing pages, navigation, search, forms, confirmation states, email delivery, calls, booking, login, reset, checkout, support, downloads, error pages, and mobile layouts that apply to the site. Use keyboard navigation and representative viewport widths.

Crawl the source and destination. Preserve valid public URLs where practical and map every intentional change to a relevant redirect. Verify canonical URLs, robots directives, sitemap entries, structured data, OpenGraph assets, internal links, status codes, and trailing-slash behavior.

Functional paths

Run complete user journeys rather than checking only whether individual pages load.

Search continuity

Compare URL inventory, status codes, redirects, canonicals, metadata, headings, links, schema, and index controls.

Visual acceptance

Review priority pages at mobile, tablet, laptop, and wide desktop sizes with no clipping or hidden controls.

04

Control cutover, rollback, and the first 72 hours

Lower DNS time-to-live in advance when appropriate, schedule a low-risk window, confirm the decision maker, take final backups, sync changing data, verify destination health, then change only the required DNS records. Preserve email records unless the email service is intentionally moving.

Define rollback triggers before launch. Keep the old environment available and unchanged for an agreed period. After cutover, verify DNS, TLS, forms, email, logs, analytics, search access, critical URLs, jobs, webhooks, and customer actions from outside the administrative network.

Go or no-go owner

One accountable person reviews readiness, accepts known issues, and authorizes cutover or rollback.

Rollback

Document exactly how to restore DNS, application, data, and integrations without improvising under pressure.

Monitoring

Watch errors, availability, form delivery, email, jobs, webhooks, search coverage, analytics, and support reports after release.

Action checklist

Use this before the next decision.

  • Domain, DNS, hosting, email, and application owners are recorded
  • Credentials and recovery methods are tested
  • Current URL and redirect inventory is captured
  • Destination is protected from indexing during testing
  • Forms, email, login, payment, and integrations are tested
  • Mobile and keyboard journeys pass
  • Backups and restoration steps are verified
  • Cutover and rollback owners are named
  • Post-launch monitoring is scheduled
Put It Into Practice

Make the migration a controlled launch, not a last-minute file move.

HostAvvy can help inventory the source, map dependencies, test the destination, and define a recoverable cutover plan.

Build My Growth Plan
A practical place to start

Turn your next business goal into a clear first plan.

Answer six quick questions to see a recommended path, useful supporting services, starting prices, and the next step before sharing contact details.