Migrate WordPress site projects can feel nerve-racking, especially when you’re changing hosts, switching domains, launching a staging site, or recovering from a failed migration.
This guide breaks the process into clear, manageable steps so you can protect your data, avoid unnecessary downtime, and move your site with confidence.
You’ll learn how to create a complete backup, transfer your files and database, update your configuration and URLs, and test the new site before changing DNS. By the end, you’ll have a practical migration plan and a reliable fallback if anything doesn’t go as expected.
TLDR: The safest way to migrate WordPress site is to create a full backup, use a reliable migration plugin to transfer the files and database together, and test the new site before updating DNS. Check forms, checkout, redirects, SSL, email records, logs, and backups before retiring the old host.
A migration fails when the transfer is treated as the whole job. The transfer is only the middle. The safer version is a controlled handoff: prepare, move, verify, switch traffic, monitor, then clean up.
Choose your migration method
Pick the method before you touch files or DNS. The right choice depends on site size, business risk, database activity, domain changes, server limits, and how comfortable you are reversing the move.
Situation
Safer method
Why
Small brochure site moving to a host that offers migration
Host-assisted migration
The host knows its own destination environment and can avoid common server-limit problems.
Healthy small or medium site
Migration plugin
A good migration plugin packages files and database together and can handle URL replacement safely.
Large sites, import failures, strict hosting rules, or locked-down access
Manual migration or host support
You need more control over files, database import, permissions, and server limits.
WooCommerce, memberships, courses, communities, or high-value SEO pages
Professional help or a controlled manual plan
These sites can lose orders, users, subscriptions, course progress, comments, leads, or rankings if the cutover is loose.
Same-domain host move
Host-assisted, plugin, or manual
Usually less URL work, but DNS, SSL, cache, and testing still matter.
Domain change
Manual plan, expert help, or a plugin with safe URL replacement
You also need siteurl, home, search-replace, 301 redirects, canonical checks, and SEO monitoring.
Host-assisted migration is usually the lowest-effort option when the new host offers it. It may still require temporary WordPress admin, SFTP, database, DNS, or control-panel access. Security plugins, two-factor authentication, anti-bot rules, and firewalls can block the host’s migration tool until you allow it.
A migration plugin is usually the easiest DIY route for a normal site. It can fail on very large sites, strict upload limits, server timeouts, multisite networks migrations, blocked archive extraction, or direct site-to-site transfers.
Manual migration is slower, but it gives you control when a plugin has already failed or the hosting setup is unusual.
🚦 Note: Choose the method based on what you cannot afford to lose. A five-page portfolio site and a WooCommerce store with live orders do not deserve the same migration plan.
Know what must move
A full WordPress migration moves three things: files, database, and environment settings.
Files: WordPress core files, themes, plugins, media uploads, custom code, cache files, and hidden server files such as .htaccess.
Database: posts, pages, users, comments, menus, widgets, plugin settings, theme options, WooCommerce orders, form entries, redirects, and saved URLs.
Environment and configuration: database connection details, table prefix, PHP version, SSL, DNS, CDN, cron jobs, redirects, cache rules, and email-related DNS records.
This is why the WordPress export tool is not a full migration tool. It can export posts, pages, and some content. It does not reliably recreate plugin settings, theme settings, users, WooCommerce history, media behavior, redirects, custom tables, or server rules.
If you move only visible content, you have copied part of the site. You have not migrated it.
Prepare before moving anything
Preparation is where you remove the easy ways to damage the site.
Create a complete offsite backup before the move: Back up both files and database, then store the backup away from the current host. A backup that only lives on the old server may be useless if the old account fails, gets suspended, or is overwritten during migration. This is where a managed workflow such as WPRemote’s WordPress backups is relevant: migration safety starts with a tested, restorable backup, not with confidence.
Record the current production setup: Note the WordPress version, PHP version, database version, active theme, active plugins, permalink structure, site URL, home URL, DNS records, SSL status, CDN settings, redirect rules, cron jobs, cache layers, and email provider. This baseline helps you identify what changed if the migrated site behaves differently.
Confirm the destination can run the site:Check PHP support, database access, storage, upload limits, memory limits, execution time, file permissions, cron support, object cache, SSL support, CDN compatibility, plugin licenses, and server-level redirects before you copy anything.
Clean only low-risk clutter: Remove abandoned plugins, inactive themes you do not need, stale backup archives, old export files, and cache folders only when you know they are safe to remove. Avoid aggressive cleanup right before migration because you do not want to debug a cleanup mistake and a migration problem at the same time.
Lower DNS TTL before launch day: If you control DNS, lower TTL in advance. TTL tells networks how long to cache a DNS answer. A common migration practice is to lower TTL to about 300 seconds roughly 48 hours before cutover. This can reduce stale routing, but it does not guarantee an instant switch because some resolvers may cache records longer.
🧭 Note: Do not skip the setup record. When a migrated site behaves differently, the question is often not “what broke?” but “what changed?” Your baseline answers that faster.
The active plugin list is another part of that baseline, because plugins can bring their own settings, tables, scheduled jobs, and licensing state into the migration.
Plan rollback before launch
Do not begin until you know how you would reverse the move.
Keep the old site available: Leave the old host, old database, and full backup untouched until the new site has been tested with real traffic. Do not cancel the old hosting account just because the new homepage loads.
Save the records needed to reverse DNS: Keep a copy of the old DNS zone, nameserver values, A records, AAAA records, CNAME records, CDN targets, MX records, and TXT records before editing anything.
Decide when live data will freeze: For sites that accept orders, signups, comments, bookings, course progress, or form entries, choose the point where new data stops on the old site and starts on the new one. Rollback becomes harder once visitors create different data in two databases.
Define the checks that decide success: The homepage is not enough. Forms, checkout, search, media, redirects, cron jobs, admin actions, email delivery, SSL, and error logs are better proof.
Keep overlap long enough to recover: For simple brochure sites, several days of host overlap may be enough. For stores, membership sites, and client sites, keep the old host for one to two weeks if the budget allows.
Migrate with a plugin
For many site owners, a reputable migration plugin is the simplest path because it moves files and database as one package.
Start from a stable source site:Update only what is necessary, clear obvious cache, and confirm the old site is not already broken. A plugin cannot reliably separate a transfer problem from a pre-existing WordPress problem.
Build a full migration package: Include files, database, plugins, themes, uploads, and custom tables. Check whether the destination needs a clean WordPress install or an empty web root before import.
Confirm what the import will overwrite: Many plugin imports replace the destination database and files. That is normal on a blank destination. It is dangerous if the destination already contains work you need.
Watch server limits during import: Large packages can fail because of upload size, memory limits, execution timeouts, blocked archive extraction, or security rules. If the import fails repeatedly, raise limits if your host allows it, ask the host to import the package, split the migration if the tool supports it, or switch to manual migration.
Replace URLs with WordPress-aware tools: Replace URLs only when the domain or URL structure changes. Use the plugin’s URL replacement feature or a WordPress-aware search-replace tool because WordPress stores some plugin and theme data as serialized data. A plain database text replacement can corrupt that data.
Refresh permalinks and every cache layer: After import, save permalink settings again and clear WordPress cache, server cache, object cache, browser cache, CDN cache, and security plugin cache. Many 404 and stale-design problems after migration are cache or rewrite-rule problems, not failed transfers.
🛠️ Note: If a plugin import fails twice for the same reason, stop and change the conditions. Raise limits, ask the host to import it, or move manually. Repeating the same failed import can leave partial files or a half-overwritten database.
Migrate manually
Manual migration is the same move with every part exposed.
Copy every WordPress file: Use SFTP, SSH, rsync, a hosting file manager, or a server-side archive. Include hidden files such as .htaccess, because they can control permalinks, redirects, access rules, and security behavior. Make sure wp-content/uploads, wp-content/themes, and wp-content/plugins move completely.
Export the full WordPress database: Use phpMyAdmin, WP-CLI, or your host’s database tool. The database is not optional. It contains content, users, settings, plugin data, menus, widgets, WooCommerce orders, form entries, and saved URLs.
Create and import the destination database: Create a database, create a database user, assign the user to the database, and import the old database. Keep the database name, username, password, host, and table prefix available.
Upload files to the correct web root: Put the WordPress files in the public folder used by the new host. Depending on the host, that folder may be called public_html, www, htdocs, public, or something custom.
Update the database connection in wp-config.php: Set DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, and $table_prefix. If any of these are wrong, WordPress may show Error establishing a database connection, which usually means WordPress cannot connect to the imported database with the current details, host, permissions, or table prefix.
Replace changed URLs safely: If the domain changed, update the WordPress siteurl and home values, then replace old URLs across content, widgets, menus, theme options, and plugin settings with WP-CLI search-replace, Better Search Replace, or another database-aware tool.
Leave post GUID values alone: Do not change the guid values in the wp_posts table. WordPress treats those as stable identifiers, especially for feeds. They are not the same thing as public URLs that need replacement.
Save permalinks after the move: Re-save permalink settings once the site is on the destination. This rebuilds rewrite rules and can fix inner-page 404s.
Handle domain changes
A same-domain host move is simpler than a new-domain move. If the domain stays the same, you may not need broad URL replacement. You move the site, test it on the new server, then point the existing domain to the new host.
Update the core WordPress URLs: For a new domain, update siteurl and home so WordPress knows its public address.
Replace embedded old-domain URLs safely: Use a database-aware search-replace tool for content, widgets, menus, theme options, page builder data, and plugin settings. Do not use a plain text replacement against the raw database.
Preserve URL paths where possible: If /services/wordpress-care/ becomes /wordpress-care/ without a redirect, visitors and search engines hit a dead end. Keeping paths stable reduces redirect work and SEO risk.
Map unavoidable URL changes before launch: If paths must change, map old URLs to the closest new equivalents before DNS changes. Use 301 redirects from old URLs to matching new URLs.
Update SEO and measurement settings: Check canonical URLs, analytics settings, form integrations, paid ad destinations, social profile links, search traffic, and Search Console change-of-address tooling where it applies.
📌 Note: A domain migration without redirect planning is not just a website move. It is an SEO risk. Build the redirect map before DNS changes, not after traffic starts finding 404s.
Change DNS carefully
DNS decides where visitors go. Do not change it until the destination has been migrated and tested.
Copy the DNS zone before editing: Save nameservers, A records, AAAA records, CNAME records, CDN targets, MX records, SPF, DKIM, DMARC, TXT verification records, subdomains, and third-party service records.
Change only the records required for the website: Some migrations need nameserver changes. Others only need an A record, AAAA record, CNAME, or CDN target change. Avoid broad DNS edits unless the migration requires them.
Wait for the migrated site to pass preview checks: Do not point traffic to a half-tested destination. Change DNS only after the migrated copy works through a staging URL, preview URL, temporary domain, hosts-file preview, or host preview tool.
Allow for uneven DNS propagation: DNS propagation can take hours and sometimes up to 48 to 72 hours. During that window, some visitors may reach the old server while others reach the new one.
Verify SSL after cutover: The destination host may issue a certificate only after the domain points there. Once DNS changes, test both HTTP and HTTPS, then check for mixed content. SSL monitoring is useful after launch because certificate and HTTPS problems may not appear during the first browser check.
Do not break email
Email is usually separate from WordPress. Moving the website does not automatically move mailboxes, aliases, forwarding rules, transactional email services, or DNS records.
The common mistake is changing nameservers and forgetting to recreate mail records. The site starts loading on the new host, but email stops because MX records, SPF, DKIM keys, DMARC policy, or mail verification TXT records were left behind.
Identify the mail host before changing nameservers. It may be the old web host, the new web host, Google Workspace, Microsoft 365, Zoho, a transactional email service, or another provider.Copy mail DNS records before the cutover. If mailboxes are also moving, treat that as a separate mailbox migration with its own backup, timing, and verification.
A successful WordPress migration can still be a business failure if contact forms and email delivery stop working.
Protect stores and member sites
Stores, course sites, communities, and membership sites need extra control because their databases change constantly.
Use a short maintenance window, content freeze, or differential migration plan for the final move. If the old and new sites both accept orders, registrations, comments, or form entries during DNS propagation, new data can split across two databases.
For WooCommerce, check recent orders, customer accounts, carts, checkout, payment gateway keys, webhook URLs, tax settings, shipping settings, transactional emails, subscriptions, scheduled actions, stock levels, and plugin licenses. If you use store-specific extensions, review your WooCommerce plugins before the final test. Run a real checkout test if possible, even if it is a low-value test order that you refund.
For membership and learning sites, test login, account pages, protected content, subscription status, renewal behavior, course progress, email notifications, and access rules.
🔒 Note: If the site takes payments or protects access, avoid a casual overnight switch. Put the site in maintenance mode for the final database move or use a host/pro who can control the handoff.
Test before DNS changes
Testing before DNS cutover catches problems while rollback is still easy.
Open the migrated site without public DNS: Use a staging URL, preview URL, temporary domain, hosts-file preview, or the host’s preview tool. A WordPress staging workflow is useful because the question is not only whether the files moved. The question is whether the moved site works before visitors reach it.
Check the pages visitors actually use: Test the homepage, important landing pages, blog posts, media files, menus, widgets, permalinks, redirects, SSL, page builder layouts, mobile layout, and visible PHP errors.
Run the actions that create business value:Submit a form, search the site, log in as a user, download a protected file, add a product to cart, complete a test checkout if the site sells, confirm transactional emails arrive, and check that analytics and tracking scripts still load.
Clear caches before judging the result: Old cached CSS, cached redirects, CDN files, and browser cache can make a broken site look fine or a working site look broken.
Prioritize anything that can cost money or trust: If it makes money, captures leads, protects access, stores user data, or affects search traffic, test it before launch.
Test after DNS changes
After DNS cutover, test again from a clean browser, a different network, or a device that has not cached the old site.
Retest from a clean path: Use a clean browser, a different network, or a device that has not cached the old site. Check both HTTP and HTTPS versions and the www and non-www versions if both are used.
Monitor the logs that show real failures: Review uptime, error logs, access logs, activity logs, 404 logs, Search Console, analytics, forms, checkout, email delivery, scheduled tasks, cache behavior, CDN behavior, security alerts, and backup creation.
Watch the site through the propagation window: Monitor closely for at least 24 to 72 hours. For important sites, watch longer because intermittent DNS, cache, cron, checkout, and email problems may not appear in the first hour.
Keep migration help available if risk is high: If you would rather not run the migration yourself, WPRemote’s WordPress migration support is the relevant service path to review after you understand the moving parts.
Fix common migration problems
Fix database connection errors: Check DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, database user permissions, and $table_prefix in wp-config.php. Confirm the database import completed.
Fix white screen or critical errors: Check PHP version, missing files, memory limits, plugin conflicts, theme conflicts, and server error logs. Disable plugins only with a reversible method, such as renaming the plugin folder temporarily or using WP-CLI if you have access. If the site shows a technical-difficulties screen, follow a WordPress critical error troubleshooting path before deleting files.
Fix 404 errors on inner pages: Save permalink settings again. Confirm .htaccess moved on Apache servers. On Nginx, ask the host to confirm the WordPress rewrite rules.
Fix broken images and media: Confirm wp-content/uploads moved fully, old URLs were replaced safely, file permissions allow public access, and CDN cache has been cleared.
Fix mixed content warnings: Replace old HTTP asset URLs where appropriate, clear cache, and check CDN or security plugin settings.
Fix redirect loops one layer at a time: Review HTTPS redirects, old-domain redirects, plugin redirects, host-panel redirects, and CDN redirects separately. Multiple layers forcing different versions of the URL can trap visitors.
Fix import size failures: Raise upload size, memory limit, and execution time if your host allows it. If not, ask the host to import the package, use a migration tool that supports larger sites, or move manually.
Fix email delivery failures: Recheck MX records, SPF, DKIM, DMARC, contact form sender settings, SMTP plugin settings, and transactional email service verification.
After migration
Keep the old host active until the new site has survived a real verification window. Then take a fresh backup on the new host and document the final setup.
Create a fresh backup on the new host: Confirm the backup includes files and database. This becomes the new restore point after the migration succeeds.
Remove temporary migration files: Delete migration packages, temporary archives, old database dumps, installer files, and test admin accounts when the move is complete. These files are useful during migration and risky afterward.
Document the final working setup: Record the new host, DNS provider, nameservers, database details, PHP version, cache layers, CDN settings, email provider, backup location, and maintenance owner.
Set the maintenance routine now: Migration is a good time to turn the move into a stable operating process. A WordPress maintenance checklist helps you keep backups, updates, monitoring, and security checks from becoming another scramble later.
When to get help
Do not force a DIY migration when the downside is bigger than the savings.
Get host support or professional help if the site earns revenue every day, stores customer data, has WooCommerce or memberships, changes often, is moving domains, has major SEO value, is very large, uses multisite, depends on custom server rules, lacks full access, already had a failed migration, or has no reliable backup.
The goal is not to prove that you can move WordPress manually. The goal is to move the site with the least chance of permanent damage.
Conclusion
To migrate a WordPress site safely, treat the move as a controlled handoff, not a file transfer.
Back up everything, move files and database together, test before DNS, and keep rollback available.
Be extra careful with domains, email, WooCommerce, membership data, redirects, and cache.
The migration is finished only when the new site works, new backups exist, and the old host is no longer needed.
If the moved site feels slow after launch, diagnose that separately from the transfer itself.
FAQs
What is the easiest way to migrate a WordPress site?
The easiest way is usually a host migration service or a trusted migration plugin. Use manual migration when the site is large, unusual, blocked by server limits, or already failed with a plugin.
Can I migrate WordPress without downtime?
You can reduce downtime by preparing the destination first, testing it before DNS changes, lowering DNS TTL in advance, and keeping the old site active. Do not depend on a zero-downtime promise because DNS, SSL, cache, and dynamic data timing can vary.
Do I need to move the database?
Yes. The database stores posts, pages, users, comments, menus, settings, plugin data, WooCommerce orders, form entries, and saved URLs. Moving only files will not move the full site.
Can I use the WordPress export tool to migrate a full site?
No. The export tool can move content, but it is not a complete site migration. It does not reliably move the full database state, plugin settings, theme settings, users, redirects, media behavior, WooCommerce data, or server configuration.
Will my email move with WordPress?
Usually no. Email is controlled by mailboxes and DNS records, not WordPress files. Preserve or migrate MX, SPF, DKIM, DMARC, mailbox, forwarding, and email verification records before changing nameservers.
Shivani enjoys crafting guides that make every aspect of using WordPress simple and easy to follow. When she’s not glued to her laptop, you can find her buried in a good book or occasionally, painting.
Check out breaks. A form stops sending. The builder opens to a white screen. If that happened right after a WordPress update or plugin update, searching for a WordPress downgrade…
Before you touch a live WooCommerce store, name the thing you’re actually afraid of. It’s probably not the update itself. It’s the order that doesn’t come through. The checkout field…
Monitoring one client site is simple. Monitoring fifty is not. Every site needs a different level of attention, so agencies add tools as new needs come up. Soon, alerts are…
How do you manage your websites?
Managing multiple WordPress websites can be time consuming and error-prone. WP Remote will save you hours every day while providing you complete peace of mind.
Managing everything yourself
But it’s too time-consuming, complicated and stops you from achieving your full potential. You don’t want to put your clients’ sites at risk with inefficient management.
