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.
Preparation should produce source evidence, not assumptions. Every important record class needs an owner, an export or inventory, a representative sample, and a ready condition. WordPress core content should remain separate from plugin-owned application data, and WordPress CMS preparation should remain separate from WooCommerce Product, Customer, and Order preparation.
Confirm the WordPress Scope and Record Owners
First define which source records belong to WordPress core, which belong to plugins or custom code, which remain in external systems, and which are intentionally excluded. This boundary prevents a migration from treating every row in the WordPress database as ordinary content.
WordPress stores several post types in the posts infrastructure, but the post type still determines editorial purpose, administration, templates, capabilities, archives, and API behavior. Custom taxonomies also need their registrations and object relationships; metadata needs the plugin, theme, or code that interprets its keys and values.
| 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, the site or blog identifier is part of record ownership. Users may participate across the network while Posts, CMS Pages, terms, options, and many plugin records remain site-specific. The preparation package must preserve that scope instead of combining records by title or numeric ID.
Secure Source Access, Backups, and Environment Evidence
A WordPress migration requires more than an administrator login. Content may be distributed across the database, uploads directory, plugin directories, theme files, language files, object storage, remote media, and external services. Access preparation should make the source recoverable and allow the team to interpret custom structures.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm WordPress administration access | Site administrator | Working administrator account and list of restricted administration areas | Required Posts, Pages, users, media, plugins, themes, menus, and settings can be inventoried. |
| Create a complete source backup | Hosting or technical owner | Dated database backup plus wp-content files, uploads, themes, plugins, and configuration references where available |
Backup location, date, restoration owner, and retention period are recorded. |
| Capture environment details | Technical owner | WordPress version, PHP version, database version, active theme, child theme, active plugins, must-use plugins, and relevant server services | The source environment can be reconstructed sufficiently to understand content and plugin ownership. |
| Record scheduled and background processes | Plugin or integration owner | WP-Cron events, external schedulers, queues, webhook endpoints, and batch processes that create or update records | Automated writers are known and will not be mistaken for static migrated content. |
| Preserve export evidence | Content and technical owners | WordPress export files where useful, database/table inventories, media file lists, and plugin-specific exports | Each selected data area has a recoverable source artifact or documented retrieval path. |
The built-in WordPress exporter can provide useful content evidence, but it is not a complete site backup and does not automatically represent every plugin table, option, media file, theme dependency, or external record. The preparation package should therefore distinguish content exports from full recovery evidence.
Inventory Posts, CMS Pages, Custom Post Types, and Lifecycle States
List every post type that contains records, not only the types visible in the main administration menu. 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 menu trees with 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. |
Term IDs and menu-item IDs are installation-specific. When metadata or builder records reference those IDs, the preparation evidence should identify the referenced taxonomy, term, menu, or content object, not only the original number.
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. |
Technical caches, temporary records, logs, sessions, generated indexes, and abandoned plugin data should not be included merely because they exist. Their exclusion should be recorded so that a later database comparison does not treat intentional cleanup as missing content.
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.
Content presentation can be stored as core blocks, classic-editor HTML, shortcodes, widgets, reusable blocks, patterns, template parts, page-builder metadata, theme options, or custom templates. The target WordPress implementation may not use the same builder or theme, so preparation should separate reusable content from source-specific layout data.
| 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 WordPress article does not require the final design to be complete. It does require 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. |
Source password hashes and external authentication identities should be documented separately from basic user profiles. A user record can be in scope even when the original authentication credential is not portable.
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. |
For Multisite, include the network/site relationship in URL evidence. Identical slugs on different sites are distinct routes and should not be merged without an explicit content decision.
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. |
A sample ledger should include the source ID, public URL where applicable, record owner, related objects, reason for selection, and any unresolved dependency. Simple records can confirm the baseline, but complex records reveal whether the scope evidence is complete.
Complete the Final WordPress Readiness Gate
Before execution, consolidate the preparation evidence into one readiness register. An unresolved item can remain open only when it has an owner, a decision date, and a defined effect on scope.
| Readiness area | Ready condition |
|---|---|
| Scope and ownership | Every selected record type belongs to WordPress core, a named plugin/custom application, an external system, an archive, or an intentional exclusion. |
| Access and recovery | Administrator access, database backup, file backup, environment inventory, and restoration ownership are recorded. |
| 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. |
| 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. A complete backup and administrator login are necessary, but they do not explain custom post types, taxonomy relationships, builder structures, application profiles, Multisite scope, or plugin-owned records.
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.
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.
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.