Migration guide
Hosting for a migration: what the host controls, and what it cannot fix
Hosting is the part of a migration people either agonise over for a fortnight or decide in four minutes on price. Both are wrong, and interestingly they are wrong about the same thing.
The reason hosting is hard to choose is that the things it is sold on are not the things it decides. Tiers are advertised in storage, bandwidth and visits per month, which are almost never what constrains a content site. Meanwhile the things a host genuinely determines — how fast a page is assembled, whether it stays up under a spike, and which headers travel with every response — appear on nobody's pricing table.
So here is the version organised around what the host actually controls. The numbers come from our scan of 27,385 live sites, which you are welcome to download and check.
Size on page weight, not on visitors
The number on the pricing page is rarely the number that binds.
A content site is bound by how quickly it can assemble and deliver a page, and page weight is a decent proxy for that. In our sample, WordPress sites average 299.1 KB of HTML with 18.2 script tags. Drupal sites average 186.4 KB and 17.1. Those are not small differences, and they land on the host as work per request.
The practical consequence is that the platform you are moving to changes the hosting you need, independently of how much traffic you get. A heavier stack with more scripts wants more caching and more origin capacity to feel the same. If you are moving to a platform that ships more markup than the one you are leaving, matching your current tier will feel like a downgrade even though nothing about the traffic changed.
The headers nobody sees are set here
Invisible in the browser, which is exactly why they go missing.
Three security headers matter enough to check on day one: HSTS, which forces HTTPS on subsequent visits; X-Content-Type-Options, which stops browsers guessing at file types; and a content security policy, which limits what can execute on your pages. All three are typically set at the host, CDN or server layer rather than by the CMS.
They are also strikingly uncommon. Across our sample, 49.5% of WordPress sites send HSTS, 40.1% send X-Content-Type-Options, and 25.8% send a content security policy. Drupal fares better on two of the three at 72.7% and 97.6%. Nothing about either platform prevents any of it. They are simply not on by default, and a migration is the one moment when adding them costs nothing — you are configuring a new environment from scratch anyway.
This is the specific way a migration can leave a site less protected than the one it replaced, without anybody doing anything wrong. The old server had headers somebody added in 2021. The new one has whatever the default is.
What a host cannot fix
The expensive problems live in the template, not the tier.
Upgrading hosting will not restore structured data that the new theme stopped emitting. It will not repair a canonical tag pointing at the staging domain, and it will certainly not rebuild a redirect map. Those are template-level and migration-level problems, and they are the ones that actually move traffic.
This matters because slow-feeling sites after a migration get blamed on hosting more often than hosting deserves. Before you buy a bigger tier, check whether the pages themselves got heavier — the platform change usually explains more of it than the server does.
When to move hosts and platforms together
Usually together. Occasionally, deliberately not.
Do both at once by default. You are rebuilding the deployment pipeline regardless, and splitting it into two cutovers means two rounds of DNS work, two testing windows and two opportunities to lose something.
The exception is when hosting is the actual complaint. If the site is already slow or unstable, move it to solid hosting first and let it sit there for a few weeks. That gives you a stable baseline to measure the migration against, so when performance changes afterwards you can tell which decision caused it. Without that, you have changed two variables and can only guess.
A note on what this page does not do
It names no hosts and carries no affiliate links. Hosting recommendations are among the most heavily monetised content on the web, which is precisely why they are worth being careful about — the ranking usually reflects commission rather than performance.
What we can tell you is what to test for, because we measure it: response time under a realistic page weight, and whether the headers above arrive. Any host that does both is fine. Most of the rest of the decision is about who you want to call when it breaks.
FAQ
Frequently asked questions
How much hosting do I need after a CMS migration?
Less than most people buy, and more than the cheapest tier. Page weight is the honest input: WordPress sites in our sample average 299.1 KB of HTML and 18.2 script tags, Drupal 186.4 KB and 17.1. A site that ships that much markup is bound by how fast it can be generated and delivered, not by raw disk or bandwidth, which is what tiers are usually sold on.
Does my host affect search performance?
Indirectly but genuinely. Response time and uptime are the obvious paths. The less obvious one is that the security and caching headers a host sets — or fails to set — travel with every page, and they are invisible in the browser, so nobody notices when they are missing.
Which security headers should hosting set?
At minimum HSTS, X-Content-Type-Options, and a content security policy. These are far from universal in practice: 49.5% of WordPress sites we measured send HSTS, 40.1% send X-Content-Type-Options, and 25.8% send a CSP. Nothing about the platform prevents any of them — they are simply not on by default, so they arrive only if somebody decides they should.
Should I move hosts and platforms at the same time?
Usually yes, because you are rebuilding the deployment anyway and doing it twice costs more than doing it once. The exception is when the site is already in trouble — if performance or uptime is the actual problem, move hosts first, get a stable baseline, and then replatform against something you can measure against.
Is managed hosting worth it?
It is worth it when nobody on your team wants to own patching, backups and uptime, which is most teams. What you are buying is the absence of a job, not speed. If somebody on the team genuinely enjoys running servers, unmanaged is cheaper and no worse.
Want to know what your current site actually emits before you move it? The free instant grade checks the headers above on a live URL, or the migration assessment works without one.