Moving a website to a new hosting provider is manageable when you treat it as a controlled change rather than a single copy operation. This guide provides a reusable website migration checklist covering inventory, backups, staging, files, databases, DNS, SSL, email, redirects, verification, and rollback so you can change hosting providers with minimal disruption.
Overview
A successful migration has two separate goals: reproduce the site accurately on the new server and switch visitors to it at the right time. Keeping those goals separate makes the process easier to test. You can prepare and validate the new environment before changing DNS, then retain the old hosting account until the new site has passed its post-cutover checks.
Start by identifying what is actually moving. A simple brochure site may require only its files, database, domain DNS, and SSL certificate. A larger WordPress installation, ecommerce store, or developer-managed application may also include scheduled jobs, background workers, webhooks, API credentials, uploaded media, transactional email, search indexes, and third-party integrations.
Record the current configuration before making changes. Your inventory should include:
- All domains, subdomains, aliases, and parked domains associated with the site.
- DNS records, including A, AAAA, CNAME, MX, TXT, and verification records.
- Hosting account details, document roots, runtime versions, extensions, and server settings.
- Databases, database users, table prefixes, connection settings, and scheduled tasks.
- Email mailboxes, forwarding rules, aliases, and the service responsible for receiving mail.
- SSL coverage, redirect rules, caching, firewall settings, backups, and monitoring.
- External services such as payment processors, analytics, forms, CRMs, CDNs, and authentication providers.
For background on the relationship between domains, DNS, hosting, and SSL, see the domain and website launch checklist. If the move is also an opportunity to change infrastructure, compare the operational differences between shared, WordPress, VPS, and cloud hosting before you begin.
Checklist by scenario
For any website migration
- Choose a migration window. Prefer a period with lower publishing, transaction, and support activity. Avoid starting immediately before a launch, campaign, billing run, or other deadline.
- Confirm access. Test access to the current host, new host, domain registrar, DNS provider, database, site administration area, and email administration tools.
- Back up the source. Create a complete, restorable backup of website files and databases. Store a copy outside the current hosting account and confirm that the archive can be opened.
- Prepare the destination. Create the site, database, users, runtime configuration, SSL plan, and required directories on the new host. Match or deliberately document differences in PHP, Node.js, Python, web server, or database versions.
- Copy the site. Transfer files and import the database using a method suited to its size. Preserve permissions where they matter, and check that uploads, generated assets, and hidden configuration files were included.
- Test before DNS changes. Use a temporary hostname, hosts-file override, staging URL, or provider preview method. Check pages, forms, login, search, media, uploads, checkout flows, and administrative actions.
- Lower DNS caching time if appropriate. If you control the authoritative DNS zone, reduce the relevant record's TTL before the cutover. This does not force every resolver to refresh immediately, so keep the old site available during the transition.
- Freeze or repeat final changes. Pause publishing or record a final content-change window. Perform a final database and file sync so changes made after the initial copy are not lost.
- Update DNS. Change only the records required for the website unless you have intentionally planned an email or broader DNS move. Keep a saved copy of the previous zone.
- Monitor and verify. Test the site over the public domain, confirm HTTPS, review logs and error monitoring, and watch important user journeys. Do not cancel the old hosting plan yet.
Moving a WordPress site
A WordPress migration normally includes the document root, the database, the wp-content directory, configuration values, and rewrite rules. Check that the database connection details match the new environment and that the site's configured URL is correct. Confirm that themes, plugins, media, private uploads, and custom mu-plugins were transferred.
After the test copy is available, sign in to the dashboard, view several content types, submit a form, upload a test image, and check scheduled tasks. Review caching and security plugins because they may retain the old hostname, server path, or IP address. If the site uses a staging environment, keep staging and production credentials and indexing controls separate; the staging versus production guide provides a useful operational model.
Moving an ecommerce or transaction-based site
For a store or application that receives orders, registrations, or other user-generated data, a file-only copy is rarely enough. Identify every system that writes data during the migration window. Plan a short maintenance mode or read-only period if needed, then perform a final database sync after new transactions stop. Test product pages, cart and checkout, payment handoff, confirmation messages, tax or shipping logic, account access, and webhooks in the new environment.
Do not assume that a successful homepage test proves the store works. Review the ecommerce hosting checklist for additional security, performance, and operational checks.
Moving email and DNS services
Website hosting and email hosting may be separate services. If mail is staying where it is, preserve the existing MX records and related SPF, DKIM, and DMARC records. If email is moving too, document every mailbox, alias, forwarder, archive, and client configuration before changing MX records. Test both inbound and outbound mail, including messages to external recipients, after the change.
A domain transfer is also separate from a website migration. You can usually move the website while leaving the domain registered with its current registrar. If you intend to transfer the domain, check the registrar's requirements, authorization process, renewal timing, DNS hosting arrangement, and lock status before scheduling the transfer.
What to double-check
- DNS scope: Confirm whether DNS is managed at the registrar, hosting provider, CDN, or a separate DNS service. Changing nameservers can move the entire zone, including email and verification records.
- SSL and canonical URLs: Verify that the certificate covers the production hostname and that HTTP redirects to the intended HTTPS URL. Check canonical tags, sitemap URLs, and any hard-coded old domain references.
- Redirects: Preserve existing permanent redirects and test important old URLs. A migration is not the time to discard URL history without a reason.
- Database and runtime compatibility: Confirm character encoding, database version, extensions, environment variables, file permissions, and maximum upload or execution settings.
- Scheduled work: Recreate cron jobs, queues, backups, reports, cache warmers, and certificate renewals. Verify their time zone and execution user.
- Security controls: Replace temporary credentials, restrict administrative access, review firewall rules, and confirm that backups run on the new platform. See the complete migration checklist for domains, DNS, SSL, and backups for a consolidated review.
- Performance: Compare representative pages, not just the homepage. Check server response time, caching, image delivery, database queries, and asset compression after the move.
Common mistakes
Deleting the old account too soon removes your easiest rollback path. Keep it active until DNS has stabilized and the new environment has passed a normal operating period that fits your site.
Copying files but not the database produces an incomplete site, especially for WordPress, forums, stores, and applications. The reverse problem is also possible: importing a database without its uploads or configuration can create broken media and missing settings.
Changing nameservers without copying the DNS zone can interrupt email, verification services, APIs, and subdomains. Export or manually record the zone before making the change.
Testing only while logged in can hide cache, permission, cookie, and redirect problems. Test in a private browser session and, where possible, from more than one network.
Forgetting hard-coded paths or hostnames can break image URLs, webhook endpoints, cron commands, application secrets, and integrations. Search configuration and database content where appropriate, but make changes only after taking a fresh backup.
Ignoring the rollback plan leaves the team guessing during an incident. Define who can restore the previous DNS records, how the final data will be reconciled, and which symptoms justify rolling back.
When to revisit
Save this checklist with the site's operational documentation and revisit it before seasonal planning cycles, major product launches, traffic events, or planned hosting changes. Update the inventory whenever you add a subdomain, email provider, integration, scheduled task, database, or backup system.
Review the process whenever your hosting control panel, deployment workflow, DNS provider, backup tool, or application stack changes. Tool interfaces and migration methods evolve, but the underlying controls remain consistent: know what exists, preserve a recoverable copy, test before cutover, change DNS deliberately, and verify the real user journeys.
For your next move, create a dated migration record with the inventory, backup location, DNS snapshot, test results, cutover time, named owner, and rollback decision point. That record turns a one-time website migration into a repeatable operating procedure.
