Migrating a website to a new host means moving the files, databases and any hosting-dependent services to a different server or provider while keeping disruption as low as possible. A successful host-to-host migration is mostly about sequencing: build the destination copy, test it before changing DNS, then switch traffic only after the important services work.
This guide covers a general website migration. If the site runs WordPress and you specifically want to use the All-in-One WP Migration plugin, use our WordPress migration guide instead.
Website Migration Checklist
Before you move anything, record what the current hosting account actually provides:
- website files and document roots,
- databases and database users,
- domains and subdomains,
- DNS records,
- email accounts and mail routing,
- SSL certificates,
- redirects and rewrite rules,
- scheduled tasks and cron jobs,
- application versions and extensions,
- third-party integrations, APIs and analytics tags.
The visible website is only one part of the migration. Missing an MX record, scheduled task or application dependency can break a service even when the homepage itself loads correctly.
1. Back Up Files and Databases
Create a complete copy of the website files and export each required database. Keep the recovery copy somewhere separate from the hosting account being migrated.
If email is hosted on the same account, make a separate plan for mailboxes and messages. Copying website files does not move email automatically.
Do not cancel the old hosting account at this stage. It is your fallback while the destination site is being tested.
2. Prepare the New Hosting Environment
Set up the destination account and match the software requirements of the existing website. Check runtime versions, extensions, database engines, storage, permissions, document roots and SSL support.
A website can fail after migration even when every file was copied correctly if the new server uses an incompatible runtime or misses a required module.
If you are choosing a destination for a shared-hosting website, review the current web hosting plans for live limits and included features rather than relying on plan details inside a migration tutorial.
3. Transfer the Website Files
Transfer the site through a method appropriate to the hosting environments, such as SFTP, SSH, a control-panel file manager, a migration utility or a provider-assisted process. Prefer encrypted transfer methods where available.
Preserve the directory structure and include hidden configuration files that the application requires. For larger sites, compare file counts or archive sizes where practical so an incomplete transfer is easier to detect.
4. Move and Reconnect the Database
Export the database from the source server and import it into the destination database. Create the required database user and permissions, then update the application configuration with the destination database name, username, password and host value.
For large databases, a command-line or hosting-panel import may be more reliable than a browser upload that can time out. If the application reports a database error, check the exact credentials, permissions, server address and database compatibility before changing unrelated settings.
5. Test the New Website Before DNS Changes
Do not point normal visitors at the new server before testing it. Depending on the provider, you may be able to use a preview address, staging URL or a local hosts-file entry.
Test at least:
- homepage and high-value landing pages,
- navigation and internal links,
- images, downloads and static assets,
- forms and email notifications,
- user login and account areas,
- site search,
- payment or checkout flows in a safe test mode,
- redirects, canonical tags, robots.txt and XML sitemaps,
- analytics and consent/tag loading,
- API callbacks and external integrations.
If the destination uses a temporary hostname during testing, make sure temporary URLs are not left inside production content, canonical tags or redirects after the move.
6. Plan Email Separately
Email migration deserves its own checklist. If email remains with the old provider, preserve the records required by that mail service. If email is moving, create the destination mailboxes, plan message migration where needed and update MX, SPF, DKIM and DMARC records carefully.
Our guide to email with your own domain explains the difference between the domain and the email-hosting service and covers the main authentication records.
Do not change email DNS simply because the website hosting is moving. Website and email can use different providers.
7. Confirm SSL Before Switching Traffic
Make sure the destination can serve the required domain and subdomains over HTTPS before forcing traffic to the new server. Check certificate validity and mixed-content warnings.
If the browser later reports a certificate or mixed-content problem, use the diagnostic steps in our Connection Is Not Secure guide.
8. Update DNS After Testing
Once the destination copy is stable, update the DNS records that control website traffic. Different resolvers may retain cached DNS answers for different periods, so the old and new servers can both receive visitors during the transition.
Keep the source environment available while the change settles, and avoid editing two independent copies of the website at the same time. Otherwise new content or transactions can be split between servers.
9. If the URLs or Domain Are Changing, Treat That as a Separate SEO Migration
A hosting move does not necessarily require URL changes. If the public URLs remain the same, keep them the same where possible.
If you are also changing the domain, protocol or URL paths, create an old-to-new URL mapping and use direct server-side permanent redirects to the final destinations. Google’s current site-move guidance recommends permanent server-side redirects such as 301 or 308 and advises avoiding redirect chains. See Google Search Central’s site-move documentation for URL-changing migrations.
Do not redirect unrelated retired URLs to the homepage simply to avoid a 404. Redirect only when there is a genuinely equivalent destination.
10. Monitor the New Host After the Switch
After DNS begins directing traffic to the destination, monitor server logs, uptime, forms, email delivery, application errors, analytics and third-party integrations.
Keep the old host available until you have confirmed that:
- visitors consistently reach the new environment,
- forms and transactions work,
- email dependencies are correct,
- scheduled tasks and cron jobs run,
- analytics records expected traffic,
- automated backups work on the destination.
Then create a fresh backup of the working destination site and document the new environment before closing the previous hosting service.
Frequently Asked Questions
How do I migrate a website to a new host?
Back up the files and databases, prepare a compatible destination server, transfer the site, reconnect the database, test the destination privately, verify SSL and email dependencies, then update DNS and monitor the new environment.
Should I change DNS before testing the new site?
No. Test the destination copy first. DNS should be changed only after the important pages, forms, databases and integrations work on the new server.
Do I need to change my website URLs when changing hosting?
Usually not. A hosting provider can change while the same domain and page URLs remain in use. URL changes create a separate SEO migration and need redirect planning.
How long should I keep the old hosting account?
There is no universal number of days. Keep it available until traffic is consistently reaching the destination and website, email, scheduled tasks, integrations and backups have been verified.
Does moving website hosting automatically move email too?
No. Email can be hosted separately from the website. Review mailboxes, MX records and email-authentication records before changing or cancelling the old hosting service.