A website migration moves your site’s files, database, and supporting services to a different hosting environment. The visible pages are only part of the job: email routing, scheduled tasks, security certificates, and recent customer activity can also be affected.
To transfer website to new host infrastructure safely, prepare a recoverable copy, test the destination, and coordinate the final switch. This guide explains how to protect changing data and preserve a rollback option without assuming that downtime is impossible.
1. Define What Is Moving
List every service connected to your domain before choosing a migration date. Your registrar, DNS provider, website host, and email provider may be separate companies. Moving the website does not automatically require transferring the domain registration or moving email.
- Website: Files, databases, uploaded media, redirects, configuration files, and application secrets.
- Background services: Scheduled jobs, queues, search indexes, external storage, and webhook endpoints.
- Email: Mailboxes, aliases, forwarding rules, and the services that send transactional messages.
- DNS: Records for the main domain, subdomains, mail delivery, verification, and authentication.
- Access: Registrar ownership, hosting administrators, billing contacts, and recovery methods.
Record who controls each account and enable multifactor authentication where available. Confirm that the domain is registered under an account your organization controls. Renewal charges, privacy options, transfer restrictions, and promotional free-domain terms deserve separate review; they are not resolved by buying hosting.
2. Choose a Compatible Destination
Choose by application requirements and operating responsibilities, not just a plan label. For WordPress or WooCommerce, check the official requirements and the destination’s current PHP, database, extension, and resource support. Also check storage, upload limits, background processing, and outbound email restrictions.
“Shared” describes infrastructure; “managed” describes a service scope. A shared plan can include management, while managed hosting may still leave plugin maintenance, content security, or restore testing to you. A VPS offers a different allocation model, but isolation varies and CPU resources may remain shared.
WordPress.com is a candidate for a hosted WordPress environment, subject to plan capabilities and migration compatibility. SiteGround and DreamHost are candidates for conventional hosting arrangements; compare their specific migration assistance, backup retention, and support scope rather than assuming identical services.
DigitalOcean, AWS, Google Cloud, and Azure are candidates when you need more infrastructure control or cloud integrations. Virtual machines such as EC2, Compute Engine, and Azure VMs generally leave more operating-system work to the customer than managed application services. Responsibilities still vary by product and contract.
Dedicated hardware does not automatically deliver better application performance or satisfy compliance requirements. Compare total operating costs, including backups, management, storage, and data egress. Cloud budget alerts should not be treated as hard spending caps.
3. Build a Recoverable Backup
Create a complete backup before making destination-related changes. Include the database and files from a consistent point in time where practical. Copy configuration files and hidden files, which ordinary downloads sometimes miss. Export DNS records and save screenshots of settings that cannot be exported.
Store an encrypted copy outside both hosting accounts. Protect database exports because they may contain personal information, password hashes, and private business records. If email is moving, back up mailbox contents separately and document how folders, contacts, and calendars will be handled.
A successful backup download is not proof of recoverability. Restore the copy into a restricted test environment and confirm that it opens correctly. Record the restore steps and approximate time required. Keep a known-good backup unchanged until the migration has been accepted.
4. Prepare DNS and Email
Find the authoritative DNS provider, then identify the records that must change. Updating only the website’s A, AAAA, or CNAME records often creates less disruption than changing nameservers. Check both IPv4 and IPv6 records; leaving an old AAAA record can send some visitors to the previous server.
If supported, lower the relevant DNS time to live, or TTL, ahead of the move. For example, changing a 24-hour TTL shortly before cutover will not shorten copies already cached for 24 hours. Allow the previous TTL to expire before relying on the lower value.
If nameservers must change, recreate the entire zone first, including MX, SPF, DKIM, DMARC, and verification records. Coordinate DNSSEC changes with the registrar and DNS providers; an incorrect trust configuration can prevent resolution. Website hosting changes should not unintentionally interrupt existing mail delivery.
5. Copy and Test the Destination
Import the files and database using an appropriate host tool, application migration utility, or secure file transfer and database export. Confirm exactly what any “free migration” service includes. Email, custom applications, large databases, and follow-up troubleshooting may fall outside its scope.
Match necessary runtime settings, file permissions, scheduled tasks, redirects, and application environment variables. Keep secrets out of public directories and logs. For WordPress, use migration-aware tools when replacing stored URLs because some database values are serialized and can break with careless text replacement.
Test through a protected staging address or a local hosts-file override that maps the real domain to the new server. A hosts-file override affects only your device and does not validate public DNS. HTTPS still needs a certificate valid for the requested hostname.
- Check key pages, images, downloads, navigation, and mobile layouts.
- Test logins, password resets, forms, search, and file uploads.
- Verify redirects, canonical URLs, analytics, and transactional email.
- Inspect application logs for database, permission, and runtime errors.
Restrict staging access and prevent indexing without carrying those restrictions into production. Disable duplicate scheduled jobs, outbound notifications, and live payment actions during testing. Use payment-provider test facilities rather than creating unintended charges.
6. Plan the Final Data Sync
The first copy becomes outdated as soon as someone places an order, publishes content, or uploads a file. Decide how to capture those changes before switching traffic. A simple brochure site may need only a brief editing freeze; an active store needs stronger write controls.
For a small ecommerce site, schedule a low-activity window, pause checkout and administrative changes, and take a final database export plus any new uploads. Import them at the destination before reopening transactions. More complex systems may need specialist replication and reconciliation rather than a manual export.
Do not cache cart, checkout, or account pages as ordinary public pages. Confirm secure payment integrations, webhook delivery, and session behavior. Hosting assistance does not remove the merchant’s payment-security or compliance responsibilities.
For example, a hypothetical store copies its site Tuesday and schedules cutover Thursday. Thursday’s final synchronization must include orders and uploads created since Tuesday. Leaving the Tuesday database in place would lose those records at the destination, even if the homepage looked perfect.
7. Switch Traffic With a Rollback Plan
Before changing DNS, confirm that the destination has working TLS, accepts the production hostname, and is ready to serve visitors. Certificate issuance methods vary; arrange validation in advance where possible. Then update the intended DNS records and note the exact time and previous values.
Keep the old hosting account operational while cached DNS answers expire and you verify real traffic. Some visitors or integrations may reach the old server during the transition. Control writes there so the two databases do not diverge. Do not promise customers zero downtime.
Define rollback triggers, such as widespread checkout failures or persistent database errors. Restoring old DNS values alone is not always sufficient: new orders or submissions accepted at the destination must be preserved and reconciled before reverting. Avoid overwriting either database without a fresh backup.
Monitor availability, error logs, orders, form submissions, and mail delivery from more than one connection. Compare results with your premigration checks. Keep someone available who can access both hosts and the DNS account.
8. Verify and Retire the Old Host
After traffic stabilizes, restore an appropriate TTL and confirm that production indexing settings are correct. Check sitemap accessibility, redirects, missing pages, and canonical hostnames. A hosting-only move normally should not require changing public URLs.
Enable the destination’s backup schedule and test a restore. Review application updates in staging before production deployment. Remove temporary accounts, rotate migration credentials, and securely delete unnecessary database copies according to your retention needs.
Cancel the old service only after confirming that no website, mailbox, DNS zone, or stored backup still depends on it. Download needed billing records and check cancellation terms first.
Your Cutover Checklist
- Account ownership and recovery access confirmed.
- Files, database, email needs, and DNS inventoried.
- Independent backup restored successfully.
- Destination compatibility, TLS, and functional tests passed.
- Final synchronization and write freeze assigned.
- Old DNS values and rollback criteria documented.
- Postlaunch monitoring and backup checks scheduled.
Frequently Asked Questions
Must I transfer my domain too?
No. You can usually keep your registrar and point DNS to the new host. A registration transfer is a separate process with its own eligibility rules.
How long should hosting overlap?
Keep both services until DNS caches have expired, critical workflows work, and data is reconciled. Allow extra time for troubleshooting rather than canceling immediately after cutover.
Will migration affect search rankings?
Keeping URLs, content, redirects, and accessibility intact reduces avoidable disruption, but rankings are not guaranteed. Watch for accidental indexing blocks, broken links, slow responses, and server errors.
Can a plugin handle everything?
A migration plugin can simplify application copying, but it may not move email, DNS, external storage, or server-level tasks. Check its limits and verify the restored site independently.
Make the Move Reversible
A successful website migration is a controlled transition, not just a file upload. Inventory dependencies, test a recoverable copy, synchronize changing data, and retain the old environment until the new one is verified.
This article provides general information, not individualized security, legal, or compliance advice. Verify current provider terms and application requirements before proceeding.
Official References
- https://www.ftc.gov/business-guidance/small-businesses/cybersecurity/hiring-web-host
- https://wordpress.org/about/requirements/
- https://developer.wordpress.org/advanced-administration/upgrade/migrating/
- https://woocommerce.com/document/server-requirements/
- https://aws.amazon.com/compliance/shared-responsibility-model/
- https://cloud.google.com/docs/get-started/aws-azure-gcp-service-comparison
- https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
- https://www.icann.org/resources/pages/registrant-2013-09-17-en
Featured photo: cottonbro studio / Pexels.
