Complete Checklist for Migrating to a New WordPress Website Hosting Provider
Moving a WordPress site is more like a house move than a software upgrade. You’re hauling content, design, reputation, and business processes from one host to another, and every box matters. A smooth migration preserves search visibility, avoids downtime, and gives you a clean slate for performance improvements. A sloppy one can break forms, lose orders, corrupt images, and leave you with DNS propagation regrets you’ll feel for days.
This checklist reflects what actually matters during a WordPress Web Hosting migration, from the planning call to the post-cutover verification. It also covers the judgment calls you’ll make when juggling uptime, cost, and complexity.
Decide whether migration is the right move
Before you change anything, verify that moving is the correct response to the pain you’re feeling. Hosting isn’t just about price or disk space. It affects speed, reliability, security posture, and how much time you spend on WordPress Website Management.
Performance is the first tell. If pages sit above two to three seconds on a warm cache and simple optimizations haven’t helped, your current host might be throttling PHP workers, stacking too many tenants per node, or using dated storage. Support quality matters too. If urgent tickets die in a queue, no amount of caching will make your life easier. Add compliance, backups, staging environments, and developer ergonomics to the list. For example, a team shipping weekly updates benefits from workflow-friendly staging and push-to-deploy. An ecommerce store needs consistent checkout speed, predictable PHP workers, and no surprise downtime with a flash sale.
Be honest about your real traffic profile. Some sites have a narrow daily peak that requires short bursts of resources. Others run stable but heavy. Hosts package resources differently. Reading beyond “unlimited” marketing claims prevents disappointment after the move.
Choose a host that fits your use case, not someone else’s
WordPress Website Hosting options range from inexpensive shared plans to premium managed platforms. Each has trade-offs.
Shared hosting is cheap, simple, and good for a personal site or brochureware. It struggles under load, and noisy neighbors are not a myth. A VPS gives you dedicated resources and control. It demands more responsibility: patching, server tuning, monitoring. Managed WordPress hosts sit in the middle. They bundle expert support, strong caching, malware scanning, automatic updates, and daily backups. That service layer costs more but frees your team to focus on content and growth.
Scrutinize the specifics. The PHP versions offered, HTTP/2 or HTTP/3 support, Brotli compression, object caching like Redis, and CDN integration make or break performance. Ask how many PHP workers a plan includes and whether they can burst. Check the real backup policy: frequency, retention, offsite storage, and whether restores are self-service. For international audiences, look for multiple regions and a global CDN with image optimization.
Consider billing and lock-in. Some hosts offer monthly or annual discounts, migration credits, and risk-free trials. Balance that against potential exit friction. If a host makes it easy to export backups and databases in standard formats, that’s a positive signal.
Inventory your current site with ruthless precision
A proper inventory spares you from late-night surprises. Catalog everything that runs, stores data, or touches third-party services.
Start with the WordPress version, theme, child theme, and all active and inactive plugins. Record versions and license keys. Speed issues often hide in plugin stacks, so note anything that handles caching, security, redirects, SEO, image optimization, forms, and ecommerce. For WooCommerce, capture version-specific dependencies like HPOS settings, the database schema, and gateway plugins.
Map the site architecture. Identify custom post types, taxonomies, and user roles. Note multisite configurations, subdomain mapping, and any custom cron jobs. If you have multilingual plugins, capture how domains and permalinks map across languages. If a headless setup feeds a mobile app, document the endpoints.
Don’t forget data outside the obvious. Some themes stash settings in the database. Page builders pack layouts into custom fields. Forms and pop-ups may store submissions locally or offload them to CRMs. For media storage, check whether the wp-content/uploads folder is on the server or in object storage like S3 via a plugin. If your site depends on .htaccess directives or Nginx configs for rewrites and security headers, copy those too.
Plan your cutover strategy
Pick a maintenance window that reflects real usage. An informational site can move off-peak with minimal fuss. A WooCommerce store with global customers probably needs a two-phase approach: initial sync during low traffic, then a brief read-only window for final delta migration. Define acceptable downtime. Zero downtime is possible with smart DNS and brief read-only periods, but it increases complexity.
Estimate timelines. Moving a 1 GB site with a single database is under an hour if everything lines up. A 50 GB media library or a database with millions of rows requires a different playbook, sometimes using rsync over SSH and chunked SQL exports to avoid timeouts.
Decide on IP warmup for email. If you’re moving transactional email as part of the migration, plan DKIM and SPF updates and allow partial parallel sending to warm a new IP. For most sites, sticking with a trusted transactional service avoids headaches.
Finally, clarify roles. Someone should own the database export, the DNS switch, QA on staging, and go/no-go authority. This avoids last-minute confusion when the clock is ticking.
Prepare the new environment before touching the old one
Set up the new hosting environment with expectations aligned to your inventory. Choose the right PHP version to match your site and upgrade it only after testing. Configure the web server (Apache or Nginx) rules for permalinks, redirects, and security headers. Create a database with proper character set and collation, usually utf8mb4 and a suitable collation like utf8mb4 _unicode_ci, so your emojis and multilingual content don’t break.
Provision SSL certificates. Most hosts offer Let’s Encrypt. For a staging subdomain, use a separate certificate so you can test HTTPS end to end. If you use HSTS, plan the rollout carefully. HSTS forced too early can lock browsers into a domain that still points to the old host.
Set up SFTP and SSH credentials. If you’re migrating a large media library, ensure SCP or rsync is available. For object caching, enable Redis or Memcached if your host supports it. Configure a CDN, but keep it disabled or on a staging hostname until after DNS cutover. Pre-install critical plugins such as security, caching, SMTP, and any required MU plugins.
Create a clean staging site and test there
Clone the site to a staging subdomain on the new host. Hosts often provide an automatic staging tool. If not, copy files, import the database, and update the site URL in the database. For search-and-replace, use WP-CLI or a safe tool that handles serialized data. A raw SQL replace can corrupt serialized strings and break widgets or options.
Once the clone runs, dive into functional testing. Logins, password resets, checkout flows, contact forms, page builder edits, and image uploads should all work. Check cron events and scheduled posts. Open the error logs and fix loud warnings that you previously ignored. If you see mixed content in the browser console, fix media and CSS URLs. Confirm your redirects work and that the canonical URLs align with expectations.
Look at performance under staging traffic. Tools like query monitors can spot slow database calls or chatty plugins. If you see server response times over 600 ms for uncached pages, evaluate PHP workers, object caching, or heavy plugins. Remove anything you no longer need. A migration is a rare chance to lighten the load.
Back up everything and verify the backups
Before you extract a single file, make current, complete backups on the old host and store them offsite. Do not rely on your host’s daily backups alone. Make your own copies using a trusted plugin or manual tarballs and SQL dumps. Include wp-content, the database, and any custom directories or configuration files. If you have crontab entries, export them. If your site stores uploads outside the standard path, copy those too.
Test a small restore to prove your backups aren’t corrupt. A backup you haven’t verified is wishful thinking, not a disaster plan.
Migrate databases the right way for your site size
Database size and write patterns drive your approach. For small to medium databases, a straightforward SQL export and import works well. Use mysqldump or WP-CLI to avoid web-based timeouts, and include all tables, including those created by plugins. For larger databases, export and import in chunks. Disable autocommit inside transactions if your tool supports it, to speed up import and reduce overhead.
Set the new database’s charset and collation to utf8mb4 variants and confirm that the import preserves them. After import, run a search-and-replace for URLs using WP-CLI’s search-replace command to safely handle serialized data. Clear transients and regenerate salts if you want a fresh security posture.
For high-write sites like ecommerce, handle final deltas. First, migrate a snapshot during low traffic. Later, when you flip DNS, put the old site into read-only mode for a few minutes and re-export only the changed tables. For WooCommerce, that typically includes orders, order meta, users, user meta, and sessions. Some teams use specialized tools or incremental replication to minimize downtime.
Move files efficiently, especially media libraries
Files typically fall into core WordPress files, themes, plugins, and uploads. For small sites, zipping wp-content and transferring via SFTP is enough. For large media libraries, use rsync over SSH with checksums and resume capability. Rsync shines for final syncs, sending only changed files. If your current host doesn’t allow SSH, break the transfer into dated folders to avoid timeouts.
Maintain permissions and ownership as you copy. Incorrect permissions can cause white screens or block uploads. Standard practice is 644 for files and 755 for directories, but hosts differ. If your new host runs Nginx with a specific user, adjust ownership accordingly.
If you’re moving from local storage to object storage, set up the offload plugin and run the migration in batches. Don’t delete local copies until you’ve verified offloaded objects are accessible via your CDN and that transformed images continue to render.
Recreate server-level behavior: redirects, rewrites, and headers
Many sites rely on .htaccess rules for redirects and rewrites. If you’re moving to Nginx, rewrite those rules using Nginx syntax. This step trips up migrations more often than it should. Document existing patterns, such as legacy URL paths, trailing slash behavior, and uppercase to lowercase normalization. Reapply HSTS, Content Security Policy, and Referrer-Policy headers if you used them, testing in report-only mode first for strict CSP policies.
If you have a reverse proxy like Cloudflare, check page rules, caching levels, and firewall settings. A new origin IP may invalidate existing allowlists. Update any WAF or bot protection tools with the new origin and test the challenge flows so you don’t block your own admin users.
Configure email and external integrations before flipping DNS
WordPress itself does not send email reliably from the server. Use a transactional provider for password resets, order confirmations, and contact forms. Install an SMTP or API-based plugin, set DNS records for SPF, DKIM, and DMARC, and send test emails. If you host email on the CaliNetworks same domain but a different provider, confirm the MX records are correct and that no A record changes will disrupt mail delivery.
Inventory API keys used by the site. Payment gateways, shipping calculators, CRM integrations, analytics, reCAPTCHA, maps, and marketing pixels all need to be verified in the new environment. IP-restricted APIs should be updated with the new server IPs. If a plugin validated its license against the old domain or IP, re-activate and confirm you are within allowed activations.
Dry run your go-live process
A rehearsal pays off. Set the new site behind a temporary hostname or hosts file override and browse it as if you were a user. Visit high-value journeys: home page to product to checkout, blog archive to single post, form submits WordPress Website Hosting to thank-you pages. Compare rendering, critical CSS, and image quality. Watch server logs and PHP error logs during this walkthrough. Fix anything noisy.
If the site uses local caching at the application or server level, prime caches on the most-visited pages. Keep object caching ready but avoid stale keys by clearing caches after any domain-wide search-and-replace.
Execute the cutover with a light touch
When it’s time to switch, reduce variables. Pause content updates or put the old site in read-only mode for a short window. For high-traffic stores, notify staff so they don’t process orders mid-cutover.
Lower DNS record TTLs at least a day before go-live if possible. That way, changes propagate faster. Update the A record to the new host, and if you use a CDN, ensure the CDN points to the correct origin. Keep both servers ready during propagation. Some visitors will still hit the old site for a few hours due to resolver caching. If necessary, set the old site to maintenance with a polite notice and a link to a status page so you avoid split-brain orders.
As soon as DNS updates, monitor the new server’s access logs, error logs, and resource usage. Watch for spikes that indicate bot traffic or a misconfigured cache. Keep a communication line open with your hosting support if you’re on managed WordPress Website Hosting. A good team can see problems from their side faster than you can.
Verify the essentials after cutover
Don’t assume success because the home page loads. Check the important layers: TLS certificate validity, redirects from www to non-www or vice versa, canonical tags, robots.txt, and XML sitemaps. For ecommerce, place a test order using a low-value product or a sandbox gateway. For membership sites, log in as a user and access protected content. For content-heavy sites, spot-check featured images, galleries, and downloadable files.
Search engines are sensitive to URL changes. Crawl the site with a tool and look for 404s, 302s where 301s are expected, or unnecessary redirect chains. Fix them quickly so your SEO equity follows.
Access the admin area and verify updates work. Trigger cron jobs and confirm they run. If you disabled cron for the migration, re-enable it or set a system cron to invoke wp-cron.php at intervals. Check the .user.ini or php.ini limits for memory and execution time. Set them high enough for your site’s needs, then ratchet them back to sane values after the first day.
Monitor and tune performance in the first 48 hours
The first two days reveal edge cases. Use real user monitoring or your analytics to track Largest Contentful Paint, Time to First Byte, and error rates. If your host provides application performance monitoring, look for slow PHP transactions and heavy queries. Fix offenders by caching, pruning plugins, or optimizing database indexes. Sometimes a single expensive search query or a chatty options autoload table drags everything down.
Inspect the wp_options table’s autoload size. Values above a few megabytes often signal bloat. Clean expired transients. Consider enabling object caching and confirming that your theme and plugins respect it. Update CDN settings for cache TTLs, image resizing, and Brotli compression. For global audiences, confirm edge caching is actually serving from nearby PoPs.
Security posture: use the move to harden your stack
A migration is a perfect time to rotate keys and revisit access. Generate new salts, change SFTP and SSH credentials, and adopt per-user access rather than shared logins. Turn on two-factor authentication for WordPress accounts with elevated privileges. Limit XML-RPC if you don’t need it, and enforce least privilege on database users.
Reassess your firewall and WAF settings. If your new host includes malware scanning, configure automatic scans and notifications. If you previously relied on .htaccess for bot rate limiting, migrate those rules or use a dedicated WAF that handles it more gracefully.
Document the new baseline and train your team
Once you stabilize, capture the environment details. Record PHP version, web server type, database credentials, cache layers, CDN settings, and the backup schedule. Document the restore process and run a test restore to an isolated environment so you know it works. If your team handles content publishing, show them any new quirks, such as stricter image size limits or staging workflows.
Good WordPress Website Management thrives on clarity. Write down how to push staging changes to production, how to purge caches, and who to call on the host’s support side when something misbehaves.
A pragmatic checklist you can print
Lower DNS TTL 24 to 48 hours in advance and choose a low-traffic cutover window. Make verified offsite backups of files and database, and document plugins, versions, and licenses. Prepare the new environment: PHP version, database charset, SSL, caching, CDN, SMTP, and server rules. Clone to staging, run URL-safe search-and-replace, and complete functional and performance tests. Execute cutover, monitor logs, validate redirects, forms, checkout, and restore cron and caching.
Common edge cases and how to handle them
Multisite networks require special care. Domain mapping, user tables, and plugin scope vary by site. Migrate one subsite at a time if needed, or clone the entire network and validate mappings before you switch DNS. Keep a list of sunrise.php and sunrise-specific config settings because they are easy to forget.
Large media libraries can stall uploads due to permissions or timeouts on the new host. If you see broken thumbnails, regenerate them with a CLI tool and verify your image editor libraries, such as Imagick, are installed and set with reasonable limits. Consider offloading media to object storage with a CDN if the library is growing fast.
Geo-IP based redirects often depend on server modules that differ across hosts. Recreate those with application-level logic or a CDN rule if your new host lacks the same module. Test with VPNs to ensure the right content serves to the right regions.
Staging URLs that leak into production happen when a search-and-replace misses serialized strings or post meta. Run another search for the staging domain across the database and fix remaining references, then flush caches again.
Payment gateways that key off server IP or country can fail silently after a move. Re-authorize the domain and update allowed IP addresses in the provider dashboard. Run a live $1 test if your policies allow it. If not, confirm sandbox behavior on a staging clone that mirrors production settings.
Aftercare: keep the gains you made
A migration often boosts speed simply by moving to better hardware and a cleaner stack. Don’t let that advantage decay. Maintain plugin discipline. Review active plugins quarterly and remove duplicates in functionality. Keep core, plugins, and themes updated, but stage and test before applying major upgrades.
Check backups monthly for integrity, and store at least one backup set offsite in a different provider. Revisit CDN analytics to fine-tune cache hit ratios. If you start publishing more video or very large images, move those assets to a platform designed for it instead of swelling your WordPress uploads.
Finally, use the host’s support well. Managed WordPress Web Hosting is more than a place to park files. The best providers help with performance tuning, malware cleanup, and scaling advice. Build that relationship early so when you face a traffic spike or a plugin meltdown, you aren’t explaining your site from scratch over chat.
The payoff
A thoughtful migration is uneventful to your visitors and a relief to your team. Pages render faster, admin screens feel snappier, and support tickets shrink. You gain observability and a backup regime you trust. Most of all, you reduce the hours you waste on hosting quirks and reinvest them in work that moves your site forward. That is the real return on choosing a WordPress Website Hosting provider that fits, planning carefully, and executing with care.