Somewhere in the second year, most Prismic teams have the same meeting.
Marketing wants a new section on a landing page, assembled from things the site already does elsewhere. The answer is that it needs a new Slice: modelled in Slice Machine, built as a component, reviewed, deployed. Nobody thinks the process is wrong. Everybody knows the section is not shipping this week.
That is where most Prismic migrations start, and it is not evidence of a bad product. The Page Builder is one of the better editing experiences in headless CMS, Slices are a smart way to model a page, documents and assets are unlimited on every plan, and the pricing is published and cheap against any enterprise DXP.
All of that stays true, and the section still is not shipping this week. Editors can build pages freely from the Slices that already exist, and that is what the Page Builder is good at. The wait shows up when the page needs a section the Slice library does not have yet, because a new Slice is built by developers by design.
That is the trade, and it is worth making for some teams and not for others. This guide covers whether moving to WordPress is right for you, what the migration costs, and how it runs.
Here is the roadmap:
- PART 1: Should You Really Migrate? The Decision Framework. Start here
- PART 2: Understanding Your Migration Complexity. Start here
- PART 3: Choosing the Right Migration Partner. Start here
- PART 4: Why You Should Migrate from Prismic to WordPress. Start here
- PART 5: How to Migrate from Prismic to WordPress. Start here
- Frequently Asked Questions. Start here
If you would rather talk it through, you can schedule a free 30-minute consultation with one of our migration leads.
PART 1: Should You Really Migrate? The Decision Framework
Before scoping anything, work out whether the move is justified. Prismic suits a particular kind of team very well, and if you are that team you should stay.
1.1 The 6 Critical Questions
Answer these honestly. Write the answers down, because you will need them in vendor conversations anyway.
There is a real difference between “our developers have moved on and nobody maintains the front end”, “marketing cannot ship a new section without a deploy”, and “we have outgrown the plan limits”. The first is an ownership problem. The second is architectural and is the most common reason teams leave. The third is a pricing conversation you may be able to have with Prismic directly.
If the answer is the second one, be specific about what kind of change is blocked. Adding a document against an existing Page Type is fast in Prismic. Adding a new kind of section is not, because Slices are built by developers from scratch. Knowing which of those your team actually needs is the difference between a real case and a vague frustration.
This is the most useful number in the whole assessment. Count the Slice requests raised in the last six months, and measure the time from request to live.
If new Slices are rare because your design system is stable, Prismic is working as intended and the model is a good fit. If your marketing team requests them constantly and waits weeks each time, you are paying a coordination tax on every campaign, and no amount of Prismic configuration fixes that. It is inherent to the architecture.
A custom Next.js or Nuxt front end is an asset when a team owns it and a liability when that team has moved on. Ask who has committed to the front-end repository in the last ninety days and whether that person still works on this product.
This changes the migration entirely. Teams keeping their front end run a very different project from teams replacing it, and the difference is most of the budget.
Count documents per Page Type, per locale and per repository. Prismic gives you unlimited documents on every plan, so the number can be larger than you assume, and nobody has ever had a reason to check.
The repository count matters more than teams expect, because Prismic bills per repository and multi-brand organisations often accumulate several without noticing the cumulative cost.
Include the migration, the Prismic subscription you will still be paying during the transition, internal time, and training. If the number you have in mind is below $50,000, a full enterprise migration will not fit, and you should be scoping a phased move or a narrower one.
Renewal-driven deadlines are the most common and the most dangerous, because they compress discovery and QA, which are the two phases that determine whether anyone judges the migration a success. Prismic annual terms are cheap enough that buying another year to get the timeline right is usually the correct trade.
1.2 Interpreting Your Answers
Strong signals that migrating is right for you. Marketing waits on developers for routine layout changes. Nobody actively owns the front-end codebase. You are managing several repositories and paying for each. Plan tier limits on locales, roles or backups are shaping decisions they should not be shaping. You want editorial and presentation back in one place.
Warning patterns that mean you are not ready. Nobody owns the decision. The business outcome is written as “move off Prismic” rather than as something measurable. Your document count across locales and repositories is unknown. The front-end decision has not been made, so the scope is undefined.
Scenarios where staying put is the right call. If you have a front-end team who own their stack and ship happily, if your design system is stable so new Slices are rare, or if you genuinely deliver content to several applications rather than one website, Prismic is doing the job it was built for and doing it cheaply. Migrating would cost you money and capability. We would rather say that now than nine months into a project.
1.3 The Go/No-Go Decision Tree
Five questions. Three or more “yes” answers means the case is real.
- Do routine layout changes require a developer and a deploy?
- Is the front-end codebase effectively unowned?
- Are plan tier limits on locales, roles or backups constraining you?
- Does your website account for the large majority of content consumption?
- Is there a named executive sponsor with budget authority who wants this to happen?
If you answered no to question five, stop. Migrations without a sponsor stall in month three, and a stalled migration costs more than never starting.
PART 2: Understanding Your Migration Complexity
Complexity on a Prismic migration comes from two places: how many distinct Slices you have to translate, and what you decide to do with the front end. Document volume matters less than people expect.
2.1 The Migration Complexity Scale
Prismic sits in the SaaS category, so there is no legacy server-side application to unpick. That lowers cost against a platform like AEM. It does not shorten timelines, because you have to build your own extractor and translate every Slice by hand. The ranges below are a starting bracket to test against your own numbers rather than a benchmark, and the five factors after them are what actually move the figure.
Simple Migration (8-14 weeks, $50K-$150K)
Under 5,000 documents in a single repository, one or two locales, a modest Slice library, and a decision to replace the front end with a WordPress theme. In practice this describes a marketing site or a product site.
Moderate Migration (14-24 weeks, $150K-$350K)
Between 5,000 and 50,000 documents, several locales or repositories, a Slice library in the dozens, five to fifteen integrations, and a front end you are either keeping or rebuilding deliberately. Most Prismic migrations land here.
High Complexity Migration (24-40+ weeks, $350K-$750K+)
Over 50,000 documents, multiple brands across repositories, extensive localisation, a bespoke front end serving several channels, or a regulated industry. If you are consolidating three or four Prismic repositories into one WordPress Multisite, you are here.
2.2 What Adds Time and Cost
Five factors move a Prismic estimate more than anything else.
Prismic has no export function. The Migration API creates and updates pages and does not read them back out, so extraction is a custom build against the Content API, which paginates at a maximum of 100 documents per request inside a 2048-character URL limit. The rate limit is 200 requests per second and CDN-cached queries are not limited at all, so throughput will not be what slows you down. The extractor will. It is engineering work with its own testing cycle rather than a command you run.
Keeping your existing Next.js front end and repointing it at WordPress is a different project from rebuilding the presentation layer as a WordPress theme. Both are valid. The cost difference is large enough that leaving the decision open past discovery makes the estimate meaningless.
Every Slice is a component with a field model and a rendered output, and each one needs a Gutenberg block equivalent. This is the largest single line in most Prismic estimates. Count your Slices early. Teams are routinely surprised by how many accumulated.
Prismic caps locales by plan tier and bills per repository, so organisations that grew past either ceiling have worked around it, usually by adding repositories. Consolidating those into one WordPress install or Multisite network is discovery work that is easy to underestimate.
User roles only exist from the Medium plan upward, and custom roles are Enterprise-only. Whatever governance you have, formal or improvised, needs restating as WordPress roles and capabilities.
2.3 The 3 Hidden Costs That Wreck Budgets
Every migration budget we have reviewed underestimates the same three line items. They are not exotic risks. They are predictable work that vendors leave out of proposals because including them makes the quote look worse than the competition’s.
What it actually costs: $50,000 to $100,000.
The technical migration moves documents. It does not move the mental model your editors built stacking Slices in the Page Builder. Those are separate problems, and the second surfaces three weeks after launch when publishing throughput has halved.
There is a specific opportunity here that other migrations do not have. Prismic editors already think in composable page sections, which is exactly how the WordPress block editor works. The conceptual leap is smaller than for almost any other source platform, so training lands faster. What changes is that the constraints loosen, and teams used to a curated Slice library need guidance on what they should and should not assemble now that more is possible.
Budget for structured workshops with your editorial leads before any content moves, field-by-field mapping documentation, and at least two rounds of hands-on training after launch rather than a single handover session.
What it actually costs: $40,000 to $75,000.
What it costs to skip: the organic traffic you lose while old URLs resolve to nothing, which on a content-heavy site is routinely worth more than the workstream itself.
Headless setups make this harder rather than easier, because URL structure lives in the front-end routing layer rather than in the CMS. Your redirect map cannot be generated from the content extract alone; it has to be reconciled against how the application actually routes.
The work is a full crawl of the live site, an export of every URL that has received organic traffic or an external link in the last two years, a one-to-one redirect map with no chains, and monitoring for at least ninety days after cutover with someone watching. Our growth services team runs this as a parallel workstream on enterprise migrations.
What it actually costs: $55,000 to $115,000.
Prismic gives you unlimited assets on every plan, which is generous and also means nobody has ever pruned. Expect the media library to be larger and messier than the inventory suggests.
The cost sits in reconciliation rather than transfer. Every asset needs its references rewritten, its metadata preserved where it exists, and its rendition strategy rebuilt, since Prismic handles image optimisation for you and WordPress will need that configured explicitly. Teams that discover this after document migration has run end up doing the whole thing twice.
2.4 Migration Readiness Checklist
Work through this before you talk to vendors. Every unchecked box is either a question you cannot answer in a scoping call or a cost that will appear later.
- The business outcome is written down and is not “move off Prismic”
- Executive sponsor named, with budget authority
- The front-end decision has been made: keep, rebuild, or decide during discovery with a stated deadline
- Success metrics agreed and currently measurable
- The cost of doing nothing has been calculated, including renewals across every repository
- Document counts known per Page Type, per locale and per repository
- Every Slice inventoried, with the page types that use it and how often
- Content that will not be migrated identified and signed off
- Content owners identified for every section
- Editorial workflow documented as it actually runs, not as the policy describes it
- Every integration inventoried, with an owner and a contract renewal date
- Front-end routing logic documented, since it holds your URL structure
- Integration Fields catalogued, with the external source each one pulls from
- Authentication and identity approach decided
- Hosting decision made
- Internal time commitment estimated honestly and cleared with those people’s managers
- Front-end engineering time specifically budgeted
- Training plan budgeted
- Post-launch ownership assigned
- Rollback plan defined
- Content freeze window agreed with the business
- Launch window avoids your peak trading or publishing period
- Legal and compliance have reviewed the plan
2.5 Timeline Reality Check
Most engagements run to the shape below. Discovery and QA are the phases compressed under deadline pressure, and they are the two that determine how the migration is judged six months later.
Two to three weeks discovery, Slice inventory and extractor build. Two weeks environment and theme setup. Two to three weeks content migration and verification. Two weeks QA and redirect testing. One week launch and stabilisation. One to two weeks training and handover.
Three to four weeks discovery, including the front-end decision and Slice-to-block workshops. Three to four weeks environment, theme and custom block development. Four to six weeks content migration, run at least three times before the real one. Three to four weeks QA, redirect testing and integration testing. One to two weeks launch. Two to three weeks training and post-launch support.
Six to eight weeks discovery across every repository, locale and Slice. Six to eight weeks build. Eight to twelve weeks content migration, usually phased by repository or brand. Six to eight weeks QA across every integration and locale. Two to three weeks phased launch. Four or more weeks training across multiple teams.
PART 3: Choosing the Right Migration Partner
Who runs this matters more than which platform you land on. The section below applies to any enterprise migration, with the Prismic-specific tells called out.
3.1 Red Flags in Vendor Evaluation
Three of the five below apply to any enterprise migration. Two are specific to what a vendor should be asking about a Prismic source.
A vendor who quotes a Prismic migration without asking how many Slices you have, which page types use them and how many are actually in active use is quoting a template. Slice-to-block translation is the largest line in most estimates, and the count is the number that moves it.
If a vendor talks about “exporting from Prismic” as though it were a button, they are working from documentation that is more than two years out of date. The button existed until April 2024 and was retired. Extraction is now a build against the Content API, and a partner who has not priced that build has not priced your project.
You want to hear about scripted, repeatable, re-runnable migration with a verification step, and an honest answer about what will be handled manually. “We have proprietary tools” is not an answer. Ask to see a migration report from a previous project.
Find out who does the work, where they sit, and whether the people in the pitch are the people on the project. Ask for named roles and allocation percentages. A team of three at 30% allocation is not a team of three.
If redirect strategy, crawl comparison and post-launch rank monitoring do not come up unprompted, they are not in the plan. On a headless source this is worse than usual, because the URL structure is not in the content extract and has to be derived from the application.
3.2 Questions to Ask Every Vendor
Ask all of these. The pattern across the answers matters more than any single response.
- How many migrations off a headless CMS have you completed, and how many off Prismic specifically?
- Have you built a Content API extractor before, and can we see how it handled failures?
- Which of those projects went over schedule, and what caused it?
- Can we speak to a client whose project did not go smoothly?
- Walk us through your process from kickoff to ninety days post-launch.
- How do you translate a Slice library into a block library without simply copying it?
- How do you handle content that does not map cleanly to the new model?
- How many times will you run the migration before the real one?
- Who exactly works on this, and what percentage of their time do we get?
- Who is our day-to-day contact, and who handles escalation?
- Do you have front-end capability in-house, or is that subcontracted?
- What does support look like in the first ninety days after launch?
- What is your rollback plan?
- What have you got wrong on a previous migration, and what changed as a result?
- How do you handle scope changes mid-project?
- What do you need from us, and what happens if we are late delivering it?
3.3 The Reference Check That Actually Matters
Vendors supply references who will say good things. Ask these five questions and listen for hesitation rather than for praise.
- What did the final invoice look like against the original quote, and what caused the gap?
- What did you have to do internally that you had not planned for?
- How long after launch did your team stop finding problems?
- If you were doing it again with the same vendor, what would you change about how you worked with them?
- Who on their team made the difference, and are they still there?
The fourth question produces the most honest answers, because it invites criticism without asking anyone to criticise.
3.4 The WordPress VIP Partner Advantage
WordPress VIP is Automattic’s enterprise platform, and its partner tiers are not self-certifications. Partners are selected by Automattic and assessed on delivered work.
The tier matters in three situations. At high scale, VIP partners have platform access and escalation paths that independent agencies do not. Under compliance obligations, VIP’s infrastructure carries the certifications and audit trails that security reviews ask for. And on unusual architectures, which describes most headless migrations, VIP partners have seen the edge cases because Automattic routes the difficult projects to them.
Multidots is a WordPress VIP Premier Partner, the highest tier, with 1000+ platform migrations across 17+ years of WordPress work. We are the 5th largest WordPress contributor globally, SOC 2 Type II compliant, and an Inc. 5000 company.
If you are not operating at that scale, you may not need a VIP partner, and a good vendor will tell you so.
3.5 Build vs. Buy vs. Partner Decision Matrix
Three routes exist, and the right one depends more on your internal capacity than on your budget. The comparison below assumes a moderate-complexity migration.
| Factor | Build in-house | Buy a template solution | Partner with a specialist |
|---|---|---|---|
| Upfront cost | Lowest on paper | Low | Highest |
| True cost | Highest, once internal time is counted | Moderate, once customisation is counted | Predictable |
| Timeline | Longest, competes with other work | Fastest to a basic site | 8-40 weeks depending on tier |
| Risk of failure | Highest | Moderate | Lowest |
| Knowledge retained internally | Highest | Lowest | Depends on the handover clause |
| Fit to your actual workflow | Best, if you finish | Worst | Good |
| Suits you when | You have WordPress engineers idle and no deadline | Your site is simple | Slice count, locales, or SEO stakes are material |
A hybrid is under-used and works particularly well here, because teams leaving Prismic usually have real front-end capability already. A specialist runs the migration and the architecture, your team builds blocks and owns the platform afterwards. Our staff augmentation model exists for exactly this.
3.6 What Great Partners Do Differently
The differences show up early, usually in the first two conversations, and they are behavioural rather than technical.
The most valuable thing a partner does early is disagree with you. On a Prismic migration the useful disagreement is usually about the Slice library: you almost certainly should not rebuild all of it, and a partner who agrees to copy it one-for-one is selling you work rather than judgement.
An honest partner gives you a range, tells you what moves it, and tells you which parts of the estimate they are least confident about. Certainty this early is a sales technique.
Ask what documentation you get. It should include content model decisions and the reasoning behind them, the redirect map, the integration inventory, deployment runbooks, and editorial guides. If documentation is a final-phase line item, it will be written by someone who has already moved on.
The best partners build so you can maintain it without them, and they say so up front. That means standard patterns over clever ones, real handover, and no dependency on proprietary tooling you cannot access after the contract ends. A partner who makes themselves difficult to leave has told you something about their confidence in the work.
3.7 Red Flags vs. Green Lights: Quick Reference
Use this as a scoring sheet during vendor conversations rather than reading it once.
| Area | Red flag | Green light |
|---|---|---|
| Scoping | Quotes before asking about Slices | Asks for Slice counts and usage per page type |
| Extraction | Talks about “exporting from Prismic” | Prices the Content API extractor as a build |
| Front end | Not raised | Raised in the first call, with both options priced |
| Timeline | Single confident date | Range, with the variables named |
| Content | “We have proprietary tools” | Describes a scripted, re-runnable process with verification |
| SEO | Comes up only when you raise it | Raised unprompted, with routing logic in scope |
| Risk | No rollback discussion | Rollback plan and a content freeze window |
| References | Only happy clients offered | Offers a client whose project was difficult |
3.8 Making the Final Decision
Score each vendor from 1 to 5 against the criteria below and weight the results. The exercise is useful mainly because it forces you to separate how much you liked the pitch from how the proposal actually reads.
Technical Capability (25% weight):
Demonstrated headless migration experience, WordPress depth at enterprise scale, and front-end capability in-house.
Methodology and Process (20% weight):
A described process rather than a described outcome, with QA, verification and rollback in it.
Team and Communication (20% weight):
Named people, sensible allocation, a single point of contact, and a clear escalation path.
References and Track Record (20% weight):
Comparable projects in scale and sector, and references who answer hard questions without hedging. Ask to see case studies with numbers in them.
Value and Transparency (15% weight):
Line-item pricing, explicit exclusions, and an honest statement of what is not included. The cheapest proposal is rarely the lowest total cost, and the most expensive is not automatically the safest.
PART 4: Why You Should Migrate from Prismic to WordPress
This is the part to send to whoever signs off the budget. It covers the strategic argument, the benefits by team, how the cost model differs, the constraints Prismic documents itself, and the objections you will hear internally.
4.1 The Business Case for Migration
The case against Prismic is not that it is expensive, and any business case built on licence cost will fall apart in the first finance review. Prismic is cheap. Platinum is $675 per month per repository with unlimited users and unlimited documents, which is a fraction of what an enterprise DXP costs.
The case is that the licence is not where your money goes. It goes into the front end: the application your team builds, maintains, secures, upgrades and staffs so that content has somewhere to render. That cost does not appear on any invoice, which is exactly why it escapes scrutiny. Add the salary cost of the engineers keeping a Next.js application current and the picture changes.
The second half of the case is velocity. Slices are a good model and they are also a coupling: a new kind of page section requires developer time by design. For an organisation shipping campaigns weekly, that coupling is the constraint on how fast marketing can move.
WordPress collapses both. Editorial and presentation live in one place, marketing ships without a deploy, and the front end stops being a separate product you have to staff. If you still need API delivery, headless WordPress serves content over the REST API in core and over GraphQL through WPGraphQL, so this is not a one-way door back to a monolith.
4.2 Benefits of Migrating from Prismic to WordPress
The gains land differently depending on which team you ask, which is worth knowing before you build a business case for an executive audience.
| Technical team | Editorial team | Marketing team | |
|---|---|---|---|
| Immediate gain | No separate front-end application to staff | New page sections without a developer | Ship campaigns without a deploy |
| Tooling | Full plugin ecosystem, standard PHP and JS stack | Block editor with patterns and revision history | Native SEO tooling, analytics of your choice |
| Control | Own the hosting, the code, and the release pipeline | Roles and capabilities on every plan | Direct control of URLs, metadata and schema |
| Talent | Hire from the largest CMS developer pool in the world | Onboard new editors in hours | Deep agency and freelancer market |
| Long-term | One codebase rather than two | Backups and governance without a tier upgrade | Locales are a plugin decision, not a plan decision |
For Technical Teams
You stop maintaining two things. Today you have a CMS you rent and an application you own, and the application needs framework upgrades, dependency management, build tooling and its own deployment pipeline. Consolidating removes an entire product from your maintenance surface. If you want to keep a decoupled front end you still can, but it becomes a choice rather than a requirement.
For Editorial Teams
The conceptual model barely changes, because stacking blocks is stacking Slices with a different name. What changes is who can create a new one. Patterns let your team assemble approved arrangements without engineering, and revision history and preview come as standard rather than as things wired into the application.
For Marketing Teams
You control URL structure, metadata, schema markup and sitemaps directly rather than through the front-end routing layer. Landing pages ship without engineering. Analytics is whatever you choose rather than whatever is wired into the application, and AI implementation work sits on your own stack rather than waiting for a vendor roadmap.
4.3 Cost Comparison: Prismic vs WordPress
Prismic publishes its pricing, which makes this comparison more honest than most in this series. The figures below are Prismic’s own, per repository, paid annually.
| Prismic | Enterprise WordPress | |
|---|---|---|
| Licence | $0 to $675/month per repository, Enterprise on quote | None, WordPress is open source |
| Billing unit | Per repository, so multi-brand multiplies | Per install, subsites included |
| Documents | Unlimited on every plan | Unlimited |
| Users | 1 to unlimited depending on tier | Unlimited |
| Locales | Capped by tier, 2 to 8 | Unlimited, plugin-dependent |
| Roles | Medium plan and above; custom roles Enterprise-only | Built in, plus custom capabilities |
| Backups | Enterprise-only | Standard on managed hosting |
| Front end | You build, host, staff and maintain it | Included in the theme, or kept if you want it |
| Hosting | Included | Your main recurring cost |
Read that table carefully before using it, because the top line favours Prismic and it would be dishonest to pretend otherwise. A $675 monthly licence is not the problem. The rows that matter are the last two and the tier gating in the middle: an unowned front-end application is a salaried cost that never appears on an invoice, and features most organisations consider baseline, backups included, sit behind an Enterprise conversation.
4.4 Why Prismic Might Be Holding You Back
Four constraints below are documented by Prismic, not inferred by us.
Prismic shipped an import/export feature and deprecated it in April 2024, replacing it with the Migration API, which creates and updates pages in a repository and offers nothing in the other direction. Prismic’s position is that you can still export by querying the Content API and saving the JSON, which is true and is also a description of a build rather than a feature. That read API returns 100 documents per request and every field, asset reference and Slice structure has to be resolved by code you write. This is worth knowing on day one of any platform decision, not on the day you decide to leave.
On Free through Platinum, backups are not included. Your disaster recovery position on a $675 per month plan is whatever your team built themselves, which in most organisations means nothing, because nobody was told it was their job.
Plans allow 2, 3, 4, 5 and 8 locales as you move up the tiers. Entering a new market can therefore mean changing plan rather than changing a setting. That is a reasonable commercial model and it is also a constraint that belongs in your growth planning rather than in a vendor’s.
Repositories are self-contained, which is clean architecture and expensive at scale. A group running four brands on Platinum is paying four times $675 per month, and each repository carries its own locale ceiling, its own user list and its own content model to maintain.
4.5 Common Concerns Addressed
These are the eight objections that come up most often inside organisations weighing this move, phrased the way people actually raise them.
It is the same idea with a wider door. Gutenberg blocks are composable page sections that editors stack, exactly as Slices are. The difference is that your team can build and combine them without a deploy, and block patterns let editors assemble approved arrangements themselves. Most teams making this move describe it as the model they already liked, with the bottleneck removed.
Not unless you want to. Keeping it and repointing it at WordPress is a supported path and often the fastest route to launch. The question worth asking is whether the application is earning its maintenance cost, because a lot of teams discover during discovery that it is not.
Only if you assume WordPress is still only a monolith, which stopped being true some years ago. The REST API is in core and WPGraphQL adds a GraphQL schema, so WordPress can serve the same decoupled architecture you have now. The difference is that a coupled front end becomes an option rather than something you must build before anyone can see a page.
WordPress runs a large share of the highest-traffic publishing operations on the web, and our own client list includes Rolling Stone, SiriusXM, and Storyful (NewsCorp). Scale is a function of the infrastructure you buy rather than the plan tier you are on.
Enterprise WordPress on managed hosting carries the certifications enterprise security reviews ask for. Multidots is SOC 2 Type II compliant, and WordPress VIP maintains enterprise infrastructure certifications. The incidents WordPress is known for trace almost entirely to outdated plugins and weak credentials on unmanaged installs, both of which are process problems that managed services solve.
Each Slice becomes a Gutenberg block, and the field model usually translates closely. Slice Machine itself has no equivalent because it solves a problem WordPress does not have: it exists to keep a separate front-end repository in sync with a remote content model. When both live in the same place, that synchronisation step disappears.
That is a fair concern and worth answering properly rather than waving away. If you keep a decoupled front end, WPGraphQL can generate types for your schema and the workflow stays close to what your team has now. If you move to a traditional theme, the types stop being necessary because there is no API contract between two codebases to keep aligned.
PART 5: How to Migrate from Prismic to WordPress
Six steps, running from strategy through to the maintenance model you will live with afterwards. Steps 1 and 2 are where most of the risk is removed, and they are the two most often compressed when a deadline tightens.
Step 1: High-Level Migration Strategy
Everything in this step happens before a single document moves. Rushing it is the most reliable way to make the later steps expensive, which is why we run it as a formal discovery process with its own deliverables rather than as a kickoff call.
1.1 When should we migrate?
The best window is after a renewal rather than before one, which is the opposite of what most teams do. Prismic annual terms are inexpensive enough that buying another year to get the timeline right is usually the correct trade, and renewal-driven deadlines compress discovery and QA.
Avoid launching into your peak trading or publishing period, and keep the Prismic subscription running through cutover so you have a rollback path.
1.2 Which CMS should we migrate to?
WordPress is the right answer for most organisations leaving Prismic, but it is worth being explicit about when it is not. If your requirement really is structured content feeding several applications and you have a front-end team who will own that layer long term, another headless platform such as Sanity may fit better. If your requirement is a public website with an editorial team behind it, WordPress wins on editorial autonomy, talent availability and total cost. Our Prismic vs WordPress comparison covers that trade-off feature by feature.
1.3 Design strategy: refresh or replicate?
Replicating the current design on a WordPress theme makes QA straightforward, since every page has an obvious correct answer. Redesigning during migration doubles the number of things that can be wrong at once and makes it impossible to tell whether a traffic drop came from the migration or the design.
If a redesign is needed, ship the migration first on a close replica, then bring in design six to eight weeks later.
Pro tip: if stakeholders push for a redesign, agree the split explicitly and put both dates in the plan. “We will redesign later” without a date means the replica ships and the redesign never happens.
1.4 Prismic feature audit and WordPress mapping
Before scoping anything, map the concepts. The table below is the standard mapping and the right starting point for the workshop with your editorial leads.
| Prismic concept | What it does | WordPress equivalent |
|---|---|---|
| Repository | Self-contained content space, billed individually | A site, or a subsite in Multisite |
| Page Type | Model for a page, with SEO fields and a slice zone | Custom post type plus registered fields |
| Custom Type | Generic model for a menu, category or CTA | Custom post type, taxonomy, or an options page |
| Document | A single piece of content against a type | A post of that post type |
| Slice | Developer-built page section modelled as fields | Gutenberg block |
| Slice Zone | Area where writers stack slices | The post content area |
| Field | Typed input inside a slice or type | Registered field, ACF or block attribute |
| Locale | Language or region variant, capped by plan | Language version via a multilingual plugin |
| Release | Group of documents published together | Scheduled publishing |
| Integration Field | Pulls external data into a document | API integration or a field populated on save |
| Slice Machine | Local tool modelling slices, generating TS types | Block registration in the theme or a blocks plugin |
The last row is the one to discuss rather than map. Slice Machine exists to keep a separate front-end repository aligned with a remote content model, and that problem does not exist when both live together.
1.5 Third-party integration planning
Every integration needs an owner, a renewal date, and a decision. The categories below cover most Prismic implementations.
| Category | Prismic side today | WordPress replacement |
|---|---|---|
| Front-end delivery | Content API into a Next.js or Nuxt app | Traditional theme, or keep the app on headless WordPress |
| Commerce | Shopify product sync, or another engine pulled in through a custom Integration Field API | WooCommerce, or keep the engine headless |
| Search | Algolia | ElasticPress or Algolia |
| Digital asset management | Prismic media library, or an external DAM | Media library, or keep the external DAM connected |
| Forms | Third-party embedded forms | Gravity Forms or Fluent Forms |
| Preview | Prismic previews wired into the application | Native preview, no wiring required |
| Analytics | Wired into the custom front end | GA4, unchanged |
Pro tip: catalogue your Integration Fields specifically. Each one is a live dependency on an external source, and because they render inside documents rather than as visible integrations, they are the connections teams most often forget they have.
1.6 Enterprise hosting strategy
Hosting is where WordPress performance is won or lost, and the decision constrains everything downstream. Compare on the dimensions below rather than on headline price.
| Host | Best suited to | Notable |
|---|---|---|
| WordPress VIP | Highest-traffic publishing, regulated industries | Automattic’s enterprise platform, strongest compliance posture |
| WP Engine | Mid-to-large enterprise | Broad feature set, strong developer tooling |
| Pantheon | Teams wanting strict environment workflows | Git-based deployment pipeline |
| Kinsta | Performance-focused mid-market | Google Cloud infrastructure |
| Pagely | Enterprise with custom infrastructure needs | AWS-based, high customisation |
For teams leaving Prismic the deciding factors are usually the deployment workflow your engineers already expect and whether backups and staging come as standard, since both were plan-gated on the platform you are leaving.
1.7 Migration team: internal vs. external expertise
You need four things: WordPress engineering, Prismic API access and knowledge, editorial decision-making, and project management. The middle two must come from inside your organisation.
Budget explicit time from your front-end lead, who understands both the Slice library and the routing logic that holds your URL structure. That person is on the critical path throughout. If WordPress engineering capacity is the gap, embedding vetted WordPress engineers with your existing team is usually faster than hiring for a fixed-length project.
Step 2: Pre-Migration Preparation
Preparation is where you build the reference points you will be measured against later: what you had, where it lived, and how it performed.
2.1 Full backup strategy
Customer-accessible backup and restore is an Enterprise feature, so on any lower plan this step is a build rather than a click. Start by writing a script that walks the Content API across every Page Type, locale and repository, and store the output outside Prismic. Pull assets separately through the Asset API, which lists 100 assets per page with cursor pagination and needs a write token. Note its rate limit of one request per second, since that makes the asset pass slower than the document pass on a large library.
Verify the backup by reconstructing a sample of pages from it. An unverified backup is a hope rather than a plan, and this one is code you wrote last week.
2.2 Content inventory and audit
Count everything, by Page Type, by locale and by repository. Then flag three categories: content that migrates as-is, content that migrates with changes, and content that does not migrate.
The third category is usually larger than expected and represents real savings. Because Prismic gives unlimited documents on every plan, nobody has had a commercial reason to prune, and the archive is often years deep. Pull the analytics before deciding, and get sign-off from content owners. Across our platform migration work, the archive-or-drop decision is the cheapest lever available for bringing a quote down.
Pro tip: inventory Slices by usage, not just by existence. Query how many documents actually use each one. Teams routinely find that a third of the Slice library appears on fewer than five pages, and those are candidates for consolidation rather than translation.
2.3 SEO and performance baseline
Capture where you stand before you change anything. A WordPress audit format works fine here even though the source is not WordPress, because the outputs are the same. Crawl the full site and export every URL. Pull twenty-four months of organic traffic and ranking data. Record Core Web Vitals from field data rather than lab tests. Export your backlink profile so you know which URLs carry external authority.
On a headless setup, add one step the other guides do not need: document the front-end routing logic. Your URL structure lives in the application, not in the CMS, so it will not appear in any content extract.
2.4 Prismic content structure analysis
Go deeper than the inventory. For each Page Type, document every field, its type, whether it is required, and what editors actually put in it against what it was designed for. Those two things diverge, and the divergence is where migration scripts break.
Pay particular attention to Slice variations. A Slice with four variations is four block patterns or one block with four presets, and deciding which before you build saves a rebuild later.
Step 3: WordPress Environment Setup
Four architectural decisions here shape the next three years. Make them before development starts, because reversing any of them later is a project in itself.
3.1 Architecture decision: traditional vs. headless WordPress
This decision carries more weight on a Prismic migration than on most, because you are already headless and the default answer is not obvious.
Traditional WordPress removes the second codebase entirely, which is usually the point of the exercise. Headless WordPress keeps your existing front end and your team’s current skills, at the cost of keeping the two-repository maintenance burden you have today.
Choose traditional if editorial velocity or engineering overhead is the driver. Choose headless if the front end is good, actively owned, and serving more than one channel.
Pro tip: if you cannot decide, build the WordPress side traditionally first. You can add API delivery later without rework. Going the other way means rebuilding the presentation layer.
3.2 Multisite vs. single site strategy
Organisations running several Prismic repositories often map cleanly onto Multisite, and this is where the per-repository billing model stops costing you. One network, one codebase, one design system, one place to manage updates and users.
Single site is better when properties have materially different requirements, separate teams, or independent release schedules. The coupling in Multisite is real: a plugin update affects every site at once. Decide before development starts, because converting afterwards is a project in itself.
3.3 User roles and workflow configuration
Prismic gates roles behind the Medium plan and custom roles behind Enterprise, so many teams arrive with governance that is informal rather than configured. Treat this as a design exercise rather than a mapping one.
| Function | WordPress role | Typical capability |
|---|---|---|
| Platform owner, plugin and user management | Administrator | Everything, kept to two or three people |
| Editorial lead, publishes and manages others’ content | Editor | Publish and edit all content |
| Staff writer, publishes own work | Author | Publish and edit own content |
| Contributor or agency, drafts only | Contributor | Write, cannot publish |
| Legal or compliance reviewer | Custom role | Read and comment, no edit |
Most enterprise teams need one or two custom roles beyond the defaults. Add editorial approval workflows with a plugin such as PublishPress rather than building from scratch.
3.4 Custom Gutenberg blocks and page templates
Your Slice inventory from Step 2.2 is the specification for this, and the usage data is what stops you copying it wholesale. The goal is a smaller library of well-constrained blocks that make the right layout easy and the wrong layout impossible.
Consolidate aggressively. Three Slices that differ only in background colour are one block with a setting. This is custom development work with a design system attached, not a translation exercise, and it should be staffed accordingly.
Pro tip: build block patterns as well as blocks. Patterns are the thing your editors have been asking developers for, since they let the team assemble approved arrangements without anyone writing code.
3.5 Essential plugin stack for enterprise
Keep the plugin count low and the quality high. Every plugin is a dependency, a security surface, and an update obligation.
A typical enterprise WordPress stack covers SEO, security, caching, forms, editorial workflow, media optimisation, analytics, and custom fields. Choose plugins with a commercial entity behind them, a public security disclosure process, and a release history suggesting they will still be maintained in three years. Audit annually and remove what is unused.
Step 4: Migration Execution and Launch
The execution phase is mechanical if the first three steps were done properly. Run everything more than once, and treat the first two runs as tests rather than attempts.
4.1 Content migration process
Run this in four phases, and run the whole thing at least three times before the real one.
Phase 1, Extract from Prismic. Walk the Content API with pagination at 100 documents per request, across every Page Type, locale and repository, keeping queries inside the 2048-character URL limit. Capture the raw JSON before transforming anything, so you can rerun later phases without hitting the API again. Build the asset manifest from the Asset API rather than from the document extract, so you catch assets that are uploaded but unreferenced, and reconcile the two lists.
Phase 2, Transformation. Map documents to your WordPress post types and fields, and convert each Slice Zone into block markup using the Slice-to-block decisions from Step 3.4. Resolve content relationships into post relationships, resolve Integration Fields into whatever replaces them, and rewrite internal links. This is where the field-level documentation from Step 2.4 earns its cost.
Phase 3, Import into WordPress. Load assets first, then documents, so references resolve. Run in batches with logging on every record, and make every run idempotent so a failed batch can be rerun without creating duplicates.
Phase 4, Verification. Compare counts by Page Type and locale against the source. Spot-check rendered output against the live site, with particular attention to Slice-heavy pages. Validate that every internal link resolves and every asset reference points somewhere real. Then rebuild scheduled Releases and user accounts, neither of which came across.
4.2 Media and digital asset migration
Prismic serves images through imgix, so your extract contains URLs carrying transformation parameters rather than plain file references. Every image URL arrives with ?auto=compress,format appended, and any field configured with responsive views returns additional keyed URLs at fixed dimensions. Download from the base URL with the parameters stripped, not from whichever view the front end happened to render, or you will migrate resized copies instead of originals.
Preserve filenames where possible, carry alt text across, and configure image sizes and an optimisation strategy on the WordPress side deliberately. This is a capability Prismic handled for you, and it needs configuring rather than assuming.
4.3 URL mapping and SEO preservation
Build a one-to-one redirect map from the crawl captured in Step 2.3 and the routing logic you documented alongside it. No chains, no wildcards standing in for pages that deserve a specific destination. Every URL that has received organic traffic or an external link in the last twenty-four months needs an explicit entry.
Migrate metadata, canonical tags and structured data alongside the content rather than treating them as a post-launch task. Page Types carry pre-configured SEO fields in Prismic, so this data exists and should be mapped rather than re-entered. Generate and submit a new sitemap on day one, and keep Search Console open for the first ninety days. On enterprise migrations we run this as a dedicated growth workstream rather than as a developer task.
Pro tip: test the redirect map against your live crawl before launch, not after. A scripted check that requests every old URL and asserts a single 301 to a 200 takes an hour to write and catches the errors that would otherwise cost you a quarter of organic traffic.
4.4 Pre-launch testing and quality assurance
Test in four passes. Functional, covering every template, form and integration. Content, comparing a statistically meaningful sample against the source, with particular attention to how translated Slices render. Performance, against the baseline from Step 2.3. And access, covering every role.
Get editorial sign-off from the people who will actually use the system, doing real tasks, before launch rather than after.
4.5 Go-live strategy and monitoring
Agree a content freeze window with the business and hold it. Run the final migration during the freeze, cut DNS, and keep the Prismic subscription alive for at least thirty days as a rollback path. It is inexpensive insurance, so do not let procurement cancel it the week of launch.
Watch error rates, 404s, Core Web Vitals and organic traffic daily for the first two weeks and weekly for the next three months. Expect a small ranking fluctuation in the first two to four weeks, expect it to recover, and investigate if it has not recovered by week eight.
Step 5: Post-Migration Optimization and Team Training
Launch is the midpoint. What happens in the eight weeks afterwards determines whether the migration is judged a success internally.
5.1 Performance optimization and monitoring
Compare like for like against the baseline: same pages, same connection profile, same time of day. Focus on Core Web Vitals and treat field data from real users as the number that matters.
Be prepared for an honest conversation here. A statically generated Next.js site fronted by a CDN can be very fast, and a traditional WordPress site needs proper caching, image handling and hosting to match it. That is an infrastructure decision rather than a platform limitation, and it should be budgeted rather than discovered, which is why we scope performance optimization into the engagement rather than after it. Use PageSpeed Insights and GTmetrix for spot checks, and automate the alerting.
5.2 Team training and workflow optimization
Training in the week before launch does not work, because people have nothing to attach it to.
Run it in three passes. A short orientation two to three weeks before launch so the interface is familiar. Hands-on sessions in launch week, in the real environment, doing real tasks. And a follow-up two to four weeks after launch, when people have accumulated actual questions.
Prismic editors adapt faster than most, because stacking blocks is what they already do. Spend the training time on the parts that are new rather than on the parts that are familiar: patterns, revisions, and the fact that they can now build arrangements nobody had to code first.
5.3 Long-term success strategy
The migration is a project. The platform is not. Name the owner before the project team disperses.
That means a named platform owner, a scheduled update and testing cadence, a quarterly review of plugins and performance, and a route for editors to request changes that does not depend on goodwill. Organisations that skip this end up two years later with an outdated install and nobody who remembers how it was built.
Step 6: Ongoing Maintenance and Monitoring
The platform needs an owner and a cadence. Both should be agreed before the project team moves on to other work.
6.1 WordPress update management
Handle updates with a process rather than with attention. Run them on staging first, on a fixed cadence, with automated smoke tests covering critical paths. Apply security releases quickly and everything else on the cadence. Keep a rollback path you have actually tested, version-control the codebase, and deploy through a pipeline rather than through the admin interface.
Teams arriving from Prismic usually find this familiar, since Slice Machine already had them treating content models as versioned code. Keep that discipline rather than letting it lapse.
6.2 Performance and security monitoring
Monitor uptime, response time, Core Web Vitals from field data, error rates and failed login attempts. Alert on thresholds rather than reviewing dashboards, because nobody reviews dashboards.
Run a firewall and malware scanning through Wordfence or Sucuri, enforce multi-factor authentication for anyone who can publish, keep administrator accounts minimal, and review access quarterly. Most WordPress security incidents trace to an outdated plugin or a weak credential rather than to a platform vulnerability.
6.3 Maintenance service options
Three models are common. An internal team works when you have WordPress engineers and enough volume to keep them busy. A retained agency works when you need expertise without headcount. A hybrid, where your team handles content and configuration and an agency handles code, security and performance, is what most enterprise teams settle on.
Multidots runs the hybrid model most often. Managed services covers updates, monitoring, security and performance for teams who want the platform run for them, and staff augmentation covers teams who want to keep the work in-house but are short an engineer.
Ready to Explore Your Options?
If you are weighing a move from Prismic to WordPress, the useful next step is a conversation with someone who has done it before rather than another vendor deck.
Book a free 30-minute migration call. No pitch. We will look at your Slice library, your document volume and your front end, tell you where the difficulty actually sits, and give you a realistic range. If migrating is the wrong call for you right now, we will say so.
Get a written migration assessment. Send us your site and a rough content inventory, and we will come back with a written view of complexity, timeline and the risks specific to your setup, usually within three business days.
Schedule a conversation with our migration experts, or read more about how we handle any CMS to WordPress migrations.
Frequently Asked Questions
Most engagements run 14 to 24 weeks for a moderate-complexity migration. Simple sites with under 5,000 documents in a single repository can complete in 8 to 14 weeks. Multi-brand, multi-locale setups spread across several repositories run 24 to 40 weeks or longer.
Each Slice becomes a Gutenberg block, and the field model usually translates closely. Do not translate one for one, though. Inventory Slices by how many documents actually use them, and expect to find that roughly a third appear on fewer than five pages. Those should be consolidated rather than rebuilt, which is how the block library ends up smaller and easier to maintain than the Slice library it replaces.
Yes, and for teams with an actively maintained front end this is often the fastest route to launch. The WordPress REST API is in core and WPGraphQL adds a GraphQL schema, so the application reads from a new source with the data-fetching layer rewritten. The trade-off is that you keep the two-codebase maintenance burden, which for many teams is the thing the migration was meant to remove.
Only if you stop needing them. Keeping a decoupled front end means WPGraphQL can generate types from your schema and the workflow stays close to what you have now. Moving to a traditional theme removes the API contract between two codebases, so there is nothing left for generated types to keep in sync.
Expect a fluctuation in the first two to four weeks and a return to baseline by week six to eight, provided redirect mapping is done properly. Headless sources make this harder because URL structure lives in the front-end routing layer rather than in the CMS, so the redirect map has to be derived from the application as well as the content extract. Budget $40,000 to $75,000 for this workstream.
It can be, with proper caching, image handling and hosting, but it takes deliberate work rather than arriving by default. A CDN-fronted static build has a genuine head start. Treat performance as a budgeted workstream with a target set against your Step 2.3 baseline, and settle the infrastructure question during discovery rather than discovering it in week ten.
Yes. WordPress runs a large share of the highest-traffic publishing operations on the web, and our own enterprise client list includes Rolling Stone, SiriusXM and Storyful. Capacity is bounded by the infrastructure you buy rather than by a plan tier.
Enterprise WordPress on managed hosting carries the certifications enterprise security reviews ask for. Multidots is SOC 2 Type II compliant and a WordPress VIP Premier Partner. Worth noting on the other side: Prismic gates backups to its Enterprise tier, so on lower plans your recovery position may be weaker than you assume.
Phase it if you run multiple repositories, more than 50,000 documents, or several brands, since repositories give you natural phase boundaries. Migrate in one pass if you have a single repository under about 20,000 documents, because phasing adds coordination overhead and a period where content lives in two systems while you pay for both.
Your front-end engineers transfer well, particularly if you keep a decoupled architecture, since the API patterns are familiar. For the WordPress side most teams either hire WordPress developers or retain an agency for the first year and bring the work in-house afterwards. Editors typically need days rather than weeks, because the block model is already familiar to them.
