7 WordPress Migration Mistakes to Avoid (and the Plugin Bills You Can Cancel)
Moving a WordPress site to fast, static code is one of the best decisions a content-heavy business can make: pages load in milliseconds, there is almost nothing left to hack, and hosting can drop to near zero. We cover the full process in our guide to migrating WordPress to a static site. This article is the other half of the story: the pitfalls that quietly catch people out, and how to sidestep each one.
None of them are hard to avoid. They are just easy to forget in the excitement of launching something faster. The examples here come from real WordPress-to-code migrations, including a 260-page bilingual business site we moved recently, so these are the traps that actually bite, not hypotheticals. Here are the seven that matter most, roughly in the order you will hit them.
1. Assuming you will still be able to log in to wp-admin
This is the one that surprises people the most. Your WordPress dashboard lives at yourdomain.com/wp-admin. The moment you point your domain at the new static site, that address stops serving WordPress, so the login screen you have used for years simply is not there anymore.
You have not lost the WordPress software or its database. What you have lost is the route to it, because the domain now leads somewhere else. If you did not plan for this, you can be locked out of your own content history, old drafts, and settings on the very day you go live.
The fix: give old WordPress its own address before you switch. Move the existing install to a
subdomain such as old.yourdomain.com, or keep it on a temporary fallback domain, before
you change the DNS on your main domain. Then wp-admin stays reachable at the new address (for example
old.yourdomain.com/wp-admin) for as long as you need it. Add a noindex tag to that old
copy so Google does not index a duplicate.
If your host offers a staging or "temporary URL", that counts too. On a recent migration we simply parked the
old WordPress at archive.yourdomain.com before flipping the main domain, which freed the main address
for the new site while keeping the old one fully reachable for reference and instant rollback. The point is simple:
decide where old WordPress will live after the switch, and set it up before the switch, never the
other way around.
2. Migrating before you have a full export and backup
Never start a migration from a live site you cannot rebuild. Before anyone touches anything, take a complete copy while the old site is still online and healthy. Export three things:
- Your content. In WordPress, go to Tools → Export and download the XML of all your posts and pages. This is your text safety net.
- Your media library. Download the
wp-content/uploadsfolder (via your host's file manager or FTP) so every image, PDF, and logo is safe, along with a full database backup if your host offers one. - Your sitemap. This is the one people forget, and it matters most for SEO.
Why the sitemap is the piece you must not skip
Your XML sitemap (usually at yourdomain.com/sitemap.xml or sitemap_index.xml) is the
complete, machine-readable list of every URL Google knows about on your site. That list is exactly what you need
to build your 301 redirect map, so no old link, ranking, or bookmark breaks after the move.
Save the sitemap while the old site is live, because the moment WordPress is gone the plugin that generated it is
gone too, and rebuilding that URL inventory from memory is painful.
Redirects are what protect your Google rankings during a move. Google's own
site
move guidance is clear that mapping old URLs to new ones with 301s is how authority carries across. The best
source for that redirect list is not guesswork, it is the Pages export in Google Search Console,
which shows the exact URLs that already earn traffic and backlinks. On the recent migration that produced 39
redirects, and it is easy to miss the less obvious ones: old Yoast sitemap addresses, and lead-magnet PDFs sitting
under /wp-content/uploads/ that other sites still link to. If keeping your rankings is the priority,
read our dedicated guide on
moving off WordPress without losing rankings.
3. Switching off the old site too early
The old WordPress site is your safety net, so do not pull it on day one. Keep it reachable in parallel (on that subdomain from mistake #1) for at least two to four weeks. Use the window to compare pages side by side, confirm every redirect resolves, check that forms and email still work, and give Google time to recrawl and reindex the new URLs. Only once the new site is verified should you think about winding the old one down. With ShiftPress, your original site stays available for at least 14 days after go-live for exactly this reason.
4. Forgetting to cancel WordPress-only subscriptions
Here is the pitfall that costs real money, and the good news is you can fix it after the migration, once the new site is proven. A static site has no plugins and no PHP, so most of the paid tools that kept WordPress running are now doing nothing but charging you. Yet the invoices keep arriving on autopilot because nobody thought to cancel them.
Go through your card statement and your plugin licences and cancel everything that only existed to prop up WordPress. That typically includes:
- Managed WordPress hosting (WP Engine, Kinsta, SiteGround) — a static site hosts on a free or near-free tier like Cloudflare Pages.
- Your page builder (Elementor Pro, Divi) — no longer part of the site.
- Caching and performance (WP Rocket) — a static site is already fast by design.
- Security and firewall (Wordfence Premium, Sucuri) — there is almost no attack surface left to defend.
- Backup (UpdraftPlus Premium) — your site is now versioned code.
- SEO (Yoast Premium, Rank Math Pro) — the metadata is baked into the pages.
- Forms and extras (WPForms Pro, Gravity Forms, membership or slider plugins) — replaced by a lightweight service or built in.
An example of how much you save
Numbers vary, but here is a realistic yearly bill for a modest WordPress business site, using typical published prices. Yours may be higher if you run a page builder, a membership plugin, or premium managed hosting.
| WordPress subscription | Typical cost / year | On a static site |
|---|---|---|
| Managed WordPress hosting | ~ €300 | €0 (free tier host) |
| Page builder (Elementor Pro) | ~ €59 | €0 |
| Caching (WP Rocket) | ~ €59 | €0 |
| Security (Wordfence Premium) | ~ €119 | €0 |
| Backup (UpdraftPlus Premium) | ~ €70 | €0 |
| SEO (Yoast Premium) | ~ €99 | €0 |
| Forms (WPForms Pro) | ~ €100 | €0 |
| Total | ~ €806 / year | ~ €0 |
That is around €800 a year, or roughly €67 a month, that stops leaving your account, on top of never paying a developer for a plugin-conflict emergency again. Even a lean site with just hosting and two or three plugins usually saves €300 to €400 a year. For the full picture of what WordPress really costs to keep running, see our breakdown of website maintenance cost and what a WordPress website costs.
One caution before you cancel. Do not cancel anything until the new site is live, verified, and you have taken a final backup (see mistake #2). Cancel hosting last of all, and confirm your final export is safely stored, because cancelling managed hosting usually deletes the WordPress install for good.
5. Breaking your email (and forms) when you repoint the domain
A static site has no server-side code, so anything WordPress did behind the scenes needs a new home. Contact and booking forms move to a lightweight form service or a built-in handler. Comments can use a service like Giscus or Disqus.
If this sounds fiddly, it isn't something you have to solve yourself. ShiftPress takes care of all of it and ships with a built-in form builder, so your contact and booking forms keep working after the move without you wiring up a separate service or writing any code.
The bigger trap is email. If your domain also runs your mailboxes, they are controlled by separate DNS records (the MX records, plus SPF/DKIM). When you repoint the domain to the new site you only need to change the address (A) record, so leave the MX and mail records exactly as they are. Touch them by accident and your email stops arriving. On a recent move the domain had five live mailboxes, and the whole trick to keeping them working was simply not touching the MX records while switching the A record. Two safety habits make this painless: take a screenshot of your full DNS zone (A, MX, TXT, everything) before you change anything, and lower the record's TTL a day or two beforehand so any rollback takes effect in minutes, not hours.
6. Skipping the handover to search engines and AI
After go-live, submit your fresh sitemap in Google Search Console so Google learns the new structure quickly, and keep an eye on the Coverage and Redirects reports for the first few weeks. This is a five-minute job that prevents weeks of "why did my traffic dip" worry. Rankings usually wobble slightly during recrawl and then settle, provided your 301s are in place.
There is a newer, easy-to-miss version of this pitfall: don't accidentally block the AI crawlers. A lot of hosts and security firewalls (WAFs) are set to reject anything that does not look like a normal browser, which quietly turns away the bots behind AI answers, GPTBot (ChatGPT), ClaudeBot, PerplexityBot and Google's AI crawlers. If those get a "403 forbidden", your site simply cannot be cited in AI search, no matter how good the content is. After a move, check your host or firewall settings and make sure those user-agents are allowed through. It is one of the highest-leverage things you can do for GEO (getting quoted by AI engines), and almost nobody checks it.
One more five-minute check that saves a lot of heartache: open the live site on the real domain right after cutover, not just on your laptop, and click through a few pages. On one migration the homepage looked perfect locally but a batch of partner logos loaded as broken images on the live host, because an image path resolved differently in production. A quick look at the real URL catches that in minutes.
7. Choosing a method that leaves you unable to edit
The last pitfall is strategic. The popular plugin exporters (Simply Static, WP2Static) create a frozen snapshot: to change one sentence you have to go back into WordPress and re-export the whole site, which means you are stuck maintaining WordPress forever, exactly the thing you were trying to escape. If you pick that route, mistakes #1 and #4 come back to bite you, because you can never actually shut WordPress down.
Skip the pitfalls entirely
ShiftPress moves your WordPress site to clean, version-controlled code and keeps it editable, you describe changes in plain language, preview them, and publish. We handle the export, the redirects, and the safety net, so there is no wp-admin to lose and no plugin bill to babysit.
Get started ↗A pre-migration checklist
Run through this before you flip the switch:
Frequently asked questions
Do I lose access to wp-admin after migrating?
What should I export before I migrate?
Can I cancel my plugin subscriptions after moving?
When is it safe to shut down the old WordPress site?
The bottom line
Migrating WordPress to code is a big upgrade, and almost every pitfall comes down to sequence. Set up a home for old WordPress before you switch, export everything (the sitemap above all) while the old site is live, keep it as a safety net for a few weeks, and only then cancel the subscriptions you no longer need. Do it in that order and you keep your content, your rankings, and a few hundred back in your budget. Or let a managed platform like ShiftPress handle the whole sequence for you, so there is nothing to lose in the first place.