When WordPress is the prospective Target Platform, migration risk begins with a simple fact: the same core storage can represent very different business objects. Posts, CMS Pages, attachments, revisions, menu items, and custom post types can share the posts table, while plugins add taxonomies, metadata, roles, options, scheduled events, and custom tables. A database row is therefore not a reliable statement of business ownership.
The most dangerous migration assumption is that WordPress is only a collection of pages and media files. The visible site may depend on plugin schemas, builder data, serialized metadata, user capabilities, Multisite scope, rewrite rules, external services, and commerce applications such as WooCommerce. A functioning destination needs more than a row for each object: editors, public routes, application consumers, and site permissions must still agree on what those objects mean.
Custom Post Types Can Be Flattened Into CMS Pages
WordPress stores built-in and custom post types in the posts table, but registered post types can have their own editor features, capabilities, taxonomies, archives, REST behavior, and templates. A source record that looks like a page may actually be an event, listing, course, resource, property, or staff profile.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | Every public source record can become a WordPress CMS Page. |
| Platform constraint | Custom post types need active type-specific registration, queries, templates, capabilities, taxonomies, and routes. |
| Migration consequence | Structured entities are flattened into generic pages or copied into a post type that the destination application does not manage. |
| Operational impact | Editors lose specialized interfaces, archives and filters fail, and templates cannot query the intended records. |
| Mitigation cue | Map each source entity to a core post type, registered custom post type, plugin record, or external-system owner. |
| Affected owners | Content operations, development, application owners, SEO, and site administration. |
| Control signal | Editors can manage representative records through the intended post-type interface and public queries return the correct objects. |
Stored posts and active registration are different dependencies. If a source theme registered a custom post type, changing themes can leave the records stored but remove their intended management interface. Public querying, archive routes, REST exposure, and editor support also depend on the destination registration rather than on the presence of a post row. Content and development owners should give each retained type a continuing registration owner; the signal is that intended editors and public queries can use it without relying on the old theme.
A shared database table does not make post types interchangeable.
Taxonomies, Terms, Menus, and Archives Can Be Merged Incorrectly
WordPress taxonomies classify objects through hierarchical or flat vocabularies. Classic menus use menu items and menu relationships; block-based navigation can use separate Navigation records and blocks consumed by the target theme. Neither is simply a taxonomy tree. Terms, post-type archives, and landing pages can own distinct public routes even when their labels match.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | Source Categories can be copied into the default WordPress Category taxonomy. |
| Platform constraint | Categories, tags, custom taxonomies, menu items, post-type archives, and landing pages serve different purposes. |
| Migration consequence | Unrelated vocabularies are merged, navigation hierarchy is mistaken for classification, or archive routes disappear. |
| Operational impact | Filters and archives return the wrong content, menus become confusing, and SEO pages lose their intended scope. |
| Mitigation cue | Identify what each grouping classifies, which post types use it, whether it is hierarchical, and whether it owns a public route. |
| Affected owners | Content, SEO, information architecture, development, and site administration. |
| Control signal | Terms classify the intended objects, menus link deliberately, and archives expose only the expected record set. |
Metadata Can Preserve Values While Breaking References
Post, user, term, and comment metadata can contain plain text, IDs, attachment references, repeaters, serialized arrays, JSON, plugin state, external identifiers, or relationship fields. Copying the stored value without interpreting its schema can point to nonexistent destination records.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | Custom fields are portable key-value pairs. |
| Platform constraint | Metadata meaning depends on its owner, field definition, type, serialization, referenced IDs, and permitted access. |
| Migration consequence | Values exist but reference old post, term, user, or attachment IDs, or no editor knows how to display them. |
| Operational impact | Pages render empty, relationships break, administrators overwrite data, and integrations cannot resolve records. |
| Mitigation cue | Classify metadata as literal data, object reference, structured field, application state, configuration, or external key. |
| Affected owners | Development, content operations, application owners, integrations, and reporting teams. |
| Control signal | Representative fields render and edit correctly, and every translated reference resolves to the intended destination object. |
Storage access also differs from API exposure. A custom post type or metadata key may be valid in the database yet absent from a REST response because registration, schema, editor support, or authorization excludes it. Treating a successful API response as a complete application export can silently omit required data; exposing more fields without reviewing permissions can create the opposite risk. Integration and application owners need an agreed access contract, with representative required fields visible to the intended caller and sensitive fields still restricted.
Plugins and Custom Tables Can Own the Real Application
Plugins can register post types, taxonomies, metadata, roles, REST endpoints, scheduled actions, and settings, or create dedicated tables for transactions and complex relationships. Forms, memberships, learning systems, directories, events, bookings, donations, and commerce frequently extend beyond core WordPress storage.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | Copying core WordPress tables preserves plugin applications. |
| Platform constraint | Plugin-owned records may span custom tables, options, cron events, files, post types, metadata, and external services. |
| Migration consequence | Visible content moves while submissions, entitlements, enrollments, bookings, transactions, or automation state disappear. |
| Operational impact | Business workflows stop even though the public pages remain available. |
| Mitigation cue | Build an application ownership map from active plugins, registered objects, custom tables, scheduled events, and external connections. |
| Affected owners | Application owners, development, operations, finance, security, and external vendors. |
| Control signal | Every business-critical workflow has its complete record set, parent relationships, and future operating owner. |
An inactive plugin may still own historical records; an active plugin may have no data worth carrying. Status alone is not sufficient classification.
Media and Builder Content Can Break Without Their Reference Graph
WordPress media can be attachment records with files, metadata, image sizes, alt text, captions, authorship, and relationships. Blocks, shortcodes, page builders, galleries, featured images, theme templates, and plugin fields can reference those attachments in different ways.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | Copying the uploads directory and page HTML preserves media and layout. |
| Platform constraint | Files, attachment records, generated sizes, featured-image metadata, block attributes, shortcodes, and builder structures form a reference graph. |
| Migration consequence | Files exist but pages reference old URLs or IDs, galleries lose order, and builder sections render empty. |
| Operational impact | Broken images, inaccessible downloads, weak accessibility, and damaged layouts affect content and conversion. |
| Mitigation cue | Preserve file identity, attachment metadata, generated derivatives where needed, and every content or builder reference to the destination asset. |
| Affected owners | Content, design, development, accessibility, SEO, and digital asset management. |
| Control signal | Representative featured images, galleries, downloads, blocks, and builder pages resolve the correct destination attachments. |
Users, Roles, and Application Profiles Can Be Mistaken for One Account Model
WordPress users provide login identity, while roles and capabilities determine permissions. Membership, learning, marketplace, commerce, community, and directory plugins can add separate profiles and relationships. Multisite can also share users while assigning site-specific access.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | A user row fully represents the person’s account purpose and access. |
| Platform constraint | Roles, capabilities, user metadata, site membership, and plugin-owned profiles can independently control authority and business status. |
| Migration consequence | Users receive excessive access, lose application entitlements, or become disconnected from authored content and historical records. |
| Operational impact | Security, editorial ownership, memberships, learning access, and Customer service become unreliable. |
| Mitigation cue | Separate identity, authentication, authorship, role, capability, site membership, and application profile. |
| Affected owners | Security, HR or staff administration, content, application owners, privacy, and support. |
| Control signal | Representative administrators, editors, authors, members, Customers, and guests retain only the intended access and relationships. |
Authentication compatibility remains separate from identity and permission mapping. The exact supported Source-to-Target path determines whether usable password verification can continue or an invite, reset, activation, or first-login transition is needed. External identity-provider access also depends on its continuing provider relationship.
Multisite Can Collapse Site Scope and Domain Ownership
WordPress Multisite uses one installation for several sites. Individual sites have separate content tables and media paths, while users are shared across the network. Themes and plugins can be network-enabled, and domains may be mapped to specific sites.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | A Multisite network can be treated as one flat WordPress database. |
| Platform constraint | Posts, terms, options, uploads, routes, and many plugin records are site-specific, while users and some administration are network-wide. |
| Migration consequence | Records from different sites are merged, media paths collide, or users receive access to the wrong site. |
| Operational impact | Regional or brand content leaks across sites, domains resolve incorrectly, and network administration becomes unsafe. |
| Mitigation cue | Preserve blog/site identity for every scoped record and document network-level themes, plugins, users, domains, and integrations. |
| Affected owners | Network administrators, regional teams, security, content, infrastructure, and SEO. |
| Control signal | Each domain and site exposes only its intended content, media, options, users, and plugin records. |
A numeric post or attachment ID is not a network-wide content identity: the same number can name different objects on different sites. Resolve references using the source site and object together, then map destination site access separately from the shared user account. Switching a query’s site context does not automatically switch the loaded plugin or theme code. Network and application owners therefore need evidence that each site’s records are interpreted by the correct application, not just read from the correct tables.
WordPress Core Can Be Confused With WooCommerce or Another Commerce Plugin
WordPress core does not natively own Products, carts, checkout, Customers, Orders, coupons, inventory, payment, shipping, tax, or fulfillment. WooCommerce and other commerce plugins may use WordPress infrastructure, but their business meaning belongs to the commerce application and extensions.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | Commerce records can be handled as ordinary WordPress posts, users, and comments. |
| Platform constraint | Products, variations, Customers, Orders, reviews, subscriptions, bookings, vendors, and payments are governed by plugin-specific schemas and versions. |
| Migration consequence | Commerce entities are flattened into content records or omitted because they are not recognized as WordPress core data. |
| Operational impact | The site retains marketing content but loses sellable catalog, Customer history, Order evidence, or extension behavior. |
| Mitigation cue | Name the commerce plugin, storage model, extensions, custom tables, external services, and version-specific ownership before scoping records. |
| Affected owners | Ecommerce operations, finance, fulfillment, Customer service, development, and application vendors. |
| Control signal | Commerce records are managed through the intended application and remain distinct from ordinary WordPress content. |
Runtime, Theme, and Plugin Compatibility Can Turn Data Success Into Site Failure
A self-managed WordPress site depends on PHP, database, web server, filesystem permissions, cron, caching, themes, plugins, and security controls. Migrated data can be correct while the target runtime is incompatible with the code that interprets it.
| Risk-chain element | WordPress-specific interpretation |
|---|---|
| Assumption | A database and uploads copy is sufficient for a functioning WordPress destination. |
| Platform constraint | WordPress behavior depends on compatible runtime versions, plugin and theme code, rewrite rules, scheduled events, and filesystem access. |
| Migration consequence | Data loads but administration, public routes, forms, jobs, or integrations fail. |
| Operational impact | The site becomes unstable, insecure, slow, or incapable of completing business workflows. |
| Mitigation cue | Separate data integrity from runtime compatibility and assign ownership for code, hosting, security, caching, cron, and observability. |
| Affected owners | Infrastructure, development, security, operations, and application vendors. |
| Control signal | The destination processes representative public, administrative, scheduled, and integration workflows without runtime errors. |
Scheduled work adds a less visible runtime constraint. Default WP-Cron is triggered by page loads rather than running continuously as a system scheduler; a low-traffic destination may delay due work unless another trigger is deliberately maintained. Infrastructure and application owners should agree how time-sensitive jobs run and how any copied schedules avoid duplicate external actions. A page that renders correctly does not demonstrate that its scheduled publishing, reminders, or application jobs execute under the intended authority.
Conclusion
WordPress risk comes from hidden ownership, not from a shortage of storage options. The same tables can hold many record types, while plugins, custom tables, metadata, users, themes, builders, and Multisite scope define how the data is actually used.
A controlled migration identifies the application behind every record. Post types remain distinct, taxonomy and route ownership stays explicit, metadata references are translated, users retain only intended authority, and commerce records remain under their commerce plugin rather than being mistaken for WordPress core content.
Common Questions
Why is WordPress migration risky when most pages look simple?
A simple page can depend on custom post types, metadata, attachments, shortcodes, builder structures, templates, plugins, and external services. The visible output does not reveal the complete dependency graph.
Can every source record become a WordPress CMS Page?
No. Events, listings, courses, Products, memberships, and other application entities may require custom post types, plugin records, custom tables, or external-system ownership.
Why can copied custom fields stop working?
The stored value may reference an old post, attachment, term, or user ID, or depend on a plugin field definition and serialization format. Literal copying can preserve the bytes while breaking the relationship.
Does copying the uploads directory preserve WordPress media?
Not by itself. Attachment records, metadata, featured-image links, galleries, builder references, generated sizes, and URLs must also resolve correctly.
How does Multisite increase migration risk?
Content, terms, options, media, and many plugin records are site-specific, while users and some administration are shared. Losing site identity can merge records and domains that were intentionally separate.
Should WooCommerce records be included in ordinary WordPress scope?
They require a separately named commerce scope. WooCommerce uses WordPress infrastructure, but Products, variations, Customers, Orders, and extensions belong to the WooCommerce application model.
Can stored WordPress content exist without its intended editor or public route?
Yes. A post row does not register its post type or provide templates, query settings, archive routes, or editor support. If a theme or plugin supplied those definitions, the destination needs a continuing owner for them. Judge continuity by whether the intended editor and public consumer can use the content, not only by whether it remains stored.
Does a complete WordPress REST response prove that all application data is portable?
No. The response is complete only for the endpoint, registered fields, schema, and caller permissions involved. Other metadata, custom tables, or plugin-owned relationships may be outside that contract. Required access and destination interpretation need separate evidence; an API feature does not by itself prove coverage of a migration path.