Migrating a WordPress site to a new host can improve speed, security, scalability, and support quality, but it can also create downtime, broken layouts, missing emails, or search ranking issues if the move is rushed. Before any files or databases are transferred, a site owner should review the current setup, confirm technical requirements, and prepare a rollback plan.
TLDR: Before migration, the site owner should check backups, hosting compatibility, DNS settings, email services, SSL certificates, plugin conflicts, and performance benchmarks. For example, if a WooCommerce store receives 30,000 monthly visits and has a 2.8-second average load time, the team should record that baseline before moving so the new host can be properly evaluated. A careful checklist can reduce downtime from several hours to just a few minutes. The safest migration is one that is tested before it is made public.
1. Confirm Why the Site Is Being Migrated
Before choosing a new hosting provider, the site owner should identify the main reason for the migration. Common reasons include slow page loading, limited storage, weak customer support, high renewal costs, security concerns, or traffic growth. Understanding the reason helps the team compare hosts based on the right priorities rather than choosing only the cheapest plan.
For example, a blog with mostly static content may need reliable uptime and caching. An online store, however, may need better PHP workers, database performance, staging tools, and real-time backups. A membership site may require stronger server resources because many pages cannot be fully cached.
2. Create a Complete Backup
A full backup is the most important item on the pre-migration checklist. The site owner should create a copy of all WordPress files, the database, media uploads, themes, plugins, and configuration files. This backup should be stored somewhere separate from the current hosting account, such as cloud storage or a local drive.
- Files: WordPress core files, themes, plugins, uploads, and custom scripts.
- Database: Posts, pages, comments, settings, users, orders, and product data.
- Configuration: wp-config.php, redirects, security rules, and caching settings.
The backup should also be tested. A backup that cannot be restored is not a true safety net. If possible, the team should restore it on a staging environment before the actual migration.
3. Check Hosting Compatibility
Not every hosting environment is suitable for every WordPress site. Before migration, the site owner should compare the current WordPress setup with the new host’s technical specifications. This includes PHP version, MySQL or MariaDB version, server type, memory limits, file upload limits, and available extensions.
Important checks include:
- PHP version: The new host should support a modern version compatible with the site’s themes and plugins.
- Database version: The database engine should meet WordPress recommendations.
- Memory limit: Larger sites, page builders, and eCommerce plugins may need higher memory.
- SSL support: The host should allow easy SSL installation and renewal.
- Cron jobs: Scheduled tasks must work properly for backups, publishing, and subscriptions.
If a site uses custom code, the developer should also check server modules, command-line access, and special dependencies.
4. Audit Themes and Plugins
Plugins and themes can behave differently on a new server. Before migration, the site owner should remove unused plugins, update active plugins, and confirm that the theme is compatible with the current WordPress version. Outdated extensions can create security risks or cause errors during PHP upgrades.
It is also wise to document mission-critical plugins. These may include payment gateways, SEO tools, caching plugins, form builders, booking systems, learning management plugins, or subscriptions. If any plugin depends on server-specific paths or license activation, that should be reviewed before the move.
5. Record Current Performance Benchmarks
To know whether the migration improves the site, the team needs data from before the move. The site owner should record page speed, uptime, server response time, database size, storage usage, and traffic levels. Tools such as performance testing platforms, analytics dashboards, and hosting reports can help establish a clear baseline.
Useful benchmarks include:
- Average page load time for the homepage and key landing pages.
- Mobile performance scores.
- Server response time.
- Monthly visits and peak traffic periods.
- Current database size and total file storage.
If the current site loads in 4.1 seconds and the migrated version loads in 2.3 seconds, the improvement is measurable. Without a baseline, the team can only guess whether the migration was successful.
6. Review DNS and Domain Settings
DNS settings control where the domain points. Before the migration, the site owner should identify where DNS is managed, whether at the domain registrar, current host, CDN, or third-party DNS provider. They should also lower the DNS TTL value before the move, often to 300 seconds, so changes propagate faster when the new server goes live.
Important DNS records may include:
- A records for the main domain.
- CNAME records for subdomains.
- MX records for email delivery.
- TXT records for SPF, DKIM, DMARC, and verification.
DNS mistakes are a common cause of migration problems. A website may work correctly, but email may stop functioning if MX records are changed accidentally.
7. Protect Email Services
Many site owners forget that web hosting and email hosting may be connected. If email accounts are hosted on the old server, migration can interrupt messages unless the team prepares in advance. The site owner should check where mailboxes are hosted, how many accounts exist, and whether old emails need to be transferred.
If email is handled by a third-party provider, such as a dedicated email platform, the MX records should usually remain unchanged. If email is moving with the website, the team should create mailboxes on the new host before changing DNS.
8. Check SSL, Security, and Firewall Rules
The new host should support a valid SSL certificate before launch. A missing or misconfigured certificate can trigger browser warnings and reduce customer trust. The site owner should also review security plugins, firewall rules, malware scanning, and login protection.
If the current site uses redirects from HTTP to HTTPS, those rules should be recreated or verified on the new server. The team should also confirm that admin logins, payment pages, and checkout forms remain secure after the migration.
9. Prepare a Staging Test
A staging site allows the team to test the migrated website before visitors see it. This is especially important for stores, membership sites, directories, and high-traffic publications. On staging, the team should check navigation, forms, search, checkout, user login, images, menus, widgets, and mobile layouts.
The staging environment should be protected from search engine indexing. Otherwise, duplicate pages may appear in search results. A temporary URL or hosts file method can be used to preview the new server safely.
10. Plan the Migration Window
The best time to migrate is usually during the site’s lowest traffic period. The site owner should check analytics to identify when visitors are least active. For an online store, the team should avoid peak sales periods, marketing campaigns, and product launches.
For dynamic sites, the team may need to place the old site in maintenance mode briefly to prevent new orders, comments, or registrations from being lost during the final database transfer. The migration plan should include who is responsible for each step and how the site will be rolled back if something fails.
11. Verify SEO and Redirects
A host migration should not change URLs, titles, metadata, or content structure unless a redesign is happening at the same time. The site owner should export existing redirects, record important URLs, and ensure that the robots.txt file and sitemap remain correct.
After migration, the team should check that search engines can crawl the site, canonical tags are correct, and no important pages return 404 errors. Analytics and search console verification codes should also remain active.
12. Build a Post-Migration Checklist in Advance
Before the move begins, the team should prepare a final checklist for after launch. This may include testing contact forms, placing a test order, checking payment gateways, reviewing page speed, confirming SSL, clearing caches, and monitoring error logs.
A successful migration is not complete when the files are copied. It is complete when the site works correctly for users, search engines, administrators, and customers.
FAQ
How long does a WordPress migration usually take?
For a small brochure site, migration may take one to three hours. Larger sites, stores, and membership platforms may require several hours or a full day, especially if testing is included.
Should the site owner migrate WordPress manually or use a plugin?
Migration plugins can work well for simple sites. However, complex websites with custom code, large databases, or eCommerce features often benefit from a manual or professionally managed migration.
Will migration hurt SEO rankings?
A host migration alone should not hurt rankings if URLs, content, redirects, SSL, and crawl access remain unchanged. Problems usually happen when pages break, load slowly, or return errors after launch.
What is the biggest risk during migration?
The biggest risk is data loss, especially for active sites with orders, comments, user registrations, or form submissions. A tested backup and a clear final database sync can reduce that risk.
When should DNS be changed?
DNS should be changed after the new hosting environment has been tested and confirmed to work. Lowering TTL before migration can help the domain point to the new server faster.
