Moving a website to new hosting is manageable when it is treated as a controlled infrastructure change rather than a single upload. This hosting migration guide provides a reusable workflow for planning the move, protecting data, keeping DNS and email aligned, validating SSL and application behavior, and monitoring the site after launch. Use it as a website hosting transfer checklist, then revisit the monitoring steps monthly or quarterly.
Overview
A successful migration has two goals: reproduce the site correctly on the destination server and reduce the time that visitors, search engines, and email systems can encounter inconsistent information. The safest approach is to keep the existing website online while the new environment is prepared, tested, and made ready to receive traffic.
Before choosing a migration method, document the current environment. Record the domain names, DNS records, PHP or runtime versions, database engine, scheduled jobs, storage paths, SSL certificates, transactional email settings, third-party integrations, and any server-level rules. For WordPress, include active plugins, themes, media storage, administrator accounts, and configuration values stored outside the database.
The destination should match the application’s practical requirements. Shared hosting may be suitable for a small site with predictable needs, while cloud hosting or VPS hosting for developers may be more appropriate when you need isolated resources, custom services, containers, background workers, or deployment automation. The hosting type matters less than whether the new environment can run the application reliably and be maintained by the responsible team.
For a broader preparation sequence, see How to Migrate a Website to a New Host: Complete Pre-Move Checklist. If the domain itself is moving between registrars, treat that as a separate workstream and review How to Transfer a Domain Without Downtime.
What to track
1. Inventory and access
Maintain a migration sheet with the current host, destination host, server IP addresses, DNS provider, registrar, database credentials, deployment credentials, control-panel access, and support contacts. Do not store passwords in a shared spreadsheet. Use an approved password manager and confirm that at least two responsible people can access the required systems.
List every hostname, not just the main domain. Include the www version, subdomains, staging environments, API endpoints, asset domains, mail hostnames, and any service used for webhooks. A forgotten subdomain can continue pointing to the old server or expose an incomplete application after the main site has moved.
2. Backups and rollback materials
Take a complete website migration backup before changing anything. For a database-driven site, back up the database separately from uploaded files and application code. Retain the original backup until the new site has passed testing and the agreed rollback window has ended. Verify that the files can be opened and that the database can be restored to a test location; a backup that has never been checked is an assumption, not a recovery plan.
Define rollback criteria in advance. Examples include failed checkout or login flows, missing media, broken email delivery, severe error rates, or an inability to restore the database. Record who can make the rollback decision and how DNS will be returned if necessary.
3. DNS, SSL, and email
Export or record the current DNS zone before migration. Track A and AAAA records, CNAME records, MX records, TXT verification records, and any service-specific entries. Lowering DNS TTL before a move may help some resolvers refresh sooner, but it does not guarantee immediate propagation everywhere.
Plan SSL before switching traffic. Confirm which hostnames need certificates, whether the destination supports automatic issuance, and whether HTTP redirects to HTTPS work after installation. The guide How to Set Up SSL in cPanel covers a common control-panel workflow. Also review certificate scope if the site uses subdomains; Wildcard SSL vs Single-Domain SSL vs Multi-Domain SSL explains the differences.
Email needs its own continuity check. Preserve MX and related authentication records unless the mail service is intentionally changing. Test inbound mail, outbound mail, contact forms, password resets, and application notifications. Web hosting and email hosting may be separate services, so do not replace mail records simply because the website is moving.
4. Application behavior
Before launch, test the homepage, key landing pages, forms, authentication, search, payments where applicable, file uploads, administrative functions, scheduled tasks, redirects, robots.txt, XML sitemaps, and analytics or consent integrations. Compare representative URLs against the old site, including pages with query strings, trailing slashes, non-ASCII characters, and legacy paths.
Use a staging environment where possible. Keep staging protected from public indexing and clearly separate its credentials and data from production. The article Staging vs Production Environments provides a useful framework for that separation.
Cadence and checkpoints
A migration is easier to control when it has explicit checkpoints rather than one large launch task.
- One to two weeks before the move: inventory the application, confirm destination capacity and runtime compatibility, check backup restoration, and identify integrations that need allow-list changes.
- Several days before the move: build the destination, copy the site, configure the database, install SSL, recreate scheduled jobs, and complete a first functional test. Record any differences rather than relying on memory.
- Immediately before cutover: take a fresh database and file backup, place the application in maintenance or read-only mode if necessary, and confirm that the DNS zone and rollback instructions are available.
- At cutover: apply the final data sync, update only the intended DNS records, and note the exact time of each change. Avoid unrelated configuration changes during this window.
- After cutover: test the live domain over HTTPS, check forms and email, review logs, verify redirects, and watch resource usage. Keep the old environment available until the site is demonstrably stable.
For larger applications, use a deployment or synchronization method that can repeat the final file and database transfer. For WordPress, pause content editing during the final sync or use a process that accounts for posts, orders, comments, and other records created during the migration window.
How to interpret changes
Not every post-migration difference indicates a hosting failure. DNS results can vary while resolvers refresh, and caches may temporarily serve older assets. Interpret symptoms by scope and timing.
- Only some users see the old site: compare DNS responses from multiple networks and confirm that both the apex domain and www hostname point where intended.
- HTTPS warnings appear: check certificate coverage, the served certificate chain, redirects, and mixed-content references to old HTTP assets.
- Pages load but forms fail: inspect application logs, mail settings, environment variables, firewall rules, and third-party API allow-lists.
- Pages are slow or return server errors: review runtime versions, database connectivity, resource limits, error logs, cron jobs, and cache configuration before assuming that the host is the sole cause.
- Search traffic or indexed URLs change: check status codes, canonical tags, robots.txt, XML sitemaps, redirects, and whether staging protections were accidentally carried into production.
Keep a short incident log containing the symptom, affected hostname or URL, time observed, evidence checked, and corrective action. This makes recurring problems easier to distinguish from one-time propagation or cache behavior.
When to revisit
Review this migration record at least monthly during the first few months after a move, then quarterly as part of normal infrastructure maintenance. Revisit it sooner when the application changes runtime versions, adds a subdomain, introduces a new email or payment provider, changes DNS management, or moves from shared hosting to a cloud or VPS environment.
At each review, confirm that backups still complete and can be restored, SSL certificates cover every active hostname, DNS records match the documented architecture, scheduled jobs run, storage and database growth remain acceptable, and monitoring still reaches the production endpoints. Check a sample of important URLs and test a real form or notification path rather than relying only on a green uptime check.
Finally, update the rollback plan whenever the old host is retired, credentials change, or the application gains a new dependency. A migration is complete only when the new environment is documented, observable, recoverable, and understood by the people responsible for operating it.
