You moved the site to a new host because the old one was slow, or expensive, or both. The migration went smoothly: every page is there, the forms work, the shop takes orders. But the site feels slower than before, not faster. The new host’s sales page promised better performance, and now you are wondering whether you made a mistake.
Ending up with a website slow after migration is common, and it rarely means the new hosting is worse. A migration copies your files and your database. It does not copy the server those files used to live on: its caching, its PHP settings, its extensions, its scheduled tasks, its location. Many of the things that made the old site fast were part of that server, and they stayed behind. Comparing old and new fairly, once those pieces are back, is the last step.
What moves, and what stays behind
It helps to picture two lists.
What moves: WordPress itself, the theme, plugins and their settings, uploaded media, and the database with all your content, orders and users.
What usually does not: the web server software and its configuration, server-level caching, any object cache service, the PHP version and its settings, compression and protocol settings, real cron jobs set in the old control panel, firewall and bot rules, and the physical location of the server.
When a site is slower after moving hosts, the cause is usually on the second list. The work is to go through it and set each item up again on the new server.
The usual suspects, one by one
Caching that depended on the old server
This is a frequent cause. Some caching plugins only work fully on a particular kind of server. LiteSpeed Cache, for example, relies on a LiteSpeed web server for its main page caching; move the site to a server running Apache or Nginx and the plugin’s page cache stops working, even though the plugin still shows as active. The reverse is also true: a site moving to LiteSpeed hosting may be running a caching plugin that does not use the server’s own cache.
Other hosts provide caching at the server level, managed from their control panel rather than a plugin. If your old host did this, you had page caching without ever setting it up, and the new host may need it switched on, or may need a plugin instead.
Check: open any public page while logged out, then inspect its response headers; a working page cache usually announces itself there with a hit. If there is no sign of caching, set it up for the new server before doing anything else.
The object cache
If the old host ran Redis or Memcached for your site, a plugin on your site was talking to it. On the new server that service may not exist, may need enabling, or may use different connection details. Ask the new host whether Redis or Memcached is available, and check the object cache plugin’s status screen to see whether it is actually connected.
PHP version and settings
New hosting accounts sometimes start on an older default PHP version, or on a newer one your plugins have not been tested with. Memory limits, maximum execution times and OPcache settings may also differ. Check the PHP version under Tools, then Site Health, then Info, and compare it with what you ran before. The post on updating the WordPress PHP version safely covers how to move between versions without breaking anything.
Scheduled tasks
If your old control panel ran WordPress’s scheduled tasks with a real server cron job and WP-Cron was switched off in wp-config.php, the new server needs that cron job set up again. Otherwise scheduled posts, emails and cleanups either stop or fall back to running when visitors load pages.
Server location
Your new host may be in a different country from your old one. If it is now further from your visitors, every request carries extra distance, and no setting fixes that. Check where the new server is. If your customers are mainly in another region, how distance slows a site for overseas visitors explains the options.
Things that came along that should not have
Migrations also carry over a few things that only cause trouble in their new home.
- Old addresses in the database. If the site changed domain or moved from a temporary address, a search-and-replace should update every stored link. When it misses some, pages may load images or files from the old address, or send every request through a redirect. In the network panel, watch for files still coming from the former domain, or plain http addresses that bounce to https.
- Copied cache folders. Cache files created on the old server can contain the old server’s paths and settings. Clear the caching plugin’s cache after the move, and remove any leftover cache folders the plugin no longer manages.
- A CDN still pointing at the old host. If you use a CDN, its origin setting must point to the new server. Otherwise it may keep fetching from the old one, or fail and fall back slowly.
- Hard-coded paths in configuration. Settings in wp-config.php, .htaccess or a plugin’s own configuration that refer to the old server’s folders.
If the move also produced errors, broken pages or missing images rather than just slowness, our guide to fixing WordPress errors after a migration covers those.
DNS during the switch-over
For a while after you change the domain’s DNS, some visitors may still reach the old server and some the new one, depending on how long the old records were set to be cached. If you test during this period, you may not even be testing the new host. Confirm which server you are reaching before drawing conclusions, for example by checking a header the new host adds or by placing a small test file only on the new server.
If you are planning a migration, lowering the time-to-live on the DNS records a day or so beforehand shortens this overlap.
Website slow after migration? Check these in order
This list catches most problems. Do it the day the site moves, while the old server is still available for comparison.
- Confirm you are reaching the new server.
- Clear every cache: plugin, server, CDN.
- Check the page cache is working on the new server, using response headers.
- Check the PHP version and memory limit in Site Health.
- Check the object cache, if you used one.
- Look for leftover links to the former domain and for any redirect hops.
- Check the CDN’s origin setting.
- Re-create any server cron jobs.
- Run speed tests on the same pages you measured before the move, from the same location.
Comparing old and new fairly
If you can, keep the old hosting running for a short time after the move. Then you can test both, side by side, with a hosts-file entry or the old server’s temporary address. Compare the server response time for a cached page, an uncached page (such as a search results page) and the dashboard.
If the new server is slower on cached pages, something is missing from its setup. If it is slower only on uncached pages, compare PHP versions, object caching and the plan’s resources. If the new server is quicker on every measure but the site still feels slow, the cause is probably in the page itself rather than the hosting, and the general triage in why is my website slow will help you look there. The hosting and caching sections of our site speed guide cover each piece in more depth.
Frequently asked questions
How long after a migration should I wait before judging the speed?
Wait until DNS has settled and you are sure visitors reach the new server, then clear the caches and let them refill. How long DNS takes depends on the time-to-live set on the old records. After that, test the same pages several times and compare against results from before the move.
Should I keep my old hosting after moving the site?
Keeping it for a short overlap is sensible. It lets you compare speed directly, recover anything the migration missed and switch back if something serious goes wrong. Cancel it once you have confirmed the new site works fully, has a backup, and is at least as fast.
How do I know if the new host is genuinely slower than the old one?
Compare like with like: the server response time for the same cached page, the same uncached page and the dashboard, from the same test location, after you have set up caching and matched PHP settings. If the new server is still slower on cached pages with everything configured, the hosting itself is the likely cause.
Does moving to a new IP address affect speed or search rankings?
Not by itself. The address only decides which server answers; speed depends on that server’s setup and location. For search, Google treats a host change without URL changes as a routine move, provided the site stays reachable and returns the same content. Keep downtime short and watch Search Console for crawl errors afterwards.
Slowness after a move often sits somewhere between the server and the site, which is why our speed optimisation service includes a hosting server response time review alongside the caching, database and script work. If the new hosting turns out to be the real limit, we will tell you plainly.
Next in this series: Website Slow After a Redesign? Why New Sites Get Heavier
