WordPress to Statamic: how your page builder shapes the migration cost
Most "migrate WordPress to Statamic" guides assume you're on plain Gutenberg. Real business sites run ACF, Elementor, Divi or WPBakery — and that choice shapes migration cost more than any other factor. Here's how to spot your situation and what to ask before signing scope.
To put numbers behind that: Advanced Custom Fields is active on more than 2 million WordPress sites, and Elementor on more than 10 million (per the WordPress.org plugin directory), with Divi and WPBakery filling out the visual-builder layer below them. The plugin layer you can't see from the outside is what drives most of the migration bill.
This piece walks through how to recognize what you actually have, what each archetype costs to migrate, where the bills hide, and what to ask before you sign a scope. It's for owners and decision-makers, not developers.
First, figure out what you have
You don't need code access. You need ten minutes in your WordPress admin and one good question for whoever currently maintains the site.
In the admin sidebar, look for:
A "Custom Fields" or "ACF" menu → ACF-driven
An "Elementor" menu with "Templates" or "My Templates" → Elementor
A "Divi" menu with "Theme Options" → Divi
"WPBakery" or "Visual Composer" → WPBakery
None of the above, only standard Posts/Pages/Appearance → Vanilla / Gutenberg
Then ask your developer one sentence: "What's the page builder, and is most content managed through ACF fields or directly in the editor?" The answer determines your scenario. Skipping this step is how migration scopes silently double.
The four starting archetypes
Real WordPress sites fall into four broad shapes. Most are mixes — but the dominant element drives the cost story.
Vanilla / Gutenberg
Easiest case. Content lives in standard WordPress fields, no proprietary layout markup baked in. Migration is mostly content remapping plus redirects. Lowest range, most predictable timeline.
ACF-driven
The friendliest non-vanilla case. Your content sits in structured fields (text, image, repeater, gallery), and the templates render it. A developer can map ACF fields to Statamic's content modeling with high fidelity, often via a one-off script. Mid range, predictable.
Visual builders — Elementor, Divi, WPBakery
The hardest case, and the most common in serious business sites. Content and layout are fused: a paragraph isn't just text, it's text inside a builder-specific module with styling baked in. Extracting "just the content" rarely works cleanly. Largest range, widest unknown. We expand on this below because it's where most surprises live.
Mixed
The realistic majority. ACF for the content types, Elementor for landing pages, Gutenberg for the blog. Cost lands wherever your largest "hard" component lands — usually the visual builder section. Plan contingency.
Why visual builders are the main risk
When a site uses Elementor, Divi, or WPBakery, the page content does not exist independently of the layout. A "hero with three columns and an icon list" isn't three text paragraphs — it's a serialized blob in WordPress's database that says "use this builder's module, with these settings, in this position." Strip away the builder and you're left with raw markup that no other system can read meaningfully.
That's why "just export the content" doesn't work for these sites. You have three honest options:
Rebuild from scratch. A designer-developer pair recreates each page in Statamic. Predictable cost, longer timeline, highest quality — you also get to fix accumulated layout drift along the way.
Partial extraction plus cleanup. A script pulls visible text and image references out of the builder markup; a person reassembles each page. Cheaper, but visual fidelity drops noticeably.
Parallel approach. Build the new Statamic site alongside the live WordPress one. Migrate page by page in priority order. Switch traffic when ready. Lowest single-shot risk, useful when downtime tolerance is low.
The right choice depends on how much of your existing visual design you care to preserve, how many pages need to move, and how much calendar time you have. Most projects we see end up combining two of these — for example, parallel build for the marketing pages, partial extraction for blog archive content.
Things every migration has to handle
Regardless of archetype, every WordPress-to-Statamic migration covers the same five universal concerns:
Redirects — without a 301 map from old URLs to new, search rankings drop within weeks. Non-negotiable.
Media — every image and PDF must move and stay reachable from its old URL.
Search standing — Yoast or Rank Math metadata maps over to Statamic's SEO equivalents.
Forms and integrations — contact forms, CRM, newsletter wiring. Sometimes a like-for-like Statamic equivalent exists; sometimes you rewire.
Editor retraining — your team learns a new admin. Plan one to two hours of guided handoff.
These aren't differentiators between archetypes — they're constants. But they need to be in every contract.
Automated migration tools — what they can and can't do
A WordPress importer addon for Statamic exists. It can pull pages, posts, taxonomies, and simple content. On a vanilla WordPress site, it does meaningful work.
For anything else — ACF custom fields, Elementor builder content, Divi shortcodes, WPBakery markup — the importer pulls in the rendered HTML, not the structured content. You end up with a Statamic site full of frozen HTML blocks, no editable structure underneath. Future content edits become painful.
The rule: any agency pitching "we'll automate the whole thing" without first running a proof of concept on your specific site is selling you a hope, not a plan. The cost of unwinding a bad automated import usually exceeds the cost of a well-scoped manual migration.
Realistic budget bands by archetype
No single number — every site is different — but here are the ranges to expect for a typical small marketing site (10–30 pages, a blog, contact forms; not e-commerce):
| Archetype | Realistic time | Budget band | Key driver |
|---|---|---|---|
| Vanilla / Gutenberg | 1–2 weeks | Small | Content count |
| ACF-driven | 2–4 weeks | Medium | Field complexity |
| Single visual builder | 4–8 weeks | Larger | Page count + design fidelity required |
| Mixed | 4–10 weeks | Largest, with contingency | Whichever path is biggest in your mix |
For the cost of running the new Statamic site over three years (separate from migration), see our 3-year cost and performance model — the migration sits at the front of those numbers.
Questions to ask before signing scope
Use these in the kickoff call. The answers separate careful agencies from optimistic ones:
"Have you looked at our actual content structure, not just the page count?"
"What's your specific plan for the [your builder] pages?"
"What do we lose if we don't redo content from scratch?"
"How are redirects handled, and at what coverage?"
"Which integrations break, and what replaces them?"
"How do you handle our translations or other languages?"
If you can't get specific, scope-defined answers to these, the price you signed will move.
When NOT to migrate
Some sites aren't worth the move. Honest signals:
Site traffic is dying anyway — migration won't fix a marketing problem.
The site is edited once every two or three years — there's no maintenance pain to relieve.
You're locked to a WordPress-only plugin (LearnDash, BuddyBoss, a complex WooCommerce setup) with no Statamic equivalent in your roadmap.
Sometimes the right answer is "stay, patch, save the budget."
About this article
I'm Andrii Trush. I work on Statamic projects across Europe — I've migrated WordPress sites of every shape on this list, and I've also told prospects when not to bother. The numbers and shapes above come from those projects, not from a vendor deck. If you want a sanity check on your own situation, get in touch.
Can we keep the existing WordPress site live while building the Statamic version?
Yes — that's the parallel approach mentioned in the body. You keep WordPress running on its current domain and build Statamic on a staging URL until ready. The switch happens at DNS level once the redirect map is in place. It costs slightly more in calendar time but eliminates downtime, which matters most for sites that get steady traffic or run paid campaigns.
How do we protect our search rankings during the migration?
Three things matter: a complete 301 redirect map from old URLs to new (including pagination, taxonomy archives, and feed URLs), preservation of meta titles and descriptions, and submitting the new sitemap to Google Search Console as soon as the new site is live. Most ranking drops we've seen during migrations come from missed redirects on long-tail URLs — blog posts from years ago that still get search traffic. A serious migration scope includes a redirect QA pass, not just the obvious main pages.
What happens to our existing WordPress plugins after migration?
Each plugin needs an explicit replacement decision. Some have direct Statamic equivalents (forms, SEO, analytics — all covered by Statamic addons or built-in features). Some have to be rewired through different tools (newsletter integrations often shift to handling at the form-submission level). A handful won't have equivalents at all and will need a custom build or a rethink. Map your active plugins before quoting — surprises here are the second-largest budget killer after page builders.
Should we redesign during the migration, or migrate first and redesign later?
Usually do them together when the existing design is genuinely tired or when you're paying for visual builder content extraction anyway — you're already touching every page. Migrate first when the current design is fine and the goal is just escaping WordPress operational pain. Doing both simultaneously costs less in total than two sequential projects, but adds risk: scope creep is real. If you bundle them, lock the new design before the migration code begins, not in parallel.