WordPress.com → WordPress
Move editorial records from a hosted WordPress.com site into a prepared self-hosted WordPress installation while separating portable content from subscriptions, followers, likes, stats, WordAds, domains, themes, and platform services.
Self-service migration path
This pair is not currently listed as a fully supported self-service direction. wordpress-com: In development. wordpress: Available. Review system status and directions. Available migration objects and capabilities depend on the selected source and target systems.
Create an account, connect a staging destination, and let the app analyze the supported scope for this direction.
No credit card required to analyze the migration and run a free sample.
Scope
The app confirms available entities after connection. Final coverage depends on source access, downloadable assets, and the destination model you prepare.
Before you connect
Use a staging destination and the least-privilege access supported by each platform. Do not send credentials through a public form.
Provide the site ID or hostname and an OAuth token with the least privileges needed for approved posts, users, taxonomy, comments, and media.
List posts, pages, authors, media, comments, followers, subscriptions, domains, email, payments, plugins, and features that must remain outside content scope.
Prepare hosting, WordPress, HTTPS, post types, taxonomies, users, media limits, SEO plugin, permalinks, backups, and Application Password or Bridge access.
How it works
You control each stage in the app. Optional expert assistance is available for custom data or destination requirements.
Start in the app and select the real source and target.
Authorize read access to WordPress.com and connect a prepared staging WordPress destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported WordPress.com data belongs in the prepared WordPress model.
Move a small set of real records to staging and inspect the result before purchasing the full migration.
Review counts, records, media, links, warnings, and exceptions, then purchase and start the full migration when ready.
Technical detail
Open only the detail you need for planning, mapping, or validation.
WordPress.com is stable and enabled in both directions in the capability snapshot. The current content source reads the WordPress.com posts endpoint; other site objects require explicit adapter or export review.
The app exposes configured authors, taxonomy, posts, comments, and media through authenticated WordPress.com API access. Posts are the verified standard content path.
Authenticated REST and Bridge adapters load approved records into a prepared installation without assuming that hosted-platform services transfer.
The CMS concepts are related, but WordPress.com platform services are not ordinary WordPress database records.
| WordPress.com source | Self-hosted WordPress target | Status and boundary |
|---|---|---|
| Posts | WordPress posts | Standard: the current adapter reads the posts endpoint and preserves source identity. |
| Pages | WordPress pages | Review: the public API supports pages, but the configured app content path is post-focused and must be verified. |
| Authors | WordPress users and authorship | Standard with identity review: profiles can map; WordPress.com credentials do not transfer. |
| Categories and tags | Categories, tags, or custom taxonomies | Standard: terms load before post relationships. |
| Comments and parent threads | WordPress comments | Standard with validation: post and parent IDs must resolve before acceptance. |
| Media library and inline images | WordPress media | Standard with file validation: download originals, upload, and rewrite references. |
| Rendered blocks, embeds, and shortcodes | Blocks, embeds, or transformed HTML | Review: portability depends on destination support and plugin availability. |
| Hosted URLs and custom domain | Self-hosted permalinks and redirects | Delivery artifact: domain, DNS, paths, and redirect control are planned explicitly. |
| Followers, subscribers, likes, Reader, and notifications | Newsletter, CRM, or membership system | Custom/restricted: not standard content entities in this pair. |
| Stats, WordAds, payments, and platform services | Analytics, ads, payments, or plugins | Reconfigure: history and service behavior do not migrate with posts. |
| Theme, widgets, forms, and site settings | Theme, blocks, plugins, and configuration | Rebuild/reconfigure: not assumed to transfer as content. |
The mapping preserves editorial identity while treating hosting, accounts, and platform services as separate workstreams.
| WordPress.com value | Migration rule | Self-hosted result |
|---|---|---|
| Post ID | Preserve as source identity | Stable destination lookup and rerun key |
| title.rendered and content.rendered | Normalize supported markup and dependencies | Post title and body |
| author ID | Match or create an approved user | Destination authorship |
| category/tag IDs | Create terms first and resolve IDs | Taxonomy relationships |
| comment post and parent IDs | Resolve after posts and parent comments exist | Threaded WordPress comments |
| attachment URL and MIME | Download, validate, upload, and rewrite | Owned destination media |
| source URL and slug | Approve final permalink and redirect entry | Canonical destination URL |
A hosted site bundles CMS records with account, audience, monetization, and infrastructure services.
Count posts, pages, authors, taxonomy, comments, media, states, blocks, embeds, and URLs.
List followers, email subscribers, likes, stats, WordAds, payments, domains, email, backups, and plan-specific features.
Assign each hosted service to a self-hosted plugin, external provider, export, retained service, or documented exclusion.
Create destination users under an approved identity policy; do not promise WordPress.com password portability.
The content may be familiar, but the hosting boundary changes DNS, redirects, caches, files, email, and operational ownership.
Capture post/page URLs, media, taxonomy archives, feeds, canonicals, pagination, and priority backlinks.
Set permalink, taxonomy, trailing-slash, collision, and canonical rules before the final migration.
Plan DNS, TLS, CDN, caching, backups, email, redirects, analytics, and rollback ownership.
Test redirects, files, feeds, sitemap, robots, canonicals, analytics, forms, and high-value landing pages.
A successful post import does not prove that hosted-platform functionality has been replaced.
Compare posts, authors, terms, comments, media, loaded, skipped, failed, and state totals.
Check blocks, embeds, shortcodes, galleries, comments, files, scheduled content, and mobile layouts.
Verify newsletter, forms, analytics, memberships, ads, payments, backups, and security only where included.
Record followers, likes, historical stats, platform features, or account data that cannot or should not transfer.
Before purchase
The free sample migration creates a limited set of records in staging. Check fields, relationships, media, URLs, rendering, and reported exceptions before paying for the full run.
Pricing
Package fit depends on supported record volume and complexity. Analyze the source first, then review the fixed package or dynamic estimate shown for the migration.
Compare migration packagesPlan the move
Review destination content types, users, taxonomy, media, SEO, and access.
Open guide →Understand the self-service migration scope and delivery boundaries.
Open guide →See package limits, exclusions, and fixed-scope factors.
Open guide →Connect access, mapping, dry runs, cutover, and stabilization to delivery time.
Open guide →Clear answers
They share WordPress concepts, but hosting control, plugins, themes, accounts, platform services, and operational responsibility differ.
Yes when API access and source files are available. Preserve relationships and validate every accepted file.
They require source-path verification because the current app adapter is optimized for the WordPress.com posts endpoint.
Not as standard content. They require an approved newsletter or CRM destination, consent review, and accessible export path.
No. Destination accounts follow a controlled creation, invitation, or password-reset process.
No. The self-hosted theme, templates, widgets, plugins, and forms are prepared separately.
Usually yes, but DNS, TLS, email, redirects, and launch ownership must be coordinated and tested.
Next step
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.
