WordPress is a CMS foundation whose migration quality depends on how content, people and the chosen implementation work together. Evaluate the prospective Target by that operating model before deciding what to transfer.
Content ownership, editorial control, SEO continuity, media, site structure and user roles can be the complete target purpose. Plugins, themes and custom functionality extend that foundation; selling requires a separately defined commerce layer.
The selected migration workflow and agreed scope determine which records and fields can move. Native content capabilities do not establish transfer coverage. Judge the result by whether users, editors, search engines, administrators and connected systems retain the meaning they need after launch.
Understand the CMS and Its Implementation Layers
WordPress is an open-source CMS and a flexible publishing and site-building environment. Its core content model supports posts, pages, media, comments, categories, tags, users, roles, themes, templates, menus, and API-accessible resources. Developers and site owners can extend that foundation through custom post types, custom taxonomies, custom fields, plugins, themes, page builders, shortcodes, custom tables, and integrations.
The WordPress software can run with a hosting provider chosen by the site owner; WordPress.com provides a managed hosting service using the same software. Hosting, maintenance and implementation responsibilities therefore depend on the actual deployment and service arrangement.
The same foundation can serve different site purposes:
- A marketing website with pages and blog posts.
- A membership portal, course library, directory or event site.
- A publisher archive, nonprofit resource center or service website.
- A commerce-connected implementation.
The required content, application layer and migration scope change with that purpose.
| WordPress layer | Migration meaning | Planning question |
|---|---|---|
| Core CMS records | Posts, CMS Pages, Blog Posts, media, categories, tags, users, comments, and menus. | Can ordinary content be represented cleanly as native WordPress records? |
| Structure layer | Custom post types, custom taxonomies, parent/child hierarchy, archive pages, templates, and permalink rules. | Does the target site need a documented content model before migration begins? |
| Metadata layer | Custom fields, SEO metadata, field groups, page-builder data, plugin settings, and record-level options. | Which metadata controls display, filtering, SEO, search, permissions, or business behavior? |
| Presentation layer | Themes, templates, blocks, synced patterns (formerly reusable blocks), widgets, shortcodes, galleries, page builders, and media output. | Which pages need visual review because content storage alone will not prove usability? |
| Plugin and custom layer | Forms, memberships, courses, bookings, events, directories, commerce plugins, custom tables, and integrations. | Which records are supported content, and which need field alignment, target setup, or separate implementation review? |
| Operational layer | Hosting, PHP, database, caching, security, redirects, search, backups, deployment, and connected systems. | Is the target environment prepared to make migrated records behave correctly after full-scale migration? |
The migration should therefore begin with architecture, not only export availability. WordPress can receive many kinds of information, but the target architecture determines whether that information becomes usable content, searchable records, structured data, visible pages, editable blocks, or hidden metadata.
Separate CMS and Commerce Ownership
Keep two ownership layers distinct:
- WordPress provides the CMS foundation and can be a complete target without commerce.
- WooCommerce adds the commerce layer: Products, cart, checkout, Orders, coupons, tax, shipping, customer-commerce and payment-related behavior.
A WooCommerce migration needs both layers. Use the WooCommerce overview when selling is part of the intended site.
| Target expectation | Correct interpretation | Migration implication |
|---|---|---|
| Content website moving into WordPress | WordPress is the Target Platform. | Focus on CMS Pages, Blog Posts, posts, users, media, menus, categories, tags, URLs, SEO fields, and layout dependencies. |
| WooCommerce store moving into WordPress | WordPress is the foundation and WooCommerce is the commerce layer. | Products, variations, attributes, orders, coupons, customers, checkout fields, payment context, taxes, and shipping require WooCommerce-specific review. |
| Membership, LMS, booking, event, or directory site | WordPress is the foundation and plugins carry business meaning. | Plugin-owned records, custom post types, custom fields, custom tables, roles, and user relationships may require deeper scoping. |
| Custom WordPress application | WordPress acts as a content/application framework. | Custom database structures, APIs, external IDs, permissions, and bespoke relationships may require separate implementation review. |
Review content, media, users, roles, themes, templates, plugins, URLs, metadata and custom structures as site architecture. Add commerce-specific review when selling is required, so those records are neither assigned to WordPress core nor hidden inside a generic CMS plan.
Preserve Content Management Meaning
The migration value lies in control over content structure, editorial workflows, SEO architecture, extensions and implementation ownership. That matters to content-heavy businesses, publishers, education resources, service businesses, organizations with many landing pages and sites connecting content with commerce.
Preserve management meaning as well as visible copy:
- Pages: navigation, reusable content and template relationships determine how the page can be maintained and used.
- Posts: authorship, publishing context, discovery and media relationships shape the article beyond its body text.
A correct text import can still leave editors or readers without usable content.
| Value area | Why it matters in WordPress | What must be preserved, rebuilt, or validated |
|---|---|---|
| Content ownership | WordPress is widely used for publishing, resource libraries, marketing sites, and content operations. | Titles, bodies, excerpts, authors, dates, statuses, featured images, categories, tags, comments, and internal links. |
| Flexible structure | Custom post types and custom taxonomies can represent resources, events, profiles, courses, portfolios, directories, or listings. | Content-type definitions, taxonomy hierarchy, relationships, archive behavior, custom fields, and templates. |
| Media context | Images, files, galleries, embeds, captions, alt text, and attachment relationships affect page meaning. | Media files, attachment links, featured images, gallery structure, alt text, captions, file references, and embedded media. |
| SEO continuity | Slugs, permalink rules, metadata, canonical behavior, internal links, redirects, and archive pages can affect traffic. | URL mapping, priority slugs, redirects, metadata, taxonomy archives, internal links, and SEO plugin fields where scoped. |
| Plugin extensibility | Plugins can define business behavior beyond WordPress core. | Plugin-owned records, settings, shortcodes, field groups, custom tables, forms, memberships, courses, events, and integrations. |
| Implementation control | Self-hosted WordPress allows control over hosting, themes, plugins, code, caching, security, and deployment. | Target environment readiness, plugin compatibility, theme behavior, hosting requirements, backups, and maintenance ownership. |
Assign each requirement an agreed treatment:
- Transfer supported, in-scope content records.
- Rebuild output owned by the target theme or builder.
- Map compatible plugin fields, or review unsupported records separately.
- Configure the workflows that belong to the live target.
This scope distinction prevents a content transfer from becoming a promise to reproduce every source behavior.
Choose the Target Content Model
The target model changes how information is organized and maintained:
- Source pages and blog content may become CMS Pages and Blog Posts.
- Product-like content may become custom post types, WooCommerce Products, other plugin records or a custom structure.
- Categories and filters may become categories, tags, custom taxonomies, search fields or plugin relationships.
Choose the interpretation before mapping.
Illustrative example: case studies, courses, events, profiles or resources may need a custom post type so editors can manage shared structure. Do not turn them into ordinary Pages solely because they appeared as web pages in the Source.
| Source-site element | WordPress interpretation | Planning impact |
|---|---|---|
| Standard pages | CMS Pages with hierarchy, templates, editor content, media, and menu relationships. | Priority pages need both record-level and visual review. |
| Blog or article content | Blog Posts with authors, dates, categories, tags, featured images, comments, excerpts, and slugs. | Publishing context should be preserved, not only title and body. |
| Product-like or listing content | Custom post types, plugin records, WooCommerce products, or custom-built platform records. | The target model must be defined before mapping begins. |
| Categories and filters | Native categories/tags, custom taxonomies, plugin filters, or search-index fields. | Filtering and archive behavior require validation beyond record existence. |
| Media assets | Media library records and attachment references. | Images and files must remain connected to content, galleries, fields, and SEO text. |
| Users and accounts | Users with roles, capabilities, authorship, membership meaning, or plugin-specific permissions. | Authors, members, subscribers, customers, vendors, instructors, and administrators may require different treatment. |
| Forms and submissions | Plugin-owned records, custom tables, email workflows, CRM records, or external data. | Historical submissions and workflow behavior may not be ordinary WordPress content. |
| SEO data | Slugs, metadata, redirects, canonicals, schema fields, breadcrumbs, and plugin records. | SEO preservation requires explicit evidence and redirect planning. |
Pages can exist while the intended site remains incomplete:
- Editors cannot manage the content types properly.
- URLs change without a redirect plan.
- Media loses its relationships.
- Plugin-controlled behavior disappears.
Confirm how the target will be edited and used, as well as which records exist.
Identify Plugin, Theme, and Builder Dependencies
Plugins, themes, builders and custom code can own storage, presentation or live behavior.
For a WordPress Source, identify which components own layouts, forms, memberships, fields, events, courses, SEO, redirects or commerce. For another Source, design the equivalent target structures rather than assuming WordPress component ownership already exists.
A dependency can own the stored record, its display or the behavior around it. Those are separate decisions even when they appear on one page. The metadata and extension model explains why a saved value does not establish its consumer.
| Dependency type | Common migration concern | Better planning response |
|---|---|---|
| Theme or template settings | Content exists but the target layout, archive template, or responsive display is not reproduced. | Separate data migration from design/theme implementation and visual acceptance. |
| Page builder or block system | Layout is stored as builder metadata, shortcodes, synced patterns, or nested content structures. | Identify priority layouts and decide whether to migrate, rebuild, simplify, or exclude. |
| Custom fields and field groups | Values may control filtering, layout, SEO, relationships, or business rules. | Align supported fields carefully; assess complex or unsupported fields against the target data model and implementation requirements. |
| Plugin-owned records | Memberships, forms, courses, events, directories, bookings, or donations may not be native WordPress records. | Identify owner plugin, storage method, target equivalent, and validation samples. |
| Custom tables | Important data may not live in posts, postmeta, terms, or users. | Review the storage model and target equivalent separately unless a supported transfer path is confirmed. |
| External integrations | CRM, search, analytics, LMS, ERP, payment, identity, or marketing systems may own operational data. | Decide whether data should migrate, reconnect, synchronize, or remain outside scope. |
Do not treat plugin functionality as ordinary content migration. Each dependency needs an agreed treatment: supported transfer, compatible field mapping, target setup, separate implementation or explicit exclusion.
Plan URLs and SEO With the Architecture
Content, categories, tags, custom post types, taxonomy archives, media, internal links, redirects and SEO plugin fields shape WordPress URL and search presentation. Changing the target architecture can change the continuity work required; native features alone do not establish SEO preservation.
Identify continuity evidence before launch:
- Priority paths: high-value URLs, source permalink patterns, CMS Pages and Blog Posts.
- Discovery: category, tag and custom-taxonomy archives.
- Site contexts: media URLs and multilingual paths.
- Continuity controls: redirects, canonical values, metadata and internal links.
If the content model or permalink structure changes, revise the route plan accordingly.
| SEO or URL area | Why it matters | Validation focus |
|---|---|---|
| CMS Page URLs | Important service, policy, landing, and informational pages may carry traffic or backlinks. | Slug preservation, redirect mapping, page hierarchy, internal links, and metadata. |
| Blog Post URLs | Date-based or category-based permalink patterns may differ from the target structure. | Post slugs, dates, categories, redirects, canonical handling, and internal links. |
| Taxonomy archives | Categories, tags, and custom taxonomies may create public archive pages. | Archive URLs, indexation expectations, content quality, and redirect decisions. |
| Media URLs | Images and files may be indexed, linked, or embedded across pages. | Attachment references, file paths, alt text, captions, and broken media checks. |
| Custom post type archives | Resources, events, profiles, courses, and listings may have their own URL patterns. | Archive slugs, single-record URLs, filters, breadcrumbs, and redirects. |
| SEO plugin fields | Titles, descriptions, canonicals, schema settings, and social previews may live in plugin metadata. | Field mapping, target plugin compatibility, and sample page verification. |
Plan URL changes and redirects with the content architecture. The chosen content model and permalinks determine which route and metadata work is needed, so continuity cannot be left to post-migration cleanup.
Plan Around Ownership
Organize the operating model around three responsibilities:
- Content: which records become Pages, posts, custom post types, taxonomies, media, users or plugin data.
- Presentation: which output depends on blocks, themes, templates, builders, shortcodes or manual design work.
- Function: which behaviors belong to plugins, custom code, integrations or target configuration.
| Priority | Decision to make | Why it controls migration quality |
|---|---|---|
| Content architecture | Decide which source records become native content, custom content, plugin records, or excluded data. | Prevents content from being flattened into ordinary pages. |
| URL and SEO continuity | Identify high-value URLs, permalink changes, redirects, metadata, and internal-link dependencies. | Protects traffic and avoids launch-week URL confusion. |
| Plugin and custom data | Identify records controlled by plugins, custom fields, custom tables, or external systems. | Clarifies which fields belong to confirmed transfer scope and which require separate implementation work, target setup or exclusion. |
| User and role meaning | Clarify authors, editors, subscribers, members, customers, instructors, vendors, or administrators. | Prevents user records from losing permission or relationship meaning. |
| Visual output | Decide which templates, layouts, blocks, forms, and page-builder sections must be recreated or validated. | Prevents content migration from being mistaken for finished site presentation. |
| Operating ownership | Confirm hosting, backups, updates, caching, security, deployment, and plugin maintenance. | WordPress requires target operation after data arrives. |
Choose the next planning question:
- Is the operating model suitable? Review WordPress fit.
- Are the agreed inputs and target decisions ready? Use the WordPress preparation checklist.
- Does the delivered result meet expectations? Follow WordPress validation priorities.
The plan needs the records that serve the site's purpose and clear owners for non-data work; it does not need every possible source record.
Conclusion
WordPress is a CMS foundation whose migration quality depends on coherent content, people, presentation and continuing application ownership. It can be a complete target for a content-only site; selling requires a separately qualified commerce layer.
Separate core content from WooCommerce, plugin behavior, custom fields and tables, external systems and target setup. Preserve the agreed records and relationships, then assign layout, workflow, field alignment, implementation and validation responsibilities to the actual target owners.
Common Questions
Is WordPress a native e-commerce platform?
No. WordPress is a CMS and site foundation. E-commerce behavior usually depends on WooCommerce or another commerce plugin, external commerce system, or custom implementation. A WordPress migration should not assume product, cart, checkout, order, tax, shipping, or payment behavior unless that layer is part of the target scope.
Why should WooCommerce be planned separately from WordPress?
WooCommerce adds a commerce data model inside WordPress. WordPress owns the CMS foundation, while WooCommerce owns product, variation, order, customer-commerce, coupon, checkout, tax, shipping, and payment-context behavior. Combining them too early can hide differences in data ownership, transfer scope and validation needs.
What WordPress data usually needs extra review before migration?
Review the actual transfer path and intended consumer for these groups:
- Structure: custom post types, custom taxonomies, custom fields, page-builder data, plugin records and custom tables.
- People and functions: users with special roles, forms, memberships, courses, events and directories.
- Continuity: SEO metadata, redirects, media attachments and external-system identifiers.
Can a migration preserve the exact WordPress page design?
The selected migration workflow can preserve content and metadata within its confirmed scope, but exact design depends on theme, template, block, builder, shortcode, media, and manual implementation decisions.
Priority pages should be visually validated after migration.
When does WordPress migration require separate implementation review?
Qualify the actual field, table, relationship and consumer first. Compatible custom fields or external IDs can follow confirmed mapping; their names alone do not determine handling.
Unsupported plugin records or tables, bespoke transformations, custom post type relationships, custom-built platform handling and workflow changes need separate review against the target model. Retaining values does not recreate a live workflow.