WordPress 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. Each major risk below links the source assumption to the WordPress constraint, migration consequence, operational impact, mitigation cue, accountable owners, and evidence of control.
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 carry 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. |
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. Menus and navigation are separate records, and taxonomy terms can own public archives with their own routes. Similar labels may belong to different taxonomies or classify different post types.
| 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 owning plugin, field definition, data type, serialization, and referenced object IDs. |
| 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. |
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. |
Password hashes and external identity providers require their own compatibility decision.
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. |
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. |
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.