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.
WordPress preparation begins by identifying what the site actually is. The same WordPress installation can be a publication, documentation site, marketing site, membership environment, directory, learning platform, event system, or the CMS around a WooCommerce Store. Core Posts and CMS Pages may represent only part of the operational content. Custom post types, taxonomies, metadata, media relationships, users, plugin tables, blocks, builder layouts, redirects, and external identifiers can determine whether the migrated site remains editable and understandable.
Produce evidence for the actual Source and decisions for the intended WordPress implementation. Every important record class needs an owner, a retrieval path or inventory, a representative sample, and a ready condition. When the Source is WordPress, preserve its installed registrations and storage context. When it is another platform, classify equivalent source records without assuming a WordPress schema. Keep CMS content separate from WooCommerce and other plugin-owned application data.
Confirm the WordPress Scope and Record Owners
Classify actual Source records and their intended owners: WordPress core, named plugins or custom code, retained external systems, archives, or deliberate exclusions. For a WordPress Source, this prevents every database row from being treated as ordinary content. For another Source, record its own structures and evidence before choosing their WordPress representation.
WordPress can store several post types in the posts infrastructure, but active registration governs their administration, capabilities, templates, archives, and API behavior. Inventory stored types even if their owning plugin or code is inactive. Custom taxonomies need their definitions and object relationships; metadata needs the component that interprets its keys and values. A stored record is not proof that the intended destination can expose or edit it.
| 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. Network users and site memberships are separate evidence: a shared user does not automatically have a role on every site. Posts, CMS Pages, terms, options, and many plugin records remain site-specific. Record who can inspect network-wide dependencies as well as local content; site administration access does not imply unrestricted network access.
Secure Source Access, Backups, and Environment Evidence
When the Source is WordPress, recoverable evidence can span the database, uploads, plugin and theme files, language files, remote media, and external services. For another Source, secure the equivalent source artifacts and retrieval access. Record intended WordPress administration and implementation access separately; source backup coverage and destination access are different readiness conditions. For an accessible native WordPress Source, preserve complete database and relevant file evidence from the same state. Another or restricted Source needs its actual connection/export contract, available originals, recovery coverage, limitations and owner; content exports alone do not establish full installation restoration. Required omissions need resolution, an 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. |
Treat the built-in WXR export as content evidence, with its selected filters and export-enabled post types recorded. It is not a complete site backup and does not automatically represent plugin tables, site options, theme code, media files, or external records. A database inventory may therefore contain relevant records absent from the export. Preserve a protected original recovery package before approved cleanup, with timestamp, retrieval location, restoration owner, and retention. This WXR qualification concerns a WordPress Source. Another Source uses its own available archives and retrieval evidence; neither its export nor WXR alone proves that every required record, file or implementation dependency is recoverable.
Inventory Posts, CMS Pages, Custom Post Types, and Lifecycle States
List every stored post type in scope, including types whose registration is currently inactive, rather than relying on visible administration screens alone. Include standard Posts and CMS Pages, attachments, revisions when retained, and each registered custom post type. For each type, document its business purpose, record count, public or private status, editor features, parent relationships, authorship, dates, archive behavior, and responsible plugin or codebase.
| 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 active type has a 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.
Prepare Taxonomies, Terms, Menus, and Archive Relationships
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. |
Freeze original term, menu, and content IDs before approved cleanup. Resolve similar labels within their taxonomy and site context instead of merging by name. Classic menus and Navigation block records are distinct representations; preserve the content links and template or block references that use them. Referenced objects need destination identities, not copied installation-specific numbers.
Map Metadata, Custom Fields, Options, and Plugin Tables
Metadata can be a simple editorial value, an object reference, serialized configuration, layout data, an external identifier, or application state. Build a key inventory for important post meta, user meta, term meta, and comment meta. Group keys by owner and purpose rather than attempting to preserve every technical key.
Plugins may also create dedicated tables when their domain does not fit WordPress core structures. Forms, memberships, learning systems, events, bookings, directories, redirects, analytics, and integrations often use custom tables for definitions, transactions, histories, or relationships.
| 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 destination field, plugin owner, or external owner. |
| 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 restructuring decision is recorded. |
| 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. |
Classify caches, temporary records, logs, sessions, indexes, and abandoned plugin data by whether they remain authoritative. Preserve the original inventory before exclusion. For each retained field or custom table, record its schema, related objects, and destination consumer. If the chosen retrieval path uses the WordPress REST API, establish the actual post-type and field exposure and permission context; a normal response does not prove that every stored metadata key is available.
Prepare Media, Blocks, Builders, Themes, and Embedded Content
Media preparation must preserve both files and references. Record featured images, inline images, galleries, downloadable documents, externally hosted assets, captions, alt text, attachment metadata, and reused files. Identify files that exist in the uploads directory but are no longer referenced, and references whose files are missing.
Inventory presentation as well as reusable content: core blocks, classic HTML, shortcodes, widgets, synced and unsynced patterns, template parts, builder metadata, theme options, and custom templates can have different owners. A synced pattern carries a shared reference whose edits affect its uses; a copied pattern can be independent. Record the intended destination renderer or conversion decision instead of assuming that the same visible text preserves its 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 Users, Roles, Authors, Comments, and Privacy-Sensitive Records
WordPress users can be authors, editors, administrators, subscribers, members, learners, vendors, or Customers of another application. Core roles and capabilities define privileges, while plugins can add roles, capabilities, profiles, memberships, and histories. Inventory the role and application relationship separately.
| 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 access behavior has a destination owner; obsolete privileges are excluded. |
| 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. |
Document account profiles separately from password verification and external authentication. Confirm the supported Source-to-Target account path and prepare reset, activation, or first-login handling where needed. For Multisite, retain user identity alongside each required site membership and role; historical authorship should not automatically grant privileged access. Social login, SSO, and membership services need separate owners.
Prepare URLs, SEO Metadata, Redirects, Languages, and Multisite Scope
Create a source URL inventory for high-value CMS Pages, Blog Posts, custom post types, taxonomy archives, author archives, media, feeds, and plugin routes. Record the permalink structure, parent hierarchy, taxonomy rewrite rules, domain/subdirectory scope, canonical URLs, and existing redirects.
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. |
Include network/site ownership in every Multisite route and SEO decision. Identical slugs on different sites are distinct routes. Translation relationships also need the actual plugin or application owner and the intended destination interpreter; shared labels do not establish a translation link.
Confirm the Intended WordPress Environment and Record Interpreters
Confirm the intended WordPress environment independently from Source recovery. Record destination site or network scope, administration and implementation access, runtime/deployment owner, and the compatible registrations, plugins, custom code or renderers needed for the agreed content and application requirements. Source files and copied registrations do not by themselves establish that the destination can interpret or edit the 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.
Select Representative Migration Test Samples
Representative migration sample selection should represent the site’s structural diversity rather than only recent or simple records. Each sample should state the intended content relationships, linked files, route evidence, and responsible reviewer.
| 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, owner plugin, 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. |
Each sample ledger entry should include the original ID and values, site scope, public URL where applicable, record owner, related objects and files, intended destination representation, accepted exclusions, and reviewer. Include the registration and field definitions needed to interpret complex samples. Also prepare a test-environment owner for WP-Cron, external schedulers, queues, notifications, and webhooks: loading a clone can permit scheduled work, so a restored copy is not inherently inert.
Complete the Final 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 and owners. |
| 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 the migration team can identify what each selected record is, where its related data lives, who owns its target representation, and which source evidence supports that decision.
Conclusion
WordPress preparation is an ownership exercise across content, classification, metadata, media, identity, presentation, plugins, custom tables, routes, and external systems. For an accessible WordPress Source, complete database-and-file recovery and the required administration access remain necessary, but they do not explain custom post types, taxonomy relationships, builder structures, application profiles, Multisite scope, or plugin-owned records. Another or restricted Source needs its actual access/archive coverage, limitations and recovery owner, without claiming full installation restoration from exports.
A strong preparation package makes those relationships explicit. It separates WordPress CMS data from WooCommerce or other application domains, preserves recoverable source evidence, selects representative samples, and resolves every important record into a destination, retained external owner, archive, or intentional exclusion before migration execution begins. Carry the accepted Source recovery limits, independent WordPress implementation prerequisites, and any held scope into that decision.
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?
Record the metadata owner, object type, value format, field definition, referenced objects, representative samples, and intended destination. Numeric IDs and serialized values should not be copied without translating the records or schemas they 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.