Editorial content
Posts, pages, comments, excerpts, publication state, dates, authors, slugs and parent relationships exposed by the chosen connection. Custom post types require access and mapping review.
Available migration objects and capabilities depend on the selected source and target systems. Check current integration status before using this planning guide.
What the migration covers
WordPress can be the source or destination. Check authenticated REST access or a compatible Bridge against the records you need to move. Standard posts and pages are the starting point; custom post types, fields and plugin-owned records need a closer look before they enter the quote.
Content model
Categories, tags, menus, menu items, supported metadata, attachments, and source identifiers used for reconciliation.
Media and authorship
Media attachments and author relationships. Full user profiles, roles, memberships, and authentication remain review items.
SEO and URLs
SEO titles, descriptions, canonicals, source URLs, internal links, media references, redirect rules, and crawl checks.
What requires separate scope
A content migration does not automatically recreate the active theme, templates, plugins, forms, checkout, memberships, search, page-builder behavior, custom PHP, or third-party integrations. Those elements are inventoried and assigned to migration, configuration, redevelopment, or exclusion before implementation.
What we check in your WordPress setup
A public article can read perfectly while its source contains a shortcode, an image on another host or fields maintained by a plugin. Those details decide which connection and transformations the move needs.
Migration direction
WordPress is enabled as both a source and a destination in the app platform registry.
Connection methods
Authenticated WordPress REST API v2 using an Application Password. Bridge adapters covering WordPress 1.0 through 6.0+.
Content sample
A recent post, an older article, a page with embedded media and any custom content type that matters to the new site.
Destination check
Confirm that the transferred values are editable and appear correctly in the new templates, including dates, authors and links.
Moving content into WordPress
A news article can become a post. A staff profile may need a prepared post type and a department field. Agree those choices with the person building the WordPress site before the first load.
Model the destination first
Define posts, pages, custom post types, taxonomies, fields, relationships, authors, and media behavior before loading source records.
Choose the extraction path
Use available source exports and APIs for standard entities, then add structured extraction or custom adapters only where the source model requires them.
Transform explicitly
Normalize dates, rich text, categories, references, filenames, publication state, and identifiers according to approved mapping rules.
Keep development separate
Treat theme, block, template, plugin, commerce, membership, and application work as a coordinated destination workstream rather than hidden migration scope.
Moving content out of WordPress
A shortcode such as [team_directory] depends on code running in WordPress. Copying it into another CMS will not recreate the directory. Decide whether it becomes ordinary content, structured fields or a feature to rebuild.
Inventory beyond posts and pages
Review registered post types, taxonomies, metadata, menus, authors, attachments, comments, options, and plugin-owned tables.
Resolve blocks and shortcodes
Determine whether block markup, embedded shortcodes, page-builder structures, and reusable blocks become clean content, transformed fields, or reconstruction scope.
Map destination limits
Check field types, references, collection limits, localization, permissions, and media behavior before transforming WordPress records.
Preserve traceability
Retain stable source identifiers in the migration dataset so rejected records, relationships, and later delta changes can be reconciled.
WordPress-specific migration risks
The difficult part is rarely copying the visible article body. Risk usually sits in plugin ownership, relationships, URL behavior, authentication, and assumptions embedded in the old rendering stack.
Plugin and serialized data
Plugin fields and serialized values need schema-aware review. Blind text replacement or generic export can corrupt structured values or omit business-critical records.
Users and authentication
Profiles, roles, authorship, memberships, and private content need separate rules. Password hashes are portable only when the destination authentication model is compatible.
URLs and internal references
Permalinks, attachment URLs, embedded links, canonicals, and redirects require an approved old-to-new inventory rather than a blanket replacement.
Multisite and multilingual content
Networks and translation plugins introduce per-site tables, shared users, domain rules, language relationships, and plugin-specific records that change scope.
What changes timeline and price
The assessment connects the advertised package to the real WordPress model. Record count matters, but model complexity and access quality usually determine the amount of custom work.
Volume and assets
Primary records, revisions, comments, users, files, remote media, archive depth, and upload size affect extraction and validation time.
Model complexity
Custom post types, fields, relationships, multilingual associations, commerce, memberships, and plugin tables increase mapping work.
Access and consistency
Restricted APIs, incomplete exports, broken media, duplicate identifiers, inconsistent markup, and legacy character encoding create exceptions.
Cutover requirements
Content activity, freeze windows, delta migration, DNS or application changes, rollback conditions, and launch support shape the delivery plan.
How the workflow works
- 1. Discover: Inventory WordPress core entities, registered content types, metadata, users, media, URLs, plugins, access methods, volume, and destination readiness.
- 2. Map: Approve destination types, fields, taxonomies, relationships, transformations, URL rules, exclusions, and acceptance criteria.
- 3. Dry run: Transfer representative standard and complex records into staging without changing the production source.
- 4. Validate: Reconcile totals and inspect content, metadata, authorship, media, relationships, links, redirects, rendering, and documented exceptions.
- 5. Cut over: Execute the approved production or delta plan, run launch checks, and monitor agreed post-launch signals.
Technical references
Scope is reviewed against the source and destination documentation available for the project.