1. Dead Plugins (Including the Ones That Are Still Active)
The average WordPress site we migrate has 18 active plugins. Of those, typically four to six are doing something the site actually needs. The rest are either completely inactive, duplicating functionality that another plugin already handles, or doing something the site used to need but doesn't anymore.
We've migrated sites with three different SEO plugins running simultaneously. Sites with two contact form plugins — one from the original build, one added by a developer who couldn't find the first one's settings. Sites with WooCommerce installed on a site that has never sold anything, because someone thought they might add a shop and then didn't.
Every active plugin is a PHP file running on every page load. Dead plugins slow the site. Forgotten plugins go unpatched and become security liabilities. We remove all of them and rebuild only what the site actually needs — usually nothing, because static HTML doesn't need plugins.
2. Page Builder Scaffolding
Elementor, Divi, Beaver Builder, WPBakery — every major page builder wraps your actual content in layers of nested divs, inline styles, and proprietary shortcodes. When you export the content of a page built with Elementor, you don't get clean HTML. You get something like:
[et_pb_section fb_built="1"][et_pb_row][et_pb_column type="4_4"][et_pb_text]Your actual content here.[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
That shortcode syntax only renders correctly in a WordPress environment with the page builder plugin active. Strip the plugin, and you get raw shortcode brackets in the middle of your content. The page builder's contribution to the actual design is zero — we reconstruct the layout from scratch in clean HTML.
The visual result is identical. The codebase is a fraction of the size. Page load time drops noticeably.
3. Duplicate and Conflicting Stylesheets
A typical WordPress site loads between 8 and 15 separate CSS files on every page: the theme's base stylesheet, the theme's customiser output, each plugin's stylesheet, the page builder's stylesheet, the child theme overrides, and whatever inline styles were added directly through the WordPress customiser.
These files conflict with each other routinely. The page builder's button styles override the theme's button styles. A plugin's form styles break the theme's input styling. The customiser adds !important declarations to force overrides. The result is CSS that nobody fully understands, can't be edited safely, and adds 200–400KB to every page load for a site that could be styled in 15KB of clean CSS.
We start from scratch. One stylesheet. No conflicts. No overrides.
4. Abandoned Drafts, Revisions, and Orphaned Media
WordPress stores every revision of every post and page in the database. A page that was edited 40 times over four years has 40 revision records sitting in the database, all being queried against on every admin load. We've seen databases with 50,000 revision records for a 12-page site.
The media library is often worse. Images uploaded and never used. Multiple sizes of every image (WordPress generates up to six resized versions of every upload). A photo gallery from a 2019 event that's no longer linked anywhere on the site. None of it is cleaned up because WordPress doesn't surface these problems — it just quietly accumulates them.
We export only the content the site actually uses. Clean copy, current images, nothing else.
5. Tracking Scripts Nobody Knows About
Almost every site we migrate has at least one analytics or tracking script installed by someone who is no longer involved with the site. An old Facebook Pixel from a 2021 ad campaign that was never paused. A Hotjar session recording tool that's been running for three years on a site with 200 monthly visitors, recording nothing useful and slowing the page. A Google Tag Manager container with 14 tags, seven of which are disabled, two of which point to a Google Analytics property that was deleted.
We ask every client to confirm what tracking they actually want. Everything else comes out. The result is a site that's faster, more privacy-compliant, and not sending user data to platforms nobody is monitoring anymore.
Frequently Asked Questions
How long does a WordPress migration take?
Our standard migration takes approximately two weeks from kickoff to launch. Week one is content extraction, cleanup, and build. Week two is review, refinement, DNS migration, and launch. More complex sites — those with custom functionality, large content libraries, or ecommerce components — may take longer. We scope each project individually after a site audit.
Will I lose content in a WordPress migration?
No. The migration process extracts all current content — pages, posts, images, forms — and rebuilds it in clean HTML. Archived or draft content is not migrated unless specifically requested, but nothing on the live site is lost. We provide a full review period before DNS cutover so you can verify everything before going live.
What happens to my WordPress plugins after migration?
They're not needed. Static HTML sites have no plugin architecture. Functionality that was handled by plugins — contact forms, SEO metadata, analytics, payment processing — is rebuilt using lightweight, purpose-built alternatives. Contact forms use Tally. Analytics can be handled by any script-based tool you prefer. The result is the same functionality with none of the plugin maintenance overhead.
See What WordPress Is Costing You
Use our free calculator — enter your real numbers and see the 3-year comparison.
Do the Math →