Your host renewal invoice just doubled. Or your site crawled to a stop last week during a traffic spike, and support took six hours to answer a ticket. Either way, you’re wondering the same thing: can you actually move your website to another host without breaking it?
Yes — you can move your website to another host, and in most cases you can do it with zero downtime and no lost SEO rankings, as long as you follow the right sequence. The risk isn’t in changing hosts; it’s in skipping steps like the database export, the hosts-file test, or the DNS cutover plan.
This guide walks through exactly how to migrate a website to a new host in 2026 — manually or with a plugin, with a zero-downtime DNS strategy, and a checklist of the mistakes that most commonly break sites mid-move.
Can you move your website to another host?
Yes. Your website’s files, database, and domain name are three separate things, and none of them are locked to a single hosting company. You can copy your files and database to a new server, point your domain there, and your old host never has to know until you cancel the plan.
The domain registration and the hosting account are also independent. You can switch web hosting companies while keeping the exact same domain name, email addresses, and URL structure — visitors won’t notice anything changed except a faster (or more reliable) site.
The only scenario where this gets genuinely complicated is a large WooCommerce store with thousands of orders processing in real time, or a multi-region setup — those benefit from professional help, which we’ll cover further down.
What do you need before migrating?
Before you touch anything, gather these five things. Missing even one is the most common reason migrations stall halfway through.
- Full backup of your files and database (not just a partial one — verify it includes
wp-content/uploads) - FTP/SFTP credentials for both the old and new host
- Database credentials — host, database name, username, password
- A staging or temporary URL on the new host to test before DNS cutover
- List of every email account tied to your domain, so you don’t lose mail mid-move
If you’re on WordPress, also export your wp-config.php settings separately — you’ll need to update the database constants on the new server, and having the original values on hand prevents guesswork.
Web Help Agency’s WordPress website migration service handles this entire checklist for clients who’d rather not manage credentials across two hosting dashboards themselves.
How do you migrate a website step by step?
Here’s the full walkthrough, in order. Skipping ahead — especially step 6 — is where most self-managed migrations go wrong.
1. Choose and set up your new host
Sign up with the new provider and, if it uses cPanel, add your domain as an addon domain so the account structure matches what you’re moving. If you manage multiple sites, this step is where most people forget a subdomain.
2. Take a full backup of your current site
Back up files and the database together, as a single dated archive. Store a copy somewhere outside both hosting accounts (local drive or cloud storage) — this is your rollback plan if anything goes wrong later.
3. Transfer your files via SFTP
Connect to your old host with an SFTP client (FileZilla, Cyberduck, or your terminal), and download the full site directory. Then upload it to the new host’s file structure. For large sites, a direct server-to-server transfer is faster than routing through your local machine — most hosts support this if you provide both sets of credentials.
4. Export your database
In phpMyAdmin or your host’s database tool, export the full database as a .sql file. Compress it before downloading — an uncompressed export on a content-heavy site can run into hundreds of megabytes and time out mid-download.
5. Import the database on the new host
Create a fresh, empty database on the new host, then import your .sql file into it. Most cPanel hosts include a MySQL import wizard for this; command-line users can run the import directly via mysql -u user -p database_name < backup.sql.
6. Update configuration files
This is the step the old version of this guide glossed over, and it’s where sites most often break. Update wp-config.php (or your CMS’s equivalent config file) with the new database name, username, password, and host. If your old and new database host values differ, the site won’t connect at all until this matches exactly.
7. Test on the new host before DNS cutover
Don’t point your domain yet. Instead, edit your computer’s hosts file to temporarily map your domain name to the new server’s IP address — only your machine sees the new site while everyone else still sees the old one. Browse every key page, submit a test form, and check that images and the admin dashboard all load correctly.
8. Lower your DNS TTL and cut over
At least 24–48 hours before cutover, lower your DNS Time To Live (TTL) to 300 seconds (5 minutes) at your current DNS provider. This tells the internet’s DNS resolvers to check for updates far more often, so when you do switch, the change propagates in minutes instead of up to 48 hours. Once TTL has had time to take effect, update your A record (and any CNAME/MX records) to point to the new host.
9. Verify everything post-cutover
Once DNS has propagated, revisit every page, test checkout or contact forms, confirm SSL is active on the new host, and send a test email to make sure mail delivery still works. Only cancel the old hosting account after a full week of stable operation on the new one.
WordPress-specific migration path: plugin vs. manual
If you’re running WordPress, you don’t have to do steps 3–5 by hand.
| Method | Best for | What it does |
|---|---|---|
| Duplicator | Most WordPress sites | Packages your files and database into one installer bundle; you run the installer on the new host and it rebuilds the site automatically |
| All-in-One WP Migration | Sites under a few GB (free tier caps export size) | Exports a single archive file you import through the plugin on the destination site |
| Host-native migration tools (e.g., automated site transfer offered by managed hosts) | Moving to a specific managed WordPress host | The receiving host pulls your site directly using your old host’s credentials — little to no manual work |
| Manual SFTP + database export | Custom builds, headless setups, non-standard file structures | Full control, but every step in the walkthrough above is on you |
Plugins solve steps 3, 4, and 5 in one action, but you still need to handle the DNS cutover and post-migration checks yourself — no plugin does that part for you.
If your site runs on a multisite network, plugin-based migration gets considerably trickier because subsites share one database with prefixed tables. Our WordPress Multisite guide breaks down what’s different about backing up and moving a multisite install.
How do you switch hosts without downtime?
Zero-downtime migration comes down to one principle: your old site stays live and serving visitors the entire time you’re setting up the new one.
- Build and test the new site on a temporary URL or via the hosts-file trick above — never take the old site offline to “make room.”
- Lower DNS TTL to 300 seconds at least a day before cutover, so the eventual switch propagates fast.
- Cut over during your lowest-traffic window (check your analytics for this — for most B2B sites it’s late night in your primary market’s timezone).
- Keep the old host’s account active and unchanged for at least a week after cutover. If DNS hasn’t fully propagated everywhere, some visitors will still land on the old server — it needs to keep working correctly during that window.
- Monitor uptime with a free tool (UptimeRobot, Pingdom) during the propagation window so you catch any issue within minutes, not days.
Done this way, visitors never see an error page, a maintenance screen, or a gap in service.
Common pitfalls that break migrations
- Forgetting email hosting. If your email runs through the same host (common with cPanel email accounts), migrating DNS without a plan for MX records kills your inbox the moment you cut over. Decide before migration day whether email moves with you or stays on a separate provider (Google Workspace, Microsoft 365).
- Losing your SSL certificate. A certificate issued by your old host doesn’t travel with you. Confirm SSL is active and forced (HTTPS redirect working) on the new host before you cut over DNS, not after.
- Hardcoded URLs in the database. WordPress stores your site URL directly in the database in multiple places. If your old site used
http://or a different domain structure, a straight file copy without a search-and-replace pass will leave broken links and mixed-content warnings scattered across your content. - Ignoring redirects and .htaccess rules. Any custom redirects, security rules, or rewrite rules living in
.htaccessneed to be copied deliberately — they don’t automatically travel with a file transfer if you’re rebuilding the server configuration from scratch. - Skipping the backup of the backup. Keep your pre-migration archive somewhere completely outside both hosting accounts. If migration goes wrong at step 6 or 7, this is what lets you roll back in minutes instead of rebuilding from memory.
Keep your host or switch? A quick decision note
Not every performance complaint means you need a new host. Before you commit to a migration, rule out the cheaper fix first.
Keep your current host and optimize if:
- Your site is slow, but you haven’t run caching, image compression, or a CDN yet — see our page speed optimization guide for the fixes that often solve “my host is slow” complaints without a migration at all
- Support has been fine, and your only complaint is price — many hosts will negotiate renewal pricing if you call and mention you’re evaluating alternatives
- You’re on shared hosting and traffic has grown, but a simple plan upgrade with the same provider resolves the resource limits
Switch hosts if:
- You’re hitting resource caps (CPU, memory, concurrent connections) that no plan upgrade with your current provider fixes
- Uptime has been unreliable over multiple months, not just a single bad week
- You need features your current host doesn’t offer — staging environments, proper WooCommerce support, managed WordPress caching, or better security hardening
- Ongoing maintenance and monitoring aren’t happening, and issues keep resurfacing — our WordPress site maintenance services cover exactly this gap for sites that have outgrown ad hoc fixes
When should you get help instead of migrating yourself?
Migrate it yourself if you’re comfortable with FTP, database tools, and DNS settings, and your site is a standard WordPress build under a few gigabytes. The plugin-based path above will get most small business sites moved in an afternoon.
Get help if any of these apply: you run a live WooCommerce store where an hour of downtime costs real revenue, your site uses custom code or a headless/multisite setup, you’ve never touched DNS records before, or you simply don’t have a spare afternoon to babysit a cutover. A botched migration that takes a site offline for two days costs far more in lost traffic and rankings than a professional migration would have.
Web Help Agency’s WordPress website migration service handles the full walkthrough above — backup, transfer, DNS cutover, and post-migration verification — so nothing falls through the cracks on migration day.
Frequently Asked Questions
Yes. Your website’s files, database, and domain are independent of any single hosting provider, so you can copy them to a new host and repoint your domain without losing your existing URL, content, or email addresses.
Yes — your domain registration is separate from your hosting account. You keep the same domain name through the entire move; only the DNS records need to be updated to point to your new host’s server.
Set up and fully test your site on the new host first (using the hosts-file trick or a staging URL), lower your DNS TTL a day in advance, then cut over during low-traffic hours while keeping the old host active for about a week as a safety net.
Yes, and it’s often easier than a manual move — plugins like Duplicator or All-in-One WP Migration package your files and database into one transferable archive, cutting steps 3 through 5 of the manual process down to a single import.
The technical transfer (files, database, testing) typically takes a few hours for a standard WordPress site. Full DNS propagation after cutover usually completes in minutes to an hour with a lowered TTL, though it can take up to 24–48 hours in rare cases depending on your DNS provider and visitors’ ISPs.
