Choose a WordPress migration approach from the supported content model and the publishing result the target must deliver. Within Next-Cart Migration Services, scope and execution responsibility are separate decisions.
Make three decisions before choosing the service:
- Which records and relationships the exact Source-to-WordPress path supports.
- Which eligible Add-ons or tailored handling the required result needs.
- Who performs the agreed Migration Actions.
Use the scope and execution framework rather than treating simple, complex, small or large as service tiers.
The customer supplies business meaning, retains manual access and verifies the final result even with expert-led execution. Target implementation remains an assigned responsibility.
Separate Scope, Execution and Proof
The approach must identify supported output, implementation ownership and evidence. Separate record transfer, eligible adjustments, tailored handling and target setup; a limited standard Demo cannot prove every site behavior.
Standard-looking content can depend on different implementations:
- A page can use block patterns, builder data, custom fields, reusable components, forms, embeds or shortcodes.
- A custom post type needs the registration and templates required for its intended editing and display.
These dependencies matter on publication, documentation and landing-page sites as well as plugin-driven applications. Identify whether a plugin, theme, builder, custom code or external system owns the result.
Shared site storage does not establish shared coverage. A WordPress content path does not establish commerce coverage; assess the WooCommerce operating model separately.
Define the required result separately:
- Visible content.
- Editable structured records.
- An operational plugin workflow.
Posts, pages, users and plugin records need their own qualified ownership and support. Saving a field does not prove all three outcomes.
| 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.
Choose Standard Migration for Customer-Led Execution
Standard Migration fits supported scope with customer-led execution. The target must be prepared for the agreed content, and the customer must be able to coordinate preparation and verify the result.
Use the readiness signals below to judge the work, then confirm customer capacity to:
- Prepare the inputs and perform or coordinate the required migration steps.
- Review supported Demo samples.
- Configure the target WordPress settings and verify the final result.
Custom fields or plugin records need qualification; their presence alone does not rule out Standard Migration.
| 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. |
Volume and complexity are different signals:
- A small site can depend on membership logic, custom fields, plugin tables, builder layouts or sensitive SEO paths.
- A larger site can suit Standard Migration when supported structures are predictable and the customer can validate them.
The required handling and available execution capacity decide the service.
Choose Managed Migration for Agreed Expert Execution
Managed Migration fits supported scope when an expert should perform the agreed Migration Actions.
WordPress editorial, SEO and development owners still decide content meaning, target registration, presentation, timing and final verification. Expert execution does not automatically include wider coordination, target setup or validation.
A large inventory or time-sensitive launch can make expert execution useful without expanding coverage. Establish supported scope and acceptance owners first; plugin dependencies and unsupported records remain capability questions.
| 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. |
Choose Managed Migration for agreed expert execution within supported capability. Where extraction, transformations, plugin-data handling or migration logic exceed supported behavior, qualify Custom Migration separately. Target setup and final acceptance remain assigned work.
Use Add-ons for Bounded Supported Changes
A bounded Standard Add-on can address supported needs such as:
- Selecting records through field-based conditions for each Data Type.
- Transforming supported field values through expressions.
- Routing source or transformed values to compatible target fields without changing them during mapping.
Qualify the actual fields and output; a WordPress label alone does not establish support.
When selected together, Standard Add-ons process in this order:
- Data Filter: selects records.
- Data Transformation: changes supported values.
- Advanced Data Mapping: routes supported source or transformed values.
- Advanced Database Mapping: routes eligible database values after Source/setup, Target and compatibility checks.
Mapping does not change the routed value. Tax is excluded from both mapping Add-ons. Combining supported Add-ons does not by itself require Custom Migration.
Write an Add-on request as an acceptance criterion.
Illustrative examples:
- Excluding draft pages through a supported Page-field condition is a filtering requirement.
- Remapping supported metadata is a field-destination requirement.
Neither establishes coverage for a plugin’s custom table or recreates a 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 | Route supported standard metadata, author, Category or Page source values, including values already transformed by Data Transformation, to compatible supported target fields without changing them during mapping. | 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. |
Supported filtering, transformation and mapping address bounded record requirements. Modified Add-on functions or bespoke behavior cross into Custom Migration scope; neither recreates a plugin workflow by itself.
Use Custom Migration for Tailored Requirements
Consider Custom Migration when required extraction, relationships or logic exceed supported behavior.
Plugin tables, builder data, membership records, multilingual relationships and form entries can expose that gap. A custom post type, field or external identifier alone does not: qualify supported records and compatible mapping first.
The trigger is the required output, not site size:
- A small plugin-driven site can need tailored handling for required business data.
- A large publication can remain within supported scope for posts, pages, taxonomies, users, media and URLs.
Target setup is separate from migration capability in either case.
| 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. |
Define tailored work through evidence:
- Representative records and field samples.
- Source ownership and the required target result.
- Transformation or relationship rules and acceptance criteria.
Without examples, the requirement is 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 included standard file workflow covers Products only; other Data Types need agreed scope. That is distinct from a supported platform’s File Upload connection method. A Product export alone does not establish WordPress content coverage.
Separate Entity Points From Content Complexity
Entity Points apply to eligible Products, Customers, Orders and Blog Posts after their first successful migration within the same purchased migration and fixed actual Store path.
For WordPress planning:
- 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 because they add work.
Counted volume does not establish support for any record.
Volume estimates migration and review workload; it does not prove compatibility.
- Ordinary Blog Posts can be simpler than a smaller custom-post-type set with plugin-owned metadata.
- A modest page inventory can still depend on builder layouts, redirects, forms or membership rules.
Use those dependencies to qualify handling before choosing the service.
A later Migration Action does not consume Entity Points again for records already counted within the same purchased migration and fixed path.
Newly eligible records may consume points on their first successful migration.
| 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. |
Use Entity Points for eligible-record capacity planning after scope is qualified. The table describes workload signals, not additional counted Data Types.
Use Demo Evidence Within Its Limits
Demo Migration provides limited standard samples available in the active supported path. It can expose a scope gap, not prove every required site outcome.
- Add-ons and Customization are unavailable in Demo.
- Reviews and Coupons are excluded.
- Enhanced or tailored output needs agreed paid proof.
- Storefront, extension and live-operation behavior needs target implementation evidence.
Use the sample contexts below only where the actual path makes them available.
| Demo Migration sample | Decision it should support |
|---|---|
| Standard page | Inspect supported hierarchy, body content, media and internal links available in the actual sample; prove required target output separately where unavailable. |
| 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 | Inspect available supported galleries, documents, embeds and featured-image references; confirm required rendering and any untested relationships separately. |
| 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. |
When Demo exposes missing values or relationship mismatches, classify the gap before Full Migration:
- Supported configuration.
- An eligible Add-on.
- Tailored handling.
- Target setup.
- Agreed exclusion.
Builder behavior, registration, redirects and live permissions need their own evidence; a small record sample does not approve them.
Plan Later Runs Around Actual Content Changes
A WordPress source can keep changing while the target is prepared:
- Publishing: new posts, page edits, media uploads and approved comments.
- Identity: new users or changed application records.
- Continuity: redirect and SEO metadata changes.
For another Source Platform, inventory its actual content changes. The launch window needs an agreed plan for which changes enter the next run.
After an earlier paid result, choose the appropriate Migration Action:
- Continue the Migration with Last Saved Configuration when the recorded configuration remains suitable.
- Continue the Migration with a New Configuration when the next run needs revised settings.
- Perform a New Migration when a distinct result is required.
New posts differ from edits to existing pages or SEO metadata. An action can provide a fresh data basis within the purchased path; it does not change the actual target site or automatically erase 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 later runs, identify changed records, the configuration that still applies, and the owners who will review 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.
Record the WordPress Approach Decision
Choose the least extensive approach that can produce the agreed publishing result. Supported scope may use Standard Migration or Managed Migration according to execution responsibility; eligible Add-ons adjust supported behavior. Custom Migration needs a concrete requirement beyond that behavior. A field, identifier or plugin label alone does not decide the path.
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. |
Proceed when the four statements define feasible handling, assigned implementation and the evidence needed for acceptance. If a required result remains vague or unsupported, pause for scope clarification before Full Migration.
Conclusion
WordPress migration approach selection joins three decisions: supported content scope, the person or team executing it, and proof of the intended publishing result. Content volume supports planning, but cannot replace qualification of the actual relationships and consumers.
Keep target setup and ongoing application behavior separate from migrated records. Proceed with qualified scope, clear responsibilities and an acceptance plan that tests what editors, readers and connected systems need after launch.
Common Questions
Is Standard Migration enough for a WordPress migration?
It can be, when the exact path supports the required records and relationships and the customer can prepare inputs, perform the agreed Migration Actions and verify the result. Qualify posts, pages, taxonomies, media, comments and user/author records rather than assuming every native WordPress type is included. Target setup and unsupported requirements remain separate.
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.