When evaluating WordPress as the prospective Target Platform, choose the Next-Cart approach from the site’s supported content model and expected publishing result. Separate ordinary record transfer, eligible adjustments, tailored handling and target implementation before assigning execution responsibility.
The right WordPress migration approach depends on how the target site must work after launch. WordPress may be a simple content destination, but it can also be a plugin-driven CMS, a publication platform, a membership environment, a documentation site, a landing-page system, or the content layer around WooCommerce. Record volume matters, but it is not the only decision factor. The more important question is whether the content structures, ownership boundaries, plugins, metadata, URLs, users, and presentation dependencies fit a supported migration path.
Approach selection should match three things: the type of WordPress data being moved, the level of execution support the merchant needs, and the amount of custom or unsupported behavior in scope. Standard Migration, Managed Migration, Add-ons, and Custom Migration each have a place, but the decision should be made from evidence rather than from broad labels such as simple, complex, small, or large.
For WordPress, decide scope before execution: identify the supported records, eligible enhancements or tailored requirements, then choose who performs the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
What Migration Approach Means for WordPress
A WordPress migration approach decides supported scope, execution responsibility and proof. Define which records and relationships the exact path handles, which presentation or plugin responsibilities belong to the target site, and which eligible Add-ons or tailored requirements need paid evidence. Demo supplies limited standard samples rather than proof of every site behavior.
WordPress makes this decision more nuanced because standard-looking content can be owned by plugins, themes, builders, custom code, or external systems. A page may depend on block patterns, page-builder data, custom fields, reusable components, forms, embeds, or shortcode output. A custom post type may be stored as content, but it may not display or remain editable unless the target WordPress environment has the right registration and templates.
The WordPress target selection should not stand in for WooCommerce commerce coverage. Posts, pages, users and plugin content may share a site but have different ownership and support boundaries. A custom post type also needs its target registration and presentation to remain useful. Specify whether the expected result is visible content, editable structured records or an operational plugin workflow; storing a field does not prove all three.
| Work type | WordPress example | Service-path implication |
|---|---|---|
| Supported content migration | Posts, pages, categories, tags, media, comments, and supported records. | Qualify each required record in the exact path, then choose customer-led or expert-led Migration Actions. |
| Supported Add-on control | Applying conditions to exclude obsolete content, transforming supported metadata values through expressions, or remapping supported standard source metadata fields to compatible supported target fields while keeping the values unchanged. | Data Filter, Data Transformation, Advanced Data Mapping, or eligible Advanced Database Mapping may be suitable when the behavior remains supported. |
| Custom or unsupported data | Plugin tables, custom fields requiring non-standard interpretation beyond supported mapping, builder data, external IDs, membership records, bespoke structures. | Review only where extraction, relationships or logic exceed supported behavior; a compatible supported field or identifier may fit mapping. |
| Target-side setup | Theme, plugins, menus, redirects, templates, roles, forms, integrations. | Should be configured and validated in WordPress, not assumed as migrated content. |
This separation prevents two mistakes: choosing too light an approach for a plugin-heavy site, or escalating ordinary supported content into a custom project without clear need.
When Standard Migration May Be Enough
Standard Migration may be enough when the WordPress scope is supported, structurally clear, and manageable for customer-led preparation and validation. It is strongest when the migration focuses on ordinary content records and the target WordPress environment is already prepared to receive and display them.
A Standard Migration candidate usually has clean posts and pages, conventional taxonomies, limited custom fields, manageable media, simple author relationships, few plugin-owned records, and clear URL expectations. The merchant should be able to prepare inputs, run or coordinate required steps, review Demo Migration samples, configure target-side WordPress settings, and verify the final result.
| Standard Migration readiness signal | Why it matters for WordPress |
|---|---|
| Most content is standard posts and pages. | The core content structure is easier to validate. |
| Categories and tags are clean. | Archive and classification behavior can be checked without heavy mapping. |
| Media references are stable. | Images and documents are less likely to require custom handling. |
| Custom post types are limited or not required. | Plugin/theme dependency risk is lower. |
| SEO and redirects are straightforward. | Launch continuity can be controlled with a clear URL plan. |
| The merchant can validate samples. | Customer-led execution depends on confident review. |
Standard Migration is not automatically the right choice for a small site. A small site with membership logic, custom fields, plugin tables, page-builder dependencies, or high SEO sensitivity may require a stronger approach. Conversely, a larger site can remain suitable for Standard Migration when the content structure is predictable and the merchant can validate it effectively.
When Managed Migration May Be Safer
Managed Migration may be safer when the scope is supported and an expert should perform the agreed Migration Actions. WordPress editorial, SEO and development teams still own content interpretation, target registration and presentation, timing decisions and final verification. Expert execution is useful for a busy team, but wider coordination and validation are not automatically included.
A large content inventory or time-sensitive launch can make expert execution preferable without changing migration coverage. Define the supported content scope and the customer’s acceptance owners first. Plugin dependencies or unsupported records remain capability questions, regardless of which party runs the migration.
| Managed Migration fit | WordPress scenario |
|---|---|
| Large content inventory | The customer defines the qualified content scope and review plan; an expert executes the agreed Migration Actions. |
| SEO-sensitive migration | An expert executes agreed data handling; SEO owners verify priority URLs, redirect operation and metadata. |
| Multiple stakeholders | Those teams retain review ownership; Managed Migration adds agreed expert migration execution. |
| Time-sensitive launch | The project needs included expert-led execution based on the agreed request and scope. |
| Supported but complex sample set | The customer defines representative supported samples and verifies them; expert execution does not expand Demo coverage. |
Managed Migration should be chosen for expert execution within supported capability. If the requirement needs unsupported plugin data, custom extraction, bespoke transformation or migration logic adjustment, evaluate Custom Migration separately. Target setup, wider project coordination and final acceptance remain assigned responsibilities.
How Add-ons Fit Into the WordPress Approach
Add-ons are appropriate when the requirement is supported, bounded, and specific. For WordPress, they may filter records through field-based conditions for each data type, transform field values through expressions, or remap supported standard source fields to compatible supported target fields while keeping the values unchanged.
When several Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Filtering selects records; transformation changes supported values; mapping routes the source value, or an already transformed value, without changing it during mapping. Combining supported Add-ons does not by itself require Custom Migration. Tax is excluded from both mapping Add-ons.
A strong Add-on request should be written as an acceptance criterion, not a vague request for customization. Excluding draft pages through a supported page-field condition is different from migrating a plugin’s custom table. Remapping a supported metadata field is different from recreating a page-builder layout that depends on plugin logic.
| Add-on use case | WordPress example | Boundary check |
|---|---|---|
| Data Filter | Apply field conditions to records supported in the selected path, such as eligible Blog Posts or CMS Pages. Native comments, media and terms are not automatically separate supported Data Types. | The exclusion should not remove records needed for SEO, legal, or editorial continuity. |
| Data Transformation | Apply expressions to transform supported field values during migration. | The expression and outputs must remain within supported behavior. |
| Advanced Data Mapping | Remap supported standard metadata, author, Category, or Page source fields to compatible supported target fields while keeping the values unchanged. | Mapping cannot create unsupported target behavior. |
| Advanced Database Mapping | Map a supported source database column to a compatible WordPress database column while keeping the value unchanged. | WordPress is a supported Advanced Database Mapping Target; the exact selected Source setup must also support it. The requested Data Type, table, field or column and semantic/Value Type compatibility must pass. Tax is excluded; storage does not register a content model or recreate theme/plugin behavior. |
| Tailored or Custom Add-on need | A Standard Add-on function needs project-specific modification, or bespoke Add-on functionality is required. | This work is reviewed and quoted through Custom Migration rather than treated as Standard Add-on scope. |
Add-ons and Custom Migration should not be treated as interchangeable. Data Filter applies data-type-specific conditions, Data Transformation applies expressions to field values, and Advanced Data Mapping changes supported source-field destinations. Custom Migration addresses requirements beyond the supported path.
When Custom Migration Should Be Considered
Custom Migration should be considered where the required WordPress output depends on unsupported extraction, custom relationships or bespoke logic. Plugin tables, builder-specific data, membership records, multilingual relationships or form entries may expose that boundary. A custom post type, field or external identifier alone is not proof of a custom migration requirement; qualify supported records and compatible mapping first.
The trigger is not simply that the site is large. The trigger is that the expected result cannot be achieved through supported migration behavior, Add-ons, and target-side setup alone. A small WordPress site can need Custom Migration if it depends on plugin-owned business data. A large publication site may not need Custom Migration if its posts, pages, taxonomies, users, media, and URLs remain within supported scope.
| Custom Migration trigger | Why it changes the approach |
|---|---|
| Plugin-owned custom tables | Data may not live in standard WordPress records. |
| Builder-specific layout data | Migrated content may not render or remain editable without custom handling. |
| Custom post type behavior | Separate target registration/templates from supported value placement; tailored migration applies only where extraction or relationships exceed the supported path. |
| Membership/access logic | Roles, permissions, protected content, and subscriptions may be plugin-owned. |
| External identifiers | A supported compatible ID may fit mapping; unsupported extraction, changed relationships or integration behavior needs tailored or separate implementation scope. |
| Multilingual structures | Language relationships and translated URLs may depend on plugin behavior. |
Custom Migration should be scoped with examples. The merchant should provide representative records, field samples, source ownership, target expectations, and validation criteria. Without examples, custom discussion becomes too abstract to estimate or approve responsibly.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the standard included file workflow covers Products only. Other required data types must be agreed explicitly. This differs from a supported platform’s File Upload connection method, and a Product export alone does not establish the complete WordPress scope.
Entity Points and WordPress Scope Planning
Entity Points apply only to eligible Products, Customers, Orders and Blog Posts after their first successful migration within the same purchased migration and fixed actual Store path. In a WordPress-focused project, Blog Posts may be the main counted content type. Pages, media files, users, comments, taxonomies, custom post types, and plugin records do not become additional Entity Points types merely because they add migration or review work.
Entity Points should be used for eligible-record volume planning, not as proof that WordPress content is supported or straightforward. A high number of ordinary Blog Posts may be easier than a small set of custom post types with plugin-owned metadata. A modest page count can still require careful service selection if pages depend on builder layouts, redirects, forms, or membership rules.
The duplicate-consumption rule also matters: records already counted within the purchased migration and fixed path do not consume Entity Points again simply because another migration action occurs. Newly eligible records may consume Entity Points when migrated for the first time.
| Scope signal | What it helps estimate | What it does not prove |
|---|---|---|
| Post/page volume | Content volume and review workload. | Whether metadata, layout, URLs, or plugin data are supported. |
| Media volume | File and reference review workload. | Whether all embeds, galleries, or file paths remain usable. |
| User volume | Author/account review workload. | Whether roles, passwords, memberships, or user meta behave as expected. |
| Custom post type count | Structural complexity signal. | Whether the target can display or edit those records correctly. |
| Comment volume | Moderation and history review workload. | Whether all comments should migrate. |
Entity Points should support service-path planning, not replace platform-specific scope review.
Demo Migration as the Approach Decision Point
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed WordPress approach. Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. Use the contexts below to identify standard sample checks and requirements needing separate proof. Validate enhanced or tailored output through the agreed paid scope, and assign storefront, extension and live-operation checks to target implementation.
| Demo Migration sample | Decision it should support |
|---|---|
| Standard page | Whether hierarchy, body content, media, and internal links survive. |
| Standard post | Inspect supported author, date, taxonomy, image and comment relationships available in the sample; archive presentation needs target checks. |
| Custom post type | Inspect only available supported standard records; custom extraction or relationships need agreed paid proof, while registration and presentation need target implementation. |
| Metadata-heavy record | Inspect available standard fields to identify a gap; verify agreed Add-on or Custom output separately in the paid scope. |
| Media-rich page | Whether galleries, documents, embeds, and featured images remain connected. |
| User/author sample | Inspect supported author/account relationships; roles, membership access and authentication need their own qualified evidence. |
| Priority URL | Inspect available supported URL values; prove permalink and redirect operation separately in the target environment. |
| Plugin-owned example | Use available standard evidence to classify the need; unsupported plugin records or behavior are not proven by Demo. |
If standard Demo evidence reveals missing values or a mismatch in expected relationships, classify the gap before Full Migration. Agree whether it needs supported configuration, an eligible Add-on, tailored handling, target setup or an exclusion. Builder behavior, registration, redirects and live permissions need their own evidence rather than approval from a small record sample.
Migration Actions and Launch Timing
WordPress sites often continue changing during migration planning. New posts may be published, pages may be edited, media may be uploaded, comments may be approved, users may be added, redirects may change, or SEO metadata may be updated. The selected approach should include a practical launch-window plan for handling those changes.
After a paid migration has produced an earlier result, choose Continue the Migration with Last Saved Configuration, Continue the Migration with a New Configuration, or Perform a New Migration according to whether the recorded configuration remains suitable and whether a distinct result is needed. Newly added posts differ from edits to existing pages or SEO metadata. A new action can provide a fresh data basis within the purchased path, but does not imply a different actual target site or automatic erasure of protected records.
| Launch-window situation | Planning implication |
|---|---|
| New posts or pages are published after an earlier run. | Plan how the new records will be added and validated. |
| Content mapping or filtering needs to change. | Validate the changed configuration and affected samples. |
| The target result should be rebuilt. | Plan a new migration and broader target review. |
| SEO metadata changes late. | Recheck priority URLs, metadata, redirects, and internal links. |
| User or membership records change. | Decide whether those records should be included, excluded, or handled separately. |
For WordPress, focus later migration planning on the records that changed, the configuration that still applies, and the owners who will validate the resulting content, user relationships, and URLs.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration. These actions keep the purchased Source-to-Target path and actual Store identities fixed. A different Source Platform, Target Platform, actual Source Store or actual Target Store requires a separate purchased Migration Service.
Choose the source-data window separately from the action. “Migrate only newly added entities” selects records added after the last successful run, not edits to existing records. “Continue the previous migration” applies to the appropriate previous migration state. Neither option is implied by an action name. When configuration changes, check the combined earlier and later output; a new action does not automatically erase protected target data.
Choosing the Practical WordPress Path
The practical WordPress approach is the lightest path that protects the defined publishing result. Standard Migration combines supported content with customer-led execution. Managed Migration adds expert handling of agreed Migration Actions. Eligible Add-ons address supported selection, value or destination needs. Custom Migration requires a specific unsupported requirement; it is not automatically triggered by a field, identifier or plugin label.
The final decision should be summarized with four statements:
| Decision statement | What it should clarify |
|---|---|
| What will migrate | The exact qualified posts, pages, taxonomy relationships, media, authors, comments or metadata in the selected path, with explicit exclusions for unsupported native structures. |
| What must be configured | Themes, plugins, menus, templates, redirects, roles, forms, and integrations. |
| What needs Add-ons or Custom Migration | Supported adjustments versus unsupported/custom requirements. |
| What must pass Demo Migration | Limited supported standard records and values; agreed Add-on/custom output needs paid proof, and target presentation or plugin operation needs separate evidence. |
When those statements are clear, the WordPress migration approach is usually ready to proceed. When they are vague, the next step should be scope clarification rather than moving directly to Full Migration.
Conclusion
Selecting the right WordPress migration approach requires more than counting pages, posts, users, or media files. The decision should account for site role, content structure, custom post types, taxonomies, metadata, plugins, builders, users, roles, URLs, SEO, Add-ons, Custom Migration, Entity Points, Demo Migration samples, and launch-window timing.
The strongest approach is the one that keeps supported content moving efficiently while separating target-side setup, plugin dependencies, unsupported data, custom requirements, and validation proof. WordPress migration should proceed when the merchant can state what will migrate, what must be configured, what needs service support, and what must be proven before launch.
Common Questions
Is Standard Migration enough for a WordPress migration?
Standard Migration may be enough when the site mainly contains supported posts, pages, taxonomies, media, comments, and ordinary user/author records, and the merchant can prepare inputs and validate the result responsibly.
When is Managed Migration safer for WordPress?
Choose Managed Migration when supported WordPress scope needs expert execution of the agreed Migration Actions. Large inventories or tight timing may make that preferable, but project coordination, editorial review, SEO validation and target setup are not automatically included. The customer retains manual access and verifies the final result.
Do Add-ons replace Custom Migration for WordPress?
No. Eligible Add-ons cover supported filtering, expressions and compatible value destinations. Custom Migration covers agreed requirements beyond supported capability, such as unsupported extraction or bespoke relationships. A custom field or external ID does not automatically need Custom Migration when its supported value and destination are compatible. Neither approach by itself recreates plugin behavior.
What should Demo Migration prove for WordPress?
Use the available limited standard sample to inspect supported content values and relationships. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. A custom post type is not automatically a Demo-supported record. Agree paid proof for enhanced or tailored output and separate target checks for registration, layouts, redirects and plugin operation.
What evidence should be prepared for Custom Migration review in a WordPress migration?
Prepare WordPress examples from plugin-owned tables, builder-specific layout data, and custom post types whose fields or relationships affect publishing. For each example, define whether the result must remain editable, visible, or connected, then establish the evidence needed to accept the Custom Migration work.
Does the WordPress migration path include WooCommerce commerce?
Do not infer that from shared WordPress storage. Qualify the exact Source and Target selections and required Data Types. A content-focused WordPress path does not establish Product, Customer or Order coverage for WooCommerce. Decide the intended commerce destination separately from the surrounding site content and presentation.
Does a custom post type automatically require Custom Migration?
No. First identify which records and fields the exact path supports and whether compatible mapping suffices. The target still needs the content type registered and presented correctly. Custom Migration applies when required extraction, relationship handling or logic exceeds supported behavior; target registration or a plugin label alone does not establish that need.
Can a Product-only file workflow cover WordPress posts and pages?
No. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration, whose included standard file workflow covers Products only. Blog Posts, CMS Pages and any other required Data Types must be agreed separately. A platform’s supported File Upload connection is a distinct setup with its own qualified coverage.