Most WordPress migration guides read like this: export the database, upload the files, import, change the settings, done.
If it really were that simple, nobody would give up halfway through. This article does not repeat those three steps; it covers the six things that actually get you stuck.
The 30-second version
| Item | Detail |
|---|---|
| The step most likely to break | Old URLs in the database cannot be string-replaced |
| The nastiest failure | Form email stops sending while the site looks perfectly fine |
| Handle in advance | Clean the database, deactivate plugin licenses, lower the DNS TTL |
| Test right after the switch | Form email, redirect rules, payment callbacks |
| When to cancel the old host | Keep it at least one to two weeks |
1. The database is much bigger than you expect
Plenty of people discover it on their first export: a site with only 50 posts somehow has a database of several hundred MB.
The bloat usually comes from three places — post revisions (one more row every time you hit save, so a post you edited ten times has ten copies), expired transients (plugin cache data, which many plugins write and never clean up), and orphaned settings accumulating in wp_options (the plugin was deleted, its settings stayed).
Clean these out before migrating and the export file is far smaller and the import far faster. Do it on the old host, not after you have moved.
2. Plugin licenses are usually tied to the domain
Licenses for paid plugins and themes are normally tied to a domain or an install count. After you move to a new environment they quietly stop receiving updates — **no error appears, they simply stop updating**, and you find out months later that you are running an old version.
Before migrating, go into the account dashboard for every paid plugin and deactivate the old site's license. Nobody is going to remind you about this one.
3. Old URLs in the database cannot be brute-force replaced
This is the item that goes wrong most often.
Absolute paths are scattered all through your content — image URLs, internal links, plugin settings. When the domain changes, all of them need updating.
But you cannot do a string replace in SQL. A great deal of WordPress configuration is stored in serialized format, and that format records the string's length in front of it. Replace old.com with newsite.com without updating the length number and the whole blob is corrupted — usually showing up as a plugin's settings vanishing entirely, with no visible cause.
Use a migration tool that understands serialized data, or WP-CLI's search-replace command. Do not open the database and do a find-and-replace yourself.
4. Email stops going out
Shared hosting normally lets you send mail straight through PHP's built-in mail(), which is why your contact form has always worked.
After moving to a containerized managed environment, that route is usually closed — for abuse prevention, not because the feature is missing. The result: the site looks completely normal, but nobody receives anything when the form is submitted.
The nastiest part is that the front end shows no sign of trouble, and the visitor also believes it went through. This is the first thing to test after migrating. The fix is an SMTP plugin pointed at your own mail service or a third-party sending service.
5. .htaccess does not necessarily carry over
Shared hosting is almost always Apache, with the rules in .htaccess. If the destination environment runs a different web server (RoamerHost uses OpenLiteSpeed), most rules are compatible, but not all of them.
Pay particular attention to the ones you added yourself: redirect rules, hotlink protection, IP blocks, cache headers. When these stop working there is no error, they simply no longer take effect — redirects from old URLs break and your SEO starts sliding.
6. The DNS switch has a gap
Switching DNS is not instantaneous. The old resolution result lingers in DNS caches around the world for a while, and during that window some people see the new site and some see the old one.
If anyone comments, orders or fills in a form on the old site during that window, that data stays on the old site — which you already exported.
Two things limit the damage: lower the domain's TTL before switching (to 300 seconds, for example) and wait for the old value to expire before you cut over; and make the switch during your lowest-traffic hours, usually late at night.
One more thing — do not cancel the old host immediately. Keep it for at least one to two weeks and confirm nothing was left behind. That money is insurance.
A checking order
| When | What to do |
|---|---|
| One week before | Clean the database, deactivate paid plugin licenses, lower the DNS TTL |
| Migration day | Migrate with a tool that handles serialized data; test the new site through your hosts file before switching DNS |
| Right after the switch | Test form email, test redirect rules, test payment callbacks |
| Two weeks after | Confirm no new data landed on the old site, then cancel it |
When migrating is not worth it
Let's be honest: if your site is purely content, traffic is modest, and shared hosting has never caused you trouble, the risk of migrating may outweigh the benefit.
The signals that make it worth it are fairly concrete — the site slows down inexplicably at certain hours (the noisy-neighbor effect), support cannot solve your problems, or you have started doing business on the site and downtime now costs you. Without those signals, your time is better spent on content.
FAQ
Q: Why can't I just replace the URLs directly in SQL?
A great deal of WordPress configuration is stored in serialized format, and that format records the string's length in front of it. Replace the old URL with a new one without updating the length number and the whole blob is corrupted — usually showing up as a plugin's settings vanishing entirely, with no visible cause. Use a migration tool that handles serialization, or WP-CLI.
Q: The site works after the move, but the form email never arrives?
This is the most common and the nastiest failure. Shared hosting usually allows PHP's built-in mail function; containerized environments normally disable it to prevent abuse. The front end shows nothing at all, and the visitor also believes it went through. Install an SMTP plugin pointed at your own mail service — but be sure to test it yourself.
Q: How long does a DNS switch take?
Not instantly. The old resolution result stays in caches around the world for a while, and during that window some people see the new site and some the old. Lower the TTL before switching (to 300 seconds, for example), wait for the old value to expire, and pick your lowest-traffic hours.
Q: Can I cancel the old host right away?
Don't. Keep it for at least one to two weeks and confirm nothing was missed — if someone comments or orders on the old site during the DNS gap, that data is already outside your export. The money is insurance.
Q: When is migrating not worth it?
If the site is purely content, traffic is modest, and shared hosting has never caused you trouble, the risk outweighs the benefit. The signals that say yes are: inexplicable slowdowns at certain hours (the noisy-neighbor effect), support that cannot solve your problems, or business running on the site so that downtime costs you.
Sources and further reading
For WordPress specifications and best practices, the official documentation is authoritative:
- WordPress official user documentation
- WordPress developer documentation — technical specifications for plugins and themes
Further reading
- Self-hosted vs managed WordPress: a cost table that counts maintenance time
- The limits of fully managed WordPress: what you cannot do
- WordPress custom domains: DNS setup and SSL certificates
- WordPress hosting FAQ: plugins, PHP settings and troubleshooting
- RoamerHost managed WordPress plans
Want someone to build it for you?
When your requirements go beyond what plugins can do, someone has to touch the code. Roamer Tech takes on advanced WordPress development:
