WordPress to Contentstack Migration: What Changes at Enterprise Scale
Moving the content is only one part of moving the website. Contentstack’s legacy WordPress XML converter handles authors, categories, assets, and published posts; its Migration Framework provides a guided mapping and test-migration workflow. Neither should be treated as a complete website migration. On a large WordPress estate, the work also includes translating ACF fields, blocks, plugin functionality, integrations, and URL behavior into a maintainable Contentstack implementation.
eight25 is a Contentstack Preferred Partner with experience delivering large, multilingual migrations. Its published NetApp migration story describes approximately 14,000 pages across 10 languages moving from Tridion to Contentstack. Although the source platform was different, the project illustrates relevant enterprise challenges: content inventory, localization, integrations, and phased delivery. For a WordPress migration, discovery should establish the plugin dependencies and target content model before migration scripts are finalized.
What the WordPress to Contentstack migration tooling moves, and what it leaves behind
At enterprise scale, a WordPress to Contentstack migration combines content transfer with content modeling, frontend implementation, and integration decisions. The legacy XML converter does not rewrite internal links and limits post migration to published posts. The Migration Framework adds content-type, field, and language mapping, plus a test migration. Custom structures and dynamic functionality still need assessment, transformation, and validation against the target Contentstack model.
| WordPress object | Covered by the converter | What scale adds |
|---|---|---|
| Published posts | Documented support | Validate imported fields and content; handle other statuses separately and recreate access controls where required |
| Authors and categories | Documented support | Validate author details, category relationships, and the target taxonomy |
| Media assets | Documented asset extraction | Validate downloads, metadata, references, and any public URL changes |
| Internal links | No automatic rewriting | Preserve valid URLs or rewrite links using the approved URL map |
Custom structures can materially affect the migration budget. In WordPress, content and presentation rules may be distributed across post types, custom fields, block markup, plugin settings, and theme code. Discovery needs to identify those dependencies and decide how they should work in Contentstack. A successful export is the starting point, not evidence that the target website is ready.
Where the WordPress content model actually lives
Post types describe only part of a WordPress content model. A complete assessment also examines taxonomies, ACF field definitions, post meta, block structures, shared settings, and template behavior. Bringing those relationships into an explicit Contentstack model makes them easier to review and maintain.
Gutenberg markup, shortcodes, and page builders
Gutenberg serializes block content into post_content using HTML comment delimiters and, where applicable, JSON attributes and saved HTML. Dynamic blocks may depend on server-side rendering, so their visible output cannot always be recovered from post_content alone. The following simplified example combines several patterns a migration may need to handle:
<!-- wp:acf/hero {"name":"acf/hero","data":{"headline":"Secure every endpoint","cta_url":"/demo/"}} /-->
<!-- wp:paragraph --><p>Body copy with a <a href="/2019/04/old-post/">legacy link</a>.</p><!-- /wp:paragraph -->
<!-- wp:embed {"url":"https://www.youtube.com/watch?v=abc123"} /-->
[gravityform id="12" title="false"]One field holds four kinds of content, each with a different destination:
| Pattern in post_content | Migration approach | Contentstack representation |
|---|---|---|
| Core paragraph, heading, list blocks | Convert HTML to JSON RTE nodes, rewrite links | JSON RTE field |
| Embeds (YouTube, Vimeo) | Extract to a Video entry, reference it | Embedded entry in JSON RTE |
| acf/* custom blocks | Parse block attributes into typed fields | A Modular Blocks block |
| Shortcodes (forms, tabs, buttons) | Identify the shortcode and parameters; replace its behavior with an approved component or integration | Modular Block, reference, or structured field, depending on the function |
| Elementor or WPBakery layouts | Inspect stored layout data and rendered output; transform reusable content where practical and rebuild layouts against the approved component library | Modular Blocks and references mapped to frontend components |
Contentstack documents a maximum of 100 embedded entries per JSON RTE field and, by default, 15 selectable reference content types. Use JSON RTE for narrative content and Modular Blocks for structured page sections. This creates clearer component boundaries, but Modular Blocks also have documented limits, including a default maximum of 100 block instances per field.
Translating ACF field groups into a maintainable Contentstack model
ACF’s explicit field definitions provide a useful starting point for Contentstack modeling. Common mappings include Flexible Content to Modular Blocks, Repeaters to Group fields with Multiple enabled, and Relationship or Post Object fields to references. Options-page values may become a single settings entry, while reusable field definitions may become Global Fields. Each mapping still needs validation for nesting, localization, shared values, and frontend behavior.
WordPress estates maintained by multiple agencies can accumulate overlapping field groups and inconsistent naming. Content modeling workshops should identify which structures represent genuinely different business objects and which can be consolidated. In Contentstack, a resource library may use one shared content type when whitepapers, webinars, and case studies have sufficiently similar fields and publishing requirements:
| Field | Contentstack field type | Design reason |
|---|---|---|
| title, url | Single line, URL | Auto-mapped by the Migration Framework |
| resource_type | Select (whitepaper, webinar, case study) | Replaces three custom post types with near-identical ACF groups |
| author | Reference → Person | One bio serves every post |
| topics | Taxonomy field associated with the Topics taxonomy | Applies a governed classification to resources |
| body | JSON RTE with embedded Video and CTA entries | Supports reuse across channels with appropriate rendering |
| page_sections | Modular Blocks (hero, stat row, quote, CTA) | Lets editors assemble approved sections after the frontend components are implemented |
| seo | Global Field (meta title, description, canonical, no index) | One SEO definition reused across every type |
A model that closely follows the source can reduce initial transformation work when the first phase prioritizes launch continuity. eight25’s NetApp story illustrates the value of separating migration from a later redesign. However, preserving unnecessary fields creates future maintenance work. Contentstack supports model changes after launch, but substantial restructuring may require content transformation and frontend updates. Agree the intended future model early, then decide what belongs in each phase.
The plugin inventory is the real scope document
Patchstack’s 2026 report recorded 11,334 new WordPress ecosystem vulnerabilities in 2025, with 91% in plugins and 46% lacking a fix at public disclosure. These figures reinforce the need to assess the site’s actual dependencies and exposure. Moving to Contentstack can remove reliance on WordPress plugins, but frontend and integration security remain responsibilities. Classify each plugin as retain through an integration, replace, consolidate, or retire.
| Job | Typical WordPress plugin | Where it lives after Contentstack | Decision to make in discovery |
|---|---|---|---|
| SEO metadata | Yoast, Rank Math | SEO Global Field, rendered by the front end | Who owns canonical and noindex rules |
| Redirects | Redirection, Yoast Premium | CDN or edge redirect map | Which team edits redirects post-launch |
| Forms | Gravity Forms, Contact Form 7 | Marketo or HubSpot forms, referenced from entries | Where submissions and consent data live |
| Multilingual | WPML, Polylang | Contentstack locales with fallback, TMS connector | Fallback rules per market |
| Search | SearchWP, Relevanssi | Coveo or Algolia, indexed from published content | What to index, and in what order |
| Roles | Members, User Role Editor | Contentstack roles, workflows, publish rules | Who can publish to which locale |
eight25’s NetApp migration story describes integrations with Coveo, Marketo, Adobe Analytics and Target, Bynder, and Trados. For a WordPress migration, assess which functions depend on plugins, which already use external services, and which should be retired. Contentstack provides a foundation for structured content delivery, while the integration map establishes how the surrounding systems will operate after cutover.
Governance through roles workflows and publish rules
WordPress includes native roles and capabilities, while more complex approval requirements may depend on additional configuration or extensions. Contentstack brings configurable workflows and publish rules into the CMS. Rules can target branches, content types, locales, and environments, with required stages and designated approvers. Enabling Prevent self-approval separates the last editor from approval and publishing. The following matrix illustrates a possible regional marketing setup:
| Role | Can do | Environments | Publish rule |
|---|---|---|---|
| Regional editor | Create and edit entries in own locale | Development, staging | Cannot publish |
| Content lead | Approve workflow stage “Review” | Staging | Publishes to staging only |
| Legal reviewer | Approve stage “Legal” on regulated content types | Staging | Required for product and pricing types |
| Web operations | Publish, unpublish, manage releases | Production | Self-approval blocked |
Implement this matrix through role permissions, workflow assignments, and publish rules together; the business role names shown here are illustrative, not predefined Contentstack roles.
Contentstack workflows and publish rules are global modules that can be assigned to all branches or selected branches. Teams should verify that each campaign or development branch is covered by the intended rules. This supports consistent governance across branches without requiring every rule to be recreated.
References, redirects, and revision history in a WordPress to Contentstack migration
Once you have mapped the model and the plugins, three workstreams remain that never show up in a page count. They are where the converter’s documented gaps turn into launch risk.
Broken references. Before import, inventory links, assets, and embedded IDs across post_content, post meta, shared blocks, options, and relevant plugin storage. Resolve them against the approved entry, asset, and URL maps:
| Source entry | Broken reference type | Source value | Resolution |
|---|---|---|---|
| post 4821 | Internal link to old permalink | /2019/04/old-post/ | Rewrite to new entry URL during JSON RTE conversion |
| page 112 | Attachment page link | /?attachment_id=903 | Point to asset URL, add redirect |
| post 6610 | Reference to deleted post | ?p=5120 | Flag for editorial review; replace with a relevant equivalent or remove the link |
Redirects. WordPress produces more URL shapes than most teams list: date-based permalinks, ?p= IDs, paginated archives, tag and author pages, and media files. Media catches teams out, because asset URLs move to Contentstack’s asset domain and external sites link straight to PDFs.
| Old URL | New URL | Status | Note |
|---|---|---|---|
| /2019/04/old-post/ | /blog/old-post/ | 301 | Pattern rule, not one-by-one |
| /?p=4821 | /blog/old-post/ | 301 | Resolved from the post ID map |
| /category/news/page/3/ | /news/ | 301 if changed | Preserve pagination where an equivalent archive exists; assess other destinations individually |
| /wp-content/uploads/2021/06/datasheet.pdf | /resources/datasheet/ | 200 if preserved; 301 if moved | Prefer an equivalent file destination when the original URL served a PDF |
Revision history. WordPress stores retained revisions in the posts table, but configuration may limit or disable retention. Establish which historical records must be preserved before migration. Do not assume a standard import will recreate WordPress authorship, timestamps, approvals, and revision history as Contentstack’s native audit trail.
| Approach | Implementation implications | Historical record | Use when |
|---|---|---|---|
| Preserve required source history | Export retained revisions and relevant metadata to a validated archive or purpose-built repository | Source records retained; not automatically restored as native Contentstack history | Retention or compliance requirements demand historical evidence |
| Import current content and archive history | Import current entries and maintain a searchable historical archive | Accessible outside the live CMS | Historical access is needed without recreating the old editing experience |
| Import current content only | Import the approved current version | Contentstack history begins with the new implementation | Retention policy permits omission of source revisions |
When WordPress is still the right answer
WordPress VIP or a well-governed headless WordPress implementation can remain a sound choice when the existing editorial experience and architecture meet the business’s needs. WordPress also supports multilingual and multi-brand estates. The case for Contentstack becomes stronger when the organization wants a headless content platform with explicit reusable models and configurable governance across its digital experiences.
Contentstack is a strong candidate when reusable content, localization, approval controls, and delivery across channels are central requirements. Its Visual Editor and Live Preview can give editors a contextual editing experience when integrated with the frontend. The migration should include component design, preview configuration, and role-specific training so the new structure improves daily publishing as well as technical maintainability.
If you do move: realistic ranges
Estimate the migration across three workstreams: discovery and architecture; implementation and integrations; and content transfer, validation, and launch readiness. Their relative effort depends on component diversity, localization, source-data quality, redesign scope, and stakeholder approvals. eight25’s published NetApp story reports a January kickoff and June cutover for a phased Tridion-to-Contentstack migration. Use that as a scoped project example, not a standard timeline for WordPress migrations.
Component count is the other line item that scales with a site’s history rather than its size. On Sophos’s two Sitecore estates, the audit found roughly 249 components and consolidated them toward 100. On a WordPress estate, run the same audit across every page builder and ACF block library before anyone estimates the build, because that count drives the component library budget more than the page count does.
Illustrative 22-week plan for a limited lift-and-shift scope: 8,000 pages to retain and 2,000 URLs to archive, retire, or redirect. This is a planning example, not an estimate; it assumes agreed components, available integrations, and timely approvals.
- Weeks 1–4: Inventory content, plugins, assets, and URLs; agree disposition decisions, target models, integrations, and governance.
- Weeks 5–10: Implement models, frontend components, integrations, and preview; test migration scripts against a representative sample covering all content patterns.
- Weeks 11–18: Migrate and validate 2,000 priority pages, followed by 6,000 remaining retained pages; prepare redirects and document the remaining 2,000 URL dispositions.
- Weeks 19–22: Complete training, final content synchronization, redirect and SEO validation, cutover, and initial post-launch support.
Migration waves describe transfer and validation batches. Public release timing should be agreed separately, using tooling that supports repeatable imports and updates.
Frequently Asked Questions
How long does a WordPress to Contentstack migration take?
The timeline depends on content structure, component variation, integrations, localization, redesign scope, and approval requirements. A limited lift-and-shift can run faster than a migration combined with a redesign. eight25’s published NetApp example involved Tridion, not WordPress. A WordPress-specific estimate should follow discovery and representative migration testing.
Can Contentstack’s migration tools move ACF fields and Gutenberg blocks?
Contentstack’s Migration Framework supports guided content-type, field, and language mapping with a test migration. Custom WordPress structures need assessment and may require preprocessing or custom transformation. Review ACF definitions, Gutenberg attributes, shortcodes, options, and plugin storage, then validate the extracted content against the chosen Contentstack fields and frontend components.
Should we move to headless WordPress instead of Contentstack?
Headless WordPress can preserve an established editorial experience while separating the frontend. It still requires management of the WordPress backend and retained plugins. Contentstack is worth prioritizing when the goal is explicit reusable content models, configurable approval controls, and a managed headless CMS. Compare the operating model, editorial requirements, integration effort, and total cost rather than brand or locale count alone.
What happens to SEO when you migrate from WordPress to Contentstack?
Preserve existing URLs where possible and use permanent redirects for changed URLs with relevant replacement destinations. Validate SEO metadata, canonicals, hreflang, structured data, internal links, sitemaps, and indexability before launch. Include directly linked media files in the URL inventory. Rankings can fluctuate during a migration, so monitor crawling, indexing, and organic performance after cutover.
How do I choose a partner for a WordPress to Contentstack migration?
Choose a partner that can demonstrate how it assesses source content, transforms custom structures, validates links, and plans integrations and cutover. Agree which discovery outputs are included and when they will be delivered. eight25’s Contentstack partner status and published enterprise migration work make it a relevant partner to evaluate for complex estates.
Planning a WordPress to Contentstack Migration?
A WordPress to Contentstack migration becomes easier to scope when content structures, plugin dependencies, integrations, and URL requirements are understood early. eight25 brings published enterprise migration experience to that assessment, helping teams define a Contentstack implementation around their content and publishing needs. Start a scoping conversation to establish discovery deliverables, dependencies, and a realistic delivery plan. Start a scoping conversation with eight25
Contentstack migration services