Before a WordPress migration, establish what makes each selected record understandable and editable. A content export may carry a Page’s text while leaving its custom fields, navigation, builder, permission rules, or plugin application unexplained. Preparation must expose those dependencies before the destination is treated as ready.
Identify the intended site purpose first:
- Publishing, documentation or marketing.
- Membership, directory, learning or event applications.
- The CMS foundation around a WooCommerce Store.
Core Posts and CMS Pages may cover only part of that purpose. The inventories below identify the structures that make retained content editable and understandable.
Produce evidence for the actual Source and decisions for the intended WordPress implementation. Each important record class needs an owner, a retrieval path or inventory, a representative sample and a ready condition.
- For a WordPress Source, preserve installed registrations and storage context.
- For another Source, classify its actual records without assuming a WordPress schema.
Keep CMS content separate from WooCommerce and other plugin-owned application data.
Define Scope and Record Ownership
Classify actual Source records and their intended treatment: WordPress core, named plugins or custom code, retained external systems, archives or deliberate exclusions.
Use the agreed migration scope to distinguish records from their future implementation. A WordPress Source needs its real storage owners; another Source needs its own structures and evidence before choosing a WordPress representation. Native content capabilities do not establish transfer coverage.
Stored content and active definitions are separate dependencies:
- Post types need the registration governing their administration, capabilities, templates, archives and API behavior.
- Custom taxonomies need definitions and object relationships.
- Metadata needs the component interpreting its keys and values.
Inventory stored types even when their owning code is inactive. The WordPress registration and ownership risks explain why a stored row does not prove usable destination content.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Define the intended role of the Target WordPress site | Site owner and content lead | One-page scope statement covering publishing, marketing, membership, directory, learning, commerce, or other application roles | Every major source record class has an intended WordPress, plugin, external-system, archive, or exclusion owner. |
| Separate WordPress CMS scope from WooCommerce or other application scope | Site owner and technical lead | Entity boundary listing CMS Posts, CMS Pages, media, users, menus, and application-owned Products, Orders, memberships, bookings, or submissions | No application record is assumed to be a normal CMS Page or Post solely because it uses WordPress tables. |
| Record the source site topology | Technical owner | Domain list, subdirectories, language sites, Multisite network/sites, staging instances, and active public URLs | The team can identify which site or network owns every selected record. |
| Identify authoritative external systems | Integration owner | CRM, DAM, PIM, LMS, marketing, search, identity, or document-system identifier map | External keys and continuing systems of record are documented before field mapping begins. |
For Multisite, qualify content IDs by site or blog ownership. Posts, CMS Pages, terms, options and many plugin records remain site-specific.
Prepare network identity and site access separately:
- A shared user does not automatically have a role on every site.
- Site administration does not imply unrestricted network access.
Record who can inspect network-wide dependencies as well as local content.
Secure Source Access and Recovery Evidence
Keep three evidence contexts separate:
- Accessible WordPress Source: preserve complete database and relevant file evidence from the same state, including uploads, plugin/theme and language files, remote media and external-service dependencies.
- Other or restricted Source: record the actual connection/export contract, available originals, recovery coverage, limits and owner.
- WordPress Target: confirm administration and implementation access independently from Source backup coverage.
Content exports do not establish full installation restoration. Required omissions need resolution, agreed exclusion or a hold.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm actual Source administration or retrieval access; WordPress administration applies to a WordPress Source | Site administrator | For a WordPress Source: working administrator account and restricted areas; otherwise actual Source access/retrieval owner, permissions and limitations | Required actual Source content, users, media, component ownership and settings can be inventoried through the permitted path; required unavailable areas are resolved, excluded by agreement, or held. |
| Preserve the actual Source recovery package and available input coverage | Actual Source hosting/technical or archive/export owner | For an accessible WordPress Source: dated complete database backup plus wp-content files, uploads, themes, plugins and configuration references; otherwise permitted exports/archives, original media, and recovery coverage/limitations |
Package location, date/state, recovery owner and retention are recorded. Accessible native database/files have recovery evidence; restricted or other Source archives have accepted coverage and limits, with required gaps resolved, excluded by agreement, or held. Exports do not establish a full restore. |
| Capture environment details | Technical owner | Actual Source environment evidence. For an accessible WordPress Source: WordPress/PHP/database versions, active/child theme, active/must-use plugins and relevant server services; otherwise available platform/export/component evidence and access limits | Actual Source content/component ownership and recovery limits can be interpreted; intended WordPress runtime and implementation requirements are assessed independently. |
| Record scheduled and background processes | Plugin or integration owner | Actual Source automated writers: WP-Cron events for a WordPress Source, external schedulers, queues, webhook endpoints and record-changing batch processes where used | Automated writers are known and will not be mistaken for static migrated content. |
| Preserve export evidence | Content and technical owners | Actual Source exports, database/table inventories where accessible, original-media lists and component-specific exports; WordPress export files apply where that is the Source | Each selected actual Source area has an available artifact or documented permitted retrieval path, with coverage, limitations and owner; required missing evidence is resolved, excluded by agreement, or held. |
For a WordPress Source, record the WXR export filters and export-enabled post types. WXR is content evidence, not a complete site backup: plugin tables, site options, theme code, media files and external records need their own coverage. A database inventory can contain relevant records absent from the export.
Before approved cleanup, preserve a protected original recovery package with its timestamp, retrieval location, restoration owner and retention.
Another Source uses its own archives and retrieval evidence. Neither its export nor WXR proves recovery of every required record, file or implementation dependency.
Inventory Content Types and Lifecycle States
List every stored post type in scope, including inactive registrations. Do not rely only on visible administration screens. Include Posts, CMS Pages, attachments, retained revisions and custom types.
For each type, record:
- Purpose and scope: business use, count and public/private status.
- Management: editor features, authorship, dates and owning plugin or codebase.
- Relationships: parent records, taxonomies and archive behavior.
The target needs a deliberate representation for each retained type.
| Record area | Evidence to prepare | Decision that must be resolved | Ready condition |
|---|---|---|---|
| Blog Posts | Samples with authors, dates, excerpts, categories, tags, comments, featured images, and embedded content | Which history, drafts, scheduled records, private records, and archives remain in scope? | Included and excluded lifecycle states are explicit. |
| CMS Pages | Parent-child map, page templates, menu use, forms, embeds, and high-value routes | Which hierarchy and page-template dependencies must continue? | Each important Page has a destination owner and intended parent or top-level status. |
| Custom post types | Registration source, field list, taxonomies, capabilities, archive settings, and representative records | Does the destination retain the type, convert it, or keep it in another application? | Every retained type, including required records from inactive registrations, has a qualified target representation and an editing owner. |
| Revisions, autosaves, and trash | Counts and retention rationale | Are historical versions operationally useful or only database history? | Retention is intentional rather than inherited by default. |
| Private or protected content | Access owner, audience, and current protection mechanism | Does access belong to WordPress roles, a membership plugin, or another system? | Protected records have a documented identity and permission dependency. |
Avoid using record counts as the sole inventory. A custom post type with twenty records can carry more migration complexity than thousands of ordinary Blog Posts when it depends on several taxonomies, relationship fields, custom tables, and public archives.
Separate Classification, Navigation and Archives
WordPress taxonomies classify objects; menus arrange navigation. They should be inventoried separately even when a Category or term also appears in a menu. For each taxonomy, record whether it is hierarchical or flat, which post types it classifies, whether it has public archives, which metadata belongs to terms, and whether equivalent labels exist in another taxonomy.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Inventory standard and custom taxonomies | Content architect or plugin owner | Taxonomy names, registered object types, hierarchy, term counts, term metadata, and archive settings | Every selected term remains connected to the correct taxonomy and object type. |
| Clean duplicate or obsolete terms | Content owner | Merge, retain, rename, and exclude decision list | Similar labels will not be merged unless they represent the same classification. |
| Export navigation structures | Content owner | Primary, footer, utility, contextual, and language-specific trees; classic menu items, Navigation block records, their references, placement, and custom links | Menu placement is documented separately from content hierarchy and taxonomy membership. |
| Document archive destinations | SEO and content owners | Category, tag, custom taxonomy, author, date, and custom post type archive URL list | Every important archive has an intended destination, replacement, or redirect decision. |
Preserve original term, menu and content IDs before approved cleanup.
- Resolve similar labels within their taxonomy and site context, rather than merging by name.
- Inventory classic menus and Navigation block records as distinct representations.
- Preserve content links and their template/block consumers, translating referenced objects to destination identities.
Copied installation-specific numbers do not establish the intended relationship.
Qualify Metadata and Plugin Storage
Inventory important post, user, term and comment metadata by owner and purpose:
- Editorial values and external identifiers.
- Object references and serialized configuration.
- Layout data and application state.
Preserve the keys needed for the agreed result, rather than every technical key by default.
Plugins can use dedicated tables when their domain does not fit core storage. Identify definitions, transactions, histories and relationships owned by:
- Forms, memberships, learning systems, events, bookings and directories.
- Redirects, analytics and integrations.
Their storage location alone does not establish an approved migration path.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Inventory business-critical metadata keys | Plugin owner and content lead | Key name, object type, data format, sample values, user-facing purpose, and referenced object type | Each retained key has a confirmed handling path and compatible agreed representation, with a destination field, plugin consumer, external owner or archive as appropriate. |
| Identify object-reference fields | Technical owner | Samples of post, attachment, user, term, and external IDs stored in metadata | References can be translated to destination objects rather than copied as obsolete numeric IDs. |
| Record serialized or structured fields | Plugin or builder owner | Schema examples, repeaters, groups, JSON/serialized payloads, and field definitions | The destination can interpret the structure, or a feasible agreed restructuring and its implementation handoff are confirmed; required unresolved handling remains held. |
| Inventory site and plugin options | Technical owner | Business-relevant options, owning plugin/theme, site scope, and whether the value is content or configuration | Configuration is not silently classified as migrated content. |
| Inventory custom tables | Plugin owner and database administrator | Table names, row counts, primary keys, parent relations, dates, statuses, and external keys | Every business-critical table has an explicit destination, retained external system, archive, or exclusion decision. |
Before excluding caches, temporary records, logs, sessions, indexes or abandoned plugin data, preserve the original inventory and decide which values remain authoritative.
For each retained field or table, record its schema, related objects and destination consumer. Use the metadata and extension model to distinguish literal values from references and application state.
If retrieval uses the WordPress REST API, qualify actual post-type and field exposure and caller permissions. A normal response does not prove that every stored key is available.
Prepare Files and Presentation Dependencies
Media preparation needs both files and references:
- Files: images, downloadable documents, externally hosted assets and reused files.
- Context: captions, alt text and attachment metadata.
- Uses: featured images, inline images and galleries.
Identify unreferenced uploads and references whose files are missing. Retain a source file or remote owner for each important asset.
Inventory the presentation owners:
- Content structures: core blocks, classic HTML, shortcodes and widgets.
- Reusable structures: synced/unsynced patterns and template parts.
- Implementation: builder metadata, theme options and custom templates.
A synced pattern shares a reference whose edits affect its uses; a copied pattern can be independent. Record the intended renderer or conversion. Identical visible text does not prove the same editing behavior.
| Preparation area | Evidence to prepare | Owner | Ready condition |
|---|---|---|---|
| Media library | File inventory, attachment records, alt text, captions, featured-image links, galleries, and external URLs | Content and media owners | Priority files are accessible and every important reference has a known source file or remote owner. |
| Core blocks and classic content | Representative content containing links, embeds, tables, reusable blocks, and complex formatting | Editorial owner | Content patterns requiring conversion or manual reconstruction are identified. |
| Shortcodes | Shortcode inventory, owning plugin/theme, example pages, and expected output | Plugin owner | Each critical shortcode has a continuing renderer or a replacement decision. |
| Page builders | Builder version, templates, global sections, field storage, theme dependency, and sample layouts | Design and technical owners | Reusable content is separated from builder-specific presentation data. |
| Themes and template parts | Active/child theme, custom templates, widget areas, template parts, and global styles | Design owner | Theme code is treated as implementation evidence rather than ordinary content. |
The final design need not be complete at this stage. Readiness requires enough ownership evidence to prevent builder data, theme code, shortcodes, and reusable content from being mixed into one undifferentiated migration scope.
Prepare Identity, Authorship and Permissions
Classify WordPress users by their intended purpose:
- Authors, editors and administrators.
- Subscribers, members and learners.
- Vendors or Customers of another application.
Core roles and capabilities govern privileges; plugins can add roles, capabilities, profiles, memberships and histories. Inventory those application relationships separately from core identity.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Classify user populations | Site administrator and business owner | Counts and samples by role, application type, active state, authorship, and account purpose | Authors, staff, members, subscribers, and application users are not merged by email alone. |
| Record custom roles and capabilities | Technical owner | Role definitions, custom capabilities, owning plugin/code, and representative users | Required roles, capabilities and their destination consumer are defined and qualified; obsolete privileges are excluded and unresolved required access remains held. |
| Link authorship and ownership | Editorial owner | High-value Posts and custom records with author/owner references | Included records have resolvable destination authors or an approved fallback owner. |
| Inventory comments and reviews | Content or community owner | Status, hierarchy, author identity, related content, spam/exclusion rules, and plugin ownership | Blog comments, discussions, testimonials, and commerce reviews remain correctly classified. |
| Identify privacy-sensitive fields | Privacy and business owners | Field inventory, consent basis, retention rule, and access requirement | Sensitive data has an approved migration, archive, redaction, or exclusion decision. |
Keep three account decisions separate:
- Qualify the actual Source-to-Target password or account path, with reset, activation or first-login handling where needed.
- For Multisite, preserve required site memberships and roles alongside network identity; historical authorship must not grant privileged access automatically.
- Assign owners for social login, SSO and membership services.
A profile inventory does not prove authentication continuity.
Plan URLs, SEO and Site Scope
Prepare the URL and redirect plan from actual Source evidence:
- Content routes: priority CMS Pages, Blog Posts and custom post types.
- Discovery and assets: taxonomy/author archives, media, feeds and plugin routes.
- Route rules: permalinks, parent hierarchy, taxonomy rewrites, domain/subdirectory scope, canonicals and existing redirects.
These are separate from the SEO values stored by a plugin.
SEO fields may be stored in core records, metadata, plugin tables, or external platforms. Inventory titles, descriptions, canonical values, social fields, structured-data inputs, indexation controls, and redirect records by owner. Do not assume a plugin export contains every route relationship.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Capture priority source URLs | SEO owner | Analytics/search-informed URL list plus current status and destination intent | Every priority route has a keep, change, consolidate, retire, or redirect decision. |
| Record permalink and rewrite logic | Technical owner | Permalink settings, custom post type and taxonomy rewrite rules, plugin endpoints, and Multisite path/domain rules | Destination route design can distinguish content records from archives and application endpoints. |
| Inventory SEO data owners | SEO and plugin owners | Metadata key/table map, export files, canonical rules, indexation rules, and sitemap sources | Each retained SEO value has a destination owner. |
| Prepare multilingual relationships | Localization owner | Languages, translation groups, locale codes, language-specific routes, and fallback rules | Translations remain connected rather than becoming unrelated duplicate content. |
| Record existing redirects | SEO or technical owner | Source, destination, status, owner, and priority | Duplicate, chained, obsolete, and still-required redirects are classified. |
Qualify relationships by their real scope:
- Identical slugs on different Multisite sites are distinct routes; include network/site ownership in SEO decisions.
- Translations need the actual plugin/application owner and intended destination interpreter.
Shared labels do not establish a translation link.
Confirm Target Interpretation and Access
Confirm the intended WordPress environment independently from Source recovery:
- Destination site/network scope and administration/implementation access.
- Runtime and deployment ownership.
- Compatible registrations, plugins, custom code and renderers for the agreed content and applications.
Source files and copied registrations do not establish that the Target can interpret or edit retained records.
Use the ownership decisions already developed for post types, taxonomies, field schemas, builders, navigation, permissions and external systems to identify the intended destination consumer. Resolve required implementation or access gaps, agree explicit exclusions, or hold the affected scope before selecting samples. Complete visual design remains a later task; required data interpretation and ownership do not.
Choose Representative Evidence
Choose representative evidence and acceptance criteria for structural diversity, not just recent or simple records. Each sample needs intended relationships, linked files, route evidence and a reviewer.
Use tests that can exercise the actual agreed output; unavailable sample capabilities need a separate evidence path. The examples below identify requirements, not automatic transfer coverage.
| Sample | Evidence to prepare | Why it belongs in the sample set |
|---|---|---|
| Hierarchical CMS Page | Parent/child route, template, blocks or builder data, media, menu use, and SEO fields | Represents Page hierarchy, presentation dependencies, and routing. |
| Blog Post with relationships | Author, categories, tags, comments, featured image, embeds, and archive routes | Represents editorial history and classification. |
| One record from every important custom post type | Taxonomies, metadata, media, public route where required, owning plugin/code and related records | Exposes plugin registration and custom schema dependencies. |
| Metadata-intensive record | Field definitions, reference IDs, repeaters, serialized values, and external IDs | Exposes whether field values can remain interpretable. |
| User with application context | Role, capabilities, authored records, profile data, and membership or other plugin relation | Represents identity without confusing core users with plugin profiles. |
| Complex media/content record | Gallery, downloadable file, reused attachment, shortcode/embed, and internal links | Represents file and content-reference dependencies. |
| Multilingual or Multisite record where applicable | Site/language ownership, translation links, routes, and shared users | Exposes site-scope and localization relationships. |
Record each sample’s evidence:
- Original ID and values, site scope and public URL where applicable.
- Record owner, related objects and files.
- Intended destination, accepted exclusions and reviewer.
- Registration and field definitions needed to interpret complex records.
Assign a test-environment owner for WP-Cron, external schedulers, queues, notifications and webhooks. Loading a clone can permit scheduled work; a restored copy is not inherently inert.
Complete the WordPress Readiness Gate
Consolidate evidence into one readiness register before execution. An open item needs an owner, decision date, and defined scope effect. Required access, registration, file, permission, relationship, or retrieval gaps must be resolved, explicitly excluded with approval, or hold the affected scope. A due date alone is not evidence of readiness.
| Readiness area | Ready condition |
|---|---|
| Scope and ownership | Every actual Source record type has an intended WordPress core, named plugin/custom application, external-system, archive or exclusion owner; Source storage is not assumed to be WordPress. |
| Access and recovery | Actual Source access or agreed inputs, dated coverage, recovery owner and limits are recorded. Complete native database/files are retained for an accessible WordPress Source; restricted or other Sources use their actual archive/retrieval contract. Required gaps are resolved, excluded by agreement, or held; exports alone do not establish a full restore. |
| Content architecture | Posts, CMS Pages, custom post types, taxonomies, menus, and lifecycle states have explicit inclusion and destination decisions. |
| Custom data | Important metadata, options, custom tables, object references and external identifiers have known schemas, qualified handling and intended consumers; required gaps are resolved, excluded by agreement or held. |
| Media and presentation | Priority files are available; builder, block, shortcode, theme, and template dependencies are classified. |
| Users and privacy | Roles, authorship, application profiles, comments, authentication dependencies, and sensitive fields are classified. |
| URLs and SEO | Priority routes, permalink logic, redirects, language/site scope, and SEO data owners are documented. |
| Target implementation | Destination site/network scope, administration/implementation access, runtime/deployment owner and compatible registrations, schemas, plugins or renderers are confirmed for the agreed requirements. Required gaps are resolved, excluded by agreement, or held; complete visual design is not required. |
| Samples | The sample ledger represents every material WordPress content and application pattern in scope. |
The WordPress scope is ready when selected records, related data, target representations, responsible owners and supporting Source evidence are understood, and required access, interpretation or relationship gaps are resolved or excluded by agreement. A remaining required gap holds the affected scope.
Conclusion
WordPress preparation establishes what retained records mean, how the actual Source can supply recoverable evidence, and what the independent Target must interpret. Accessible WordPress database/files and another or restricted Source’s archive limits remain different recovery contracts.
A usable preparation package separates CMS from application scope, preserves source evidence and selects representative samples. Each retained requirement has a destination, external owner, archive or agreed exclusion; required gaps remain held.
Carry accepted recovery limits and Target prerequisites into WordPress validation, where delivered outcomes receive their own evidence.
Common Questions
What should be prepared first for a WordPress migration?
Define the role of the Target WordPress site and classify the source record owners. This establishes whether each record belongs to WordPress core, a plugin or custom application, an external system, an archive, or an intentional exclusion before detailed field work begins.
Is the WordPress export file a complete migration backup?
No. The built-in export can provide useful content evidence, but a recoverable source normally also requires the database, media and other wp-content files, environment details, and plugin-specific or external records that the export does not represent.
That native database-and-file recovery requirement applies to an actual WordPress Source with the relevant access. Another or restricted Source needs its own permitted retrieval path, available archives and original media, coverage, limits and recovery owner.
Exports alone do not establish a full installation restore; required gaps need resolution, an agreed exclusion, or a hold.
Why must custom post types and taxonomies be inventoried separately?
They can share WordPress storage while using different registrations, capabilities, editors, metadata, archives, templates, and plugin owners. Preserving only titles and body content would not preserve the structure that makes those records manageable.
How should custom fields and metadata be prepared?
Prepare three groups:
- Meaning: metadata owner, object type, value format and field definition.
- Relationships: referenced objects and representative samples.
- Destination: intended representation and consumer.
Distinguish literal values from references. Translate object IDs and referenced schemas where needed; a numeric value or serialized field is not automatically an obsolete object reference.
Should plugins and themes be treated as migrated content?
Not automatically. Plugins and themes are implementation dependencies. Their business-critical records, settings, custom tables, shortcodes, templates, and external links need explicit ownership decisions, while temporary or obsolete technical data can be excluded.
How is WordPress preparation different from WooCommerce preparation?
WordPress preparation owns CMS Posts, CMS Pages, custom post types, taxonomies, metadata, media, users, menus, routes, and plugin application boundaries.
WooCommerce preparation separately owns Products, variations, Customers, Orders, coupons, commerce reviews, HPOS, checkout metadata, and commerce extensions.
Can records remain important when their custom post type is no longer visible?
Yes. Deactivated or changed registration code can leave stored records without their former editor or routes. Inventory those records with their owning code, fields, relationships, and intended destination interpreter. Do not assume that an export contains them or that reusing their type name restores their application behavior.
Should classic menus and Navigation blocks be prepared as one export?
Prepare their actual records and references separately, then relate them to the same intended navigation where appropriate. Classic menu items and Navigation block records can point to content while using different storage and presentation dependencies. Preserve links, site scope, placement, and the owner of the destination representation.
Does preserving a Multisite user also preserve access to every site?
No. Network identity and site membership or role are separate. Prepare the selected site assignments, required capabilities, authorship, and account access path, including any reset or external identity dependency. The destination access owner must decide what privileges continue; a shared user row does not decide them.