WordPress stores much of its visible content through a small set of reusable core structures, but those structures can support very different applications. A record in the posts table may represent a Blog Post, CMS Page, media attachment, navigation item, revision, or custom post type. A taxonomy can classify editorial content, directory records, courses, events, or Products. Metadata can be a harmless display value or the field that connects a record to a plugin, template, permission rule, or external system.
The important migration decision is therefore not whether a value can enter WordPress. It is what WordPress object should own it and which relationships make the record manageable. A source “page” may become a CMS Page, a custom post type, a taxonomy archive, a plugin record, or several linked objects. A source “customer” may become a WordPress user, a commerce-plugin Customer, a membership profile, a CRM contact, or no WordPress account at all.
WordPress Core Provides Reusable Record Types, Not One Universal Business Schema
WordPress core separates content, classification, media, identity, settings, comments, routing, and presentation. Plugins can register new record types or create separate tables for specialized applications. Themes and block templates determine output but do not automatically own the underlying business records.
| WordPress layer | Core meaning | Translation consequence |
|---|---|---|
| Posts table | Stores multiple post types, including Posts, Pages, attachments, revisions, menu items, and registered custom post types | The post type and its relationships matter more than the shared table location. |
| Taxonomies and terms | Classify records through hierarchical or flat vocabularies | A source Category cannot be mapped safely without knowing what it classifies and how the destination uses it. |
| Metadata | Adds key-value data to posts, users, terms, and comments | The same storage pattern can carry display fields, relationships, permissions, plugin state, or external identifiers. |
| Users, roles, and capabilities | Represent identity and authorization | A WordPress user is not automatically a Customer, member, learner, donor, vendor, or staff profile. |
| Options and settings | Store site-level or plugin-level configuration | Configuration records should not be mistaken for portable content entities. |
| Comments | Store interactions attached to posts or other supported objects | Blog comments, Product reviews, testimonials, questions, and discussions may need different destination owners. |
| Plugins and custom tables | Add domain-specific records and behavior | Commerce, memberships, forms, events, directories, learning, and bookings require owner-specific interpretation. |
WordPress can therefore receive many source data types, but the destination model must name the intended post type, taxonomy, metadata owner, plugin owner, and route. Without those decisions, migrated content may exist in the database while remaining absent from the editor, archives, templates, search, permissions, or application workflow.
Blog Posts, CMS Pages, and Custom Post Types Carry Different Content Meaning
WordPress Posts and Pages share core storage but serve different editorial roles. Blog Posts usually belong to a dated publishing stream and can participate in categories, tags, authorship, archives, feeds, and chronological navigation. CMS Pages usually represent relatively stable site content and can form parent-child hierarchies. Custom post types model structured domains beyond ordinary editorial content.
A source platform may call every public record a page even when the records represent events, locations, case studies, resources, staff, courses, properties, or listings. Translating all of them into CMS Pages removes the type boundary that supports specialized fields, archives, filters, templates, and administration.
| Source record | Possible WordPress destination | Relationship that defines the choice |
|---|---|---|
| News article or editorial entry | Blog Post | Publication date, author, categories, tags, archives, feeds, and related content |
| About, contact, policy, or service page | CMS Page | Stable hierarchy, menu placement, page template, and route |
| Event | Event custom post type or plugin-owned event record | Date, venue, organizer, recurrence, ticketing, and calendar relationships |
| Property or directory listing | Listing custom post type or directory-plugin record | Location, attributes, taxonomy filters, owner, status, and search relationships |
| Course or lesson | LMS-owned post type and related tables | Course hierarchy, enrollment, progress, quizzes, certificates, and access rules |
| Product | Commerce-plugin Product model | Product type, variation, price, stock, tax, shipping, Customer, and Order relationships |
| Reusable design section | Block pattern, template part, builder record, or embedded blocks | Presentation reuse rather than independent editorial identity |
Custom post types can be stored alongside other post types, but shared storage does not make them interchangeable. Their registered capabilities, supported editor features, taxonomies, metadata, REST exposure, archive behavior, and templates define how editors and applications use them.
Taxonomies, Terms, Menus, and Archives Are Related but Not Interchangeable
WordPress taxonomies classify objects. Categories are hierarchical by default, tags are flat, and plugins or themes can register custom taxonomies for domains such as topics, brands, locations, industries, resource types, course levels, or Product attributes. Terms are the individual values inside those taxonomies.
Menus and navigation are separate. A menu entry can link to a CMS Page, Blog Post, taxonomy archive, custom post type archive, external URL, or another route. The existence of a taxonomy term does not guarantee a corresponding menu entry, and menu hierarchy does not necessarily reproduce content hierarchy.
| Source structure | WordPress ownership | Translation concern |
|---|---|---|
| Editorial section | Category or custom taxonomy | Preserve the relationship to the correct post types and the intended archive behavior. |
| Keyword label | Tag or flat custom taxonomy | Avoid creating a deep hierarchy when the source value is only an annotation. |
| Brand, region, or resource type | Custom taxonomy, commerce taxonomy, or plugin classification | Keep vocabularies separate when they control different filters or templates. |
| Main navigation tree | Navigation/menu records | Menu order and nesting are presentation relationships, not taxonomy membership. |
| Landing page for a classification | Taxonomy archive, CMS Page, or plugin view | Decide which object owns the route, content body, and filtered result set. |
| Source Category used only internally | Metadata or external classification | Do not expose an operational code as a public WordPress archive by default. |
Term relationships also need scope. A term assigned to Blog Posts may share a label with a term assigned to Products, but the two can belong to different taxonomies and serve different applications. Combining them solely because their names match can merge unrelated archives and filters.
Metadata and Custom Fields Can Carry Display Data, Relationships, or Application State
WordPress metadata APIs support additional values for posts, users, terms, and comments. Plugins and themes commonly use metadata for subtitles, SEO values, external IDs, template choices, file references, locations, dates, prices, visibility settings, relationship IDs, and serialized application state.
The storage pattern alone does not reveal the meaning. A meta key may hold a simple text value, a reference to another post, a list of term IDs, an attachment ID, a structured array, or a plugin-specific state machine. A field that displays correctly in the source can become unusable if the destination copies only the literal value and loses the field definition or referenced object.
| Metadata pattern | Possible meaning | Destination requirement |
|---|---|---|
| Plain text or number | Subtitle, specification, date, score, code, or editorial label | Attach the value to the correct object and expose it through the intended editing interface. |
| Post or attachment ID | Relationship to another record or media item | Translate the reference to the destination record rather than copying the old numeric ID. |
| Term ID | Classification relationship | Reconnect the value to the destination taxonomy and term. |
| User ID | Author, owner, instructor, vendor, reviewer, or assignee | Preserve the business role, not only the source user number. |
| Serialized array or JSON | Repeater fields, layouts, settings, coordinates, or plugin state | Interpret the owning plugin schema before deciding whether the structure remains portable. |
| External identifier | CRM, ERP, PIM, DAM, or legacy-system key | Keep it stable on the destination entity that represents the same business object. |
Field definitions can matter as much as field values. Systems that register custom fields may define field type, allowed values, display labels, input rules, repeaters, groups, conditional logic, and relationships. Copying values without the definitions can leave administrators with data that no editor or template knows how to use.
Blocks, Builders, Templates, and Theme Data Belong to the Presentation Layer
WordPress content can be represented as classic editor HTML, block markup, shortcodes, builder-specific structures, reusable blocks, patterns, template parts, or theme settings. These layers can reference the same underlying CMS Page or custom post type while encoding presentation in different ways.
A source page builder may store layout data in post_content, metadata, custom post types, options, or custom tables. A block-based site can store content blocks in the record while the Site Editor and theme provide templates around it. The destination model must keep content ownership separate from presentation ownership.
| Presentation structure | What it owns | What remains separate |
|---|---|---|
| Core blocks in post content | Structured content and block attributes for one record | Site-wide templates, navigation, plugin data, and external records |
| Shortcodes | Placeholder instructions interpreted by a plugin or theme | The actual plugin configuration or data queried by the shortcode |
| Page-builder layout | Builder-specific sections, widgets, styles, and references | The business records displayed inside the layout |
| Template or template part | Site-wide rendering structure | CMS Page, Blog Post, Product, Customer, or Order data |
| Theme option | Global design or display setting | Portable editorial content and application records |
| Reusable block or pattern | Reusable presentation content | Every instance or business entity shown through the pattern |
A destination does not need to preserve a source builder’s internal storage format when the target uses another rendering system. It does need to preserve the content, media, links, reusable relationships, and record ownership that the new implementation requires.
Media Attachments Are Records With Files, Metadata, and Parent Relationships
WordPress media is not only a directory of copied files. Media items can be attachment post records with titles, captions, descriptions, alt text, MIME types, file metadata, image sizes, authorship, dates, and parent relationships. Content bodies, featured-image metadata, galleries, blocks, plugin fields, and external systems can all reference those attachments.
| Source media situation | WordPress representation | Relationship consequence |
|---|---|---|
| Featured image | Attachment plus featured-image relationship to a content record | The file and the reference must both be translated. |
| Image embedded in content | Attachment or external file plus URL inside content | The destination content must point to the correct file location. |
| Gallery | Multiple attachments plus block, shortcode, builder, or plugin structure | File transfer alone does not preserve order, captions, or gallery behavior. |
| Downloadable document | Media attachment, file URL, or plugin-owned download | Access rules, link destinations, and replacement paths remain part of the model. |
| Product or listing image | Attachment related through a commerce or directory plugin | The plugin relationship is distinct from ordinary CMS Page media. |
| Externally hosted asset | Remote URL or DAM reference | The destination must retain the external owner rather than inventing a local attachment relationship. |
Attachment parent IDs are not always a complete ownership map. The same image can appear in several records, and newer editor workflows may not set a meaningful parent. The destination should derive relationships from actual references, featured-image fields, galleries, plugin records, and content markup rather than relying on the parent column alone.
Users, Roles, Capabilities, and Profiles Represent Different Account Meanings
WordPress users provide login identity, while roles and capabilities define permitted actions. User metadata adds profile values and plugin-specific state. Plugins can introduce memberships, courses, communities, commerce accounts, vendor profiles, staff directories, subscriptions, or protected-content relationships.
| Source identity | Possible WordPress representation | Ownership distinction |
|---|---|---|
| Author or editor | WordPress user with authorship and editorial capabilities | Post ownership and revision history may matter independently of login status. |
| Site administrator | User with administrative capabilities | Administrative authority is not equivalent to Customer or member status. |
| Newsletter subscriber | External marketing contact, plugin record, or limited WordPress user | Marketing consent and list membership should not be inferred from a login account. |
| Member | WordPress user plus membership-plugin profile, plan, access, and status records | The user record alone does not reproduce membership behavior. |
| Learner | WordPress user plus LMS enrollment, progress, quiz, and certificate records | Learning history belongs to the LMS domain. |
| Customer | Commerce-plugin Customer, WordPress user, guest identity, or external CRM contact | Commerce ownership must be named explicitly. |
| Vendor or marketplace seller | User plus plugin-owned vendor and payout records | Role membership alone does not represent the full commercial account. |
Source password hashes, authentication providers, multi-factor settings, and single-sign-on identities may not be portable as ordinary user fields. The account can retain its business identity even when the authentication relationship must be represented differently.
Comments, Revisions, and Historical Records Need Their Own Context
Comments can represent blog discussion, Product reviews, testimonials, questions, support messages, or plugin interactions. Revisions represent earlier versions of content rather than separate public records. Autosaves, trash states, scheduled posts, and private posts also carry lifecycle meaning.
| Historical record | WordPress meaning | Translation boundary |
|---|---|---|
| Blog comment | Interaction attached to a Blog Post or CMS Page | Preserve author, date, status, parent reply, and owning content relationship. |
| Product review | Comment-like record owned by a commerce plugin | Rating, verified-owner status, Product reference, and moderation meaning differ from an ordinary comment. |
| Threaded discussion | Comment hierarchy or community-plugin record | Parent-child replies and membership context can be essential. |
| Content revision | Historical version of one post | Do not present revisions as duplicate public CMS Pages or Blog Posts. |
| Draft, scheduled, private, or trashed record | Lifecycle state of a content entity | Publication state should remain distinct from menu visibility and access permissions. |
Historical records can be intentionally excluded when they have no ongoing business value, but they should not be silently confused with current content. The destination model should state whether it represents the current record, its editorial history, or both.
Plugins and Custom Tables Define Application-Specific Ownership
WordPress plugins can register custom post types, taxonomies, metadata, roles, REST endpoints, settings, and scheduled events. They can also create dedicated database tables when the domain requires structures that do not fit core post and metadata patterns. Forms, bookings, memberships, learning systems, events, directories, donations, redirects, analytics, automation, and commerce commonly add their own records.
| Plugin-owned area | Records that may exist | Translation requirement |
|---|---|---|
| Forms | Form definitions, fields, submissions, notifications, and external integrations | Separate reusable form structure from historical submission data and delivery workflows. |
| Memberships | Plans, subscriptions, access rules, user relationships, and protected content | Keep identity, entitlement, payment, and content-access ownership distinct. |
| Learning systems | Courses, lessons, enrollments, progress, quizzes, attempts, and certificates | Preserve the relationships required by the destination learning model. |
| Events and bookings | Events, sessions, resources, attendees, reservations, payments, and reminders | Do not flatten schedules and booking relationships into generic posts. |
| Directories or marketplaces | Listings, owners, locations, attributes, claims, vendors, and payouts | Identify which records are content and which belong to the application workflow. |
| SEO and redirects | Metadata, canonical values, schema fields, redirects, and social previews | Attach values to the correct route-owning record and keep site-wide settings separate. |
| Custom tables | Bespoke entities, histories, relationships, logs, and integration keys | Translate the business schema instead of copying table rows without their owning application. |
Plugin filenames and active-status lists are not the data model. The actual ownership map comes from registered post types, taxonomies, metadata keys, custom tables, user roles, options, scheduled events, and external references used by the site.
URLs, Permalinks, Archives, and Multisite Scope Are Part of Record Identity
WordPress routes can depend on post type, slug, parent Page, publication date, category, custom taxonomy, archive settings, rewrite rules, site domain, and plugin endpoints. A source URL therefore cannot always be reconstructed from the destination title alone.
| Route element | Record relationship | Destination implication |
|---|---|---|
| CMS Page path | Page slug plus parent hierarchy | Moving the Page under a different parent can change the full path. |
| Blog Post permalink | Post slug plus the configured permalink pattern | Date or Category segments may be part of the historical URL. |
| Taxonomy archive | Taxonomy rewrite and term slug | A term can own a public archive even when it has no menu entry. |
| Custom post type archive | Registered post type rewrite and archive settings | Single-record and archive routes may need separate identities. |
| Plugin endpoint | Application route attached to an account, Product, course, or other area | The endpoint is not an ordinary CMS Page. |
| Multisite URL | Network, site, domain, and path scope | Records can belong to one site while users or plugins have network-wide relationships. |
| Redirect | Old route to new destination relationship | The old path remains a record of continuity even when the target slug changes. |
WordPress Multisite adds another ownership layer. Posts, Pages, terms, options, and many plugin records are site-specific, while users can participate across the network. Network-activated plugins and shared external services can introduce additional scope. A source export that omits site identity can merge records that were intentionally separated.
WordPress Core and Commerce Plugins Must Remain Separate Models
WordPress core does not provide native Products, carts, checkout, Customers, Orders, coupons, payment, shipping, tax, inventory, or fulfillment. Those entities belong to WooCommerce or another commerce plugin. They may use WordPress post types, taxonomies, users, metadata, comments, and tables, but their business meaning comes from the commerce application.
| Commerce concept | WordPress core relationship | Actual owner |
|---|---|---|
| Product and variation | May use custom post types, taxonomies, metadata, or dedicated tables | Commerce plugin and its extensions |
| Customer | May connect to a WordPress user or remain a guest transaction identity | Commerce plugin, CRM, membership system, or external account platform |
| Order and Order line | May use custom post types or dedicated commerce tables | Commerce plugin and payment or fulfillment extensions |
| Product review | May use comments plus rating metadata | Commerce plugin’s Product-review model |
| Subscription, booking, bundle, or vendor record | May reference Products, users, and Orders | Specialized extension or marketplace application |
| Payment, tax, shipping, and fulfillment context | Can appear in historical transaction records | Commerce and operational integrations, not WordPress core content |
A WordPress migration and a WooCommerce migration are therefore different scopes even when both use the same installation. The destination must identify the commerce plugin, its version and storage model, installed extensions, and external systems before interpreting Products, Customers, Orders, or application-specific records.
A WordPress Translation Map Should Preserve Ownership and Editability
The destination model is coherent when every record has a named type, owner, classification system, metadata contract, route, and editing surface. The objective is not to copy the source database design. It is to preserve the relationships that let editors, administrators, applications, and external systems understand the data.
| Source question | Translation decision |
|---|---|
| Is the record editorial content or an application entity? | Choose a core post type, custom post type, plugin record, or external-system owner. |
| Does a grouping classify records or only arrange navigation? | Separate taxonomy relationships from menus and landing pages. |
| Does a custom value contain data or reference another object? | Translate both the value and its target relationship. |
| Is layout stored with content or in a builder/template system? | Preserve content meaning separately from presentation implementation. |
| Is an account only a login identity or part of a membership, learning, commerce, or vendor system? | Keep the WordPress user and application profile as distinct but connected records. |
| Does a URL come from a slug, hierarchy, archive, plugin endpoint, or Multisite scope? | Preserve the route-owning relationship rather than relying on titles. |
| Is the entity owned by WordPress core, a plugin, a custom table, or an external platform? | Keep the actual owner explicit and retain stable cross-system identifiers. |
These decisions keep the migrated site manageable. Editors can find the right records, templates can render the intended objects, archives and filters can query the correct classifications, accounts retain their application meaning, and integrations continue to identify the same business entities.
Conclusion
WordPress changes data meaning by using reusable core tables for many record types while allowing plugins and custom code to define specialized applications. Posts, CMS Pages, custom post types, taxonomies, metadata, attachments, users, comments, options, plugin tables, routes, and commerce entities may share infrastructure without sharing business meaning.
A coherent migration preserves that ownership. Content remains connected to the correct post type and taxonomy, metadata remains connected to its field contract and referenced records, media remains connected to the content that uses it, users remain connected to roles and application profiles, routes remain connected to their owning objects, and plugin or commerce records remain separate from ordinary WordPress core content.
Common Questions
Are WordPress custom post types the same as CMS Pages?
No. Both can be stored through the WordPress posts system, but a custom post type can have its own editor features, taxonomies, capabilities, metadata, archive, REST behavior, and templates. The destination should preserve the type that represents the record’s business purpose.
Can every source Category become a WordPress Category?
No. The source grouping may belong in a standard Category, tag, custom taxonomy, commerce taxonomy, navigation menu, metadata field, plugin filter, or external classification. The choice depends on what the grouping classifies and how the destination needs to query or display it.
Why are WordPress custom fields relationship-sensitive?
A custom field can hold a literal value, another record’s ID, an attachment reference, a term, a user, a serialized structure, or a plugin state. Copying the visible value without translating the relationship or field definition can leave the destination data unusable.
Do themes and page builders own the underlying business records?
Usually not. They own presentation structures, templates, styles, and layout references. The CMS Page, Blog Post, Product, event, listing, or other entity remains owned by WordPress core or the relevant plugin even when a builder controls how it is displayed.
Should WooCommerce Products be treated as ordinary WordPress posts?
No. WooCommerce can use WordPress infrastructure, but Products, variations, Customers, Orders, coupons, inventory, payment, shipping, tax, and extensions belong to the WooCommerce commerce model. Their relationships require commerce-specific interpretation.
When does WordPress data belong in a custom table or external system rather than a post type?
The owner is determined by the application that manages the record. High-volume transactions, specialized histories, complex many-to-many relationships, integration logs, or domain-specific workflows may live in plugin tables or external platforms. The migration model should preserve the entity and its references without forcing it into a generic post merely because WordPress is the site framework.