Umbraco → WordPress
Translate Umbraco document types and property-editor values into a prepared WordPress content model using the Delivery API or approved source access, while separating members, templates, compositions, and custom .NET behavior from portable content.
Self-service migration path
This pair is not currently listed as a fully supported self-service direction. umbraco: Beta. 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.
Enable the Umbraco Content Delivery API and provide the site URL. Supply the API key only when public access is disabled or preview data is explicitly in scope.
Provide a least-privilege client ID and secret only if document types, media, users, members, redirects, or unpublished records require Management API coverage.
Prepare post types, taxonomies, fields/blocks, users, media, multilingual and SEO plugins, permalinks, and authenticated destination 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 Umbraco and connect a prepared staging WordPress destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported Umbraco 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.
Umbraco is beta and source-only in the site snapshot. The current app has a dedicated Delivery API source adapter, integration coverage, and an Umbraco-to-WordPress E2E scenario for Umbraco 13 fixtures.
Published content is read primarily through /umbraco/delivery/api/v2. An API key can unlock protected API access; optional Management API credentials are reviewed only where backoffice data is required.
Document types and properties are routed into a prepared WordPress model after hierarchy, property-editor, media, culture, and URL rules are approved.
Standard covers published Delivery API content. Property editors, backoffice records, protected content, and application behavior require explicit review.
| Umbraco source | WordPress target | Status and boundary |
|---|---|---|
| Published content items | Pages, posts, or prepared custom post types | Standard with modeling: route each contentType alias to an approved destination type. |
| Document type aliases and properties | Post types, fields, taxonomies, or blocks | Review: property editor and value shape determine the transformation. |
| Content tree hierarchy and routes | Page parents and permalinks | Standard with URL review: preserve parent context while approving final paths. |
| Block List, Block Grid, Nested Content, and compositions | Blocks, repeaters, child records, or fields | Review/custom: nested values and rendering need schema-specific transformation. |
| Cultures and variants | Configured multilingual model | Review: use culture, route, translation group, and fallback rules. |
| Media library items and pickers | WordPress media and references | Review: expand media values, download originals, upload, and rewrite. |
| Backoffice users used as authors | WordPress authors | Review: Delivery API may not expose full author profiles; Management access can be required. |
| Tags and category-like document types | Taxonomies | Review: Umbraco has no universal taxonomy model, so each source schema is inspected. |
| Draft and preview content | WordPress draft/private state | Review: requires configured preview access and an explicit retention policy. |
| Members and protected content | Membership or access-control solution | Separate security scope: profiles do not reproduce authentication or protection rules. |
| Templates, Razor views, controllers, packages, and forms | Theme, plugins, forms, or applications | Rebuild: .NET behavior does not transfer as JSON content. |
The mapping contract is organized by content type and property editor, not by field names alone.
| Umbraco value | Migration rule | WordPress result |
|---|---|---|
| Content GUID and id | Preserve stable identity and source route | Destination ID map and rerun lookup |
| contentType alias | Route through the approved type matrix | Page, post, or custom post type |
| name and route.path | Map title and approve destination slug hierarchy | Title, permalink, and URL-map entry |
| properties by alias | Transform according to property editor and value shape | Core field, post meta, ACF, block, or taxonomy |
| Block List/Grid JSON | Resolve element types, order, nested values, and references | Blocks, repeaters, or child records |
| Media picker value | Expand media, download, validate, upload, and resolve ID | WordPress media reference |
| cultures and Accept-Language variant | Group translations and map locale | Multilingual destination relationship |
| createDate/updateDate and state | Normalize timestamps and approved visibility | WordPress dates and status |
Two Umbraco fields with similar labels can return entirely different JSON depending on their property editors.
Capture aliases, compositions, properties, data types, allowed children, cultures, variations, and content counts.
Sample text, rich text, links, pickers, media, blocks, grids, nested content, repeaters, and custom editors.
Approve post types, taxonomies, fields, blocks, relationships, authors, and fallback handling before loading.
Create authors, taxonomies, media, and reusable referenced records before dependent documents resolve IDs.
Published delivery content and backoffice management data have different access and risk profiles.
Read published JSON, routes, cultures, properties, hierarchy, and expanded references through the least-privilege source.
Use an API key for draft or restricted Delivery API access only when those records are approved scope.
Request OAuth credentials only for required document type, media, user, member, redirect, or unpublished-data gaps.
Treat member profiles, passwords, groups, protected routes, and authentication as a distinct security workstream.
Acceptance must cover the rendered result of transformed property data, not only source JSON counts.
Compare source, extracted, transformed, loaded, skipped, failed, published, draft, and culture totals.
Review blocks, grids, pickers, compositions, media, links, variants, dates, and custom-editor fallbacks.
Test source routes, language paths, redirects, canonicals, sitemap entries, internal links, and media URLs.
Validate source-to-target IDs, relationship resolution, reruns, documented exceptions, cutover checks, and monitoring.
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 Delivery API access, document types, property editors, cultures, media, and members.
Open guide →Review WordPress destination modeling, users, taxonomies, media, SEO, and custom fields.
Open guide →Understand the broader self-service migration scope and delivery boundaries.
Open guide →See package limits, estimate factors, exclusions, and fixed-scope rules.
Open guide →Clear answers
The current app uses the v2 Content Delivery API and has an Umbraco 13 E2E fixture. Other versions are accepted only after endpoint and property-shape verification.
Yes for the standard source path. Public access or an API key must expose the approved content.
Yes after element types, nested properties, ordering, references, and destination blocks or fields are mapped.
Yes when cultures and variants are accessible and the WordPress multilingual model, translated paths, and fallbacks are prepared.
Accessible media values and originals can be expanded, downloaded, validated, uploaded, and rewritten.
Not as standard content. Members, passwords, groups, protected routes, and authentication require a separate security and destination design.
No. Views, controllers, packages, forms, integrations, and custom application behavior require WordPress-native redevelopment.
Next step
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.
