01 · When it is the fix
We do not recommend a move by default.
Most security and performance problems are configuration problems, and moving them just relocates them. More often the answer is hardening what you already have. These are the cases where the host is genuinely the constraint.
You cannot see what is happening
Some managed hosts are opaque. When the site slows down you file a ticket and wait, with no visibility into what is consuming resources. During an incident that is the difference between acting and guessing.
Autoscaling turns an attack into a bill
Leave autoscaling on and a bot-driven attack can produce a four-figure invoice with no warning. Turn it off and the site hits a hard resource ceiling instead, at which point it starts dropping work, and the work it drops first is the third-party API calls your business depends on.
RuleNeither option is acceptable, and you have to pick one every month.
The plan is sized for traffic you no longer have
Plans are usually billed by visit count. If a large share of those visits are crawlers, you are buying capacity for robots, and the answer may be a differently shaped plan rather than a bigger one. Before you upgrade, it is worth finding out how much of your bill is robots.
The host own bot handling is hurting you
We have dealt with an environment where search engine crawlers were being blocked at the host level. Nothing breaks visibly when that happens. Rankings just decline and nobody knows why.
02 · How we migrate
Six steps, and the old site stays live through all of them.
Size the plan against real numbers
Before choosing anything we pull the actual traffic history: peak month, typical month, and the composition of it. On one recruitment site the peak was around 120,000 visits against a typical range of 60,000 to 70,000, so the plan was sized against the peak rather than the average.
If a meaningful share of that traffic turns out to be bots, we deal with that first, because it changes what plan you actually need.
RuleSizing against the average is how you end up back in an overage two months later.
Inventory the DNS before touching it
Every existing record gets listed: A, CNAME, MX, TXT. The web records are the easy part. MX and TXT are where migrations cause real damage, because getting those wrong breaks email delivery and domain authentication, and unlike a broken page nobody notices for days. Sites that have been running for years accumulate records nobody remembers adding.
Handle credentials properly
We ask for temporary access to the domain registrar for the migration window, and we ask you to change the password before sharing it and change it again afterwards to revoke access. Where two-factor is enabled we work out the handover in advance rather than discovering it at the cutover.
Keep the old host live
The old environment stays running and functional until the new one is proven under real traffic. If anything behaves unexpectedly, the domain points back and the site is exactly as it was.
RuleThis is the single most important part of the process and it is the part free migrations skip.
Migrate outside peak
The cutover is scheduled for a defined window at a low-traffic time, agreed with you in advance, with someone on your side available to test afterwards. On one client migration we moved the scheduled DNS change by a day specifically because the client wanted more of their team in the office to test it.
RuleTesting means more than loading the homepage. It means the forms submit, the integrations sync, the logins work and the search still returns results.
Configure Cloudflare as part of the same job
If the reason for moving is security or bot load, deploying Cloudflare afterwards as a separate project means going through DNS propagation twice and paying for two mobilizations. We point the domain at Cloudflare, migrate to the new host, then configure the rules, in one sequence.
03 · What to expect
Four answers before you ask.
Downtime
None, in normal circumstances
The old environment serves traffic until the new one is verified, and DNS changes propagate rather than switching instantly.
Timeline
An hour or two at the cutover
The preparation around it, sizing, DNS inventory, staging and verification, is the bulk of the work.
Data
Nothing is deleted until you sign off
The old environment is decommissioned only once you have accepted the new one.
Cost
A fixed scope, after we have looked
The variables are the number of integrations that need verifying and whether email is hosted on the same domain.
Migration is one piece of our wider WordPress security work. After the move, updates, monitoring and backups sit with our maintenance service.
Common questions
My host offers free migration. Why pay for this?+
If you are moving for price or convenience and the site is straightforward, take the free migration. Pay for this when you are moving because something is broken, because then the migration is the small part and the diagnosis, sizing, DNS work, security configuration and rollback plan are the actual job. A free migration will not tell you why the old setup failed.
Will my SEO be affected?+
Not if it is done correctly. URLs stay identical, redirects are preserved, and the site stays available throughout. The risk in a migration is not the move itself, it is the broken redirects and missing records that come with a careless one. We verify the site is crawlable from the new environment before the old one is decommissioned.
What about my email?+
Email usually lives with a separate provider and is controlled by MX and TXT records. Those records are inventoried and migrated with the rest, and verified afterwards. This is the most common way DIY migrations go wrong.
Which host do you recommend?+
It depends on the site. We have migrated clients onto managed WordPress platforms where visibility into resource use and sensible bot handling were the deciding factors, not price. We will explain the reasoning in writing before you commit.
What if the new host turns out to be worse?+
That is what the rollback is for. The old environment stays live and functional throughout, so if the new one underperforms the domain points back and you are where you started, minus the migration fee.
Can you migrate a site you did not build?+
Yes, that is most of them. We need access to the current host, the domain registrar and the site itself.
