Concrete5 → WordPress
Translate Concrete page versions, areas, blocks, attributes, and file references into a prepared WordPress model with version-aware Bridge extraction while separating reusable content from themes, templates, packages, workflows, and block controllers.
Self-service migration path
Source and target connectors are available. concrete5: Available. 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 a safe clone or staging instance, database access for the compatible Bridge, Concrete version, table naming, file storage, and temporary credentials.
List sitemap hierarchy, Page Types, Templates, Areas, block types, Stacks, Global Areas, attributes, files, languages, packages, Express objects, forms, users, and workflows.
Prepare post types, fields/blocks, taxonomy, users, comments, media, multilingual and SEO plugins, permalinks, and authenticated 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 Concrete5 and connect a prepared staging WordPress destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported Concrete5 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.
Concrete5 is stable and source-only in the snapshot. The current app has Bridge adapters for 5.4, 5.7, and 8+ plus integration and unit coverage for pages, blocks, paths, tags, metadata, files, users, and comments.
The content adapters resolve page records, approved versions, canonical PagePaths, Page Types, text/image blocks, tags, and metadata with version-specific schema handling.
Approved pages and relationships load into a prepared model after block, Area, attribute, media, hierarchy, and URL rules are defined.
Standard covers configured Bridge records. A page assembled from Areas and Blocks still needs an explicit WordPress composition rule.
| Concrete source | WordPress target | Status and boundary |
|---|---|---|
| Pages and approved versions | Pages, posts, or custom post types | Standard with modeling: Page Type and purpose determine destination routing. |
| Sitemap hierarchy and canonical PagePaths | Page parents and permalinks | Standard: preserve parents while approving final destination paths. |
| Text and image Blocks | Gutenberg blocks, fields, or body content | Standard/review: configured adapters extract common block values and file references. |
| Custom Blocks and block tables | Custom blocks, repeaters, fields, or child records | Custom: controller schema and rendering need block-specific transformation. |
| Areas, layouts, and containers | Block order and page composition | Review: preserve meaningful order; visual grid behavior requires destination implementation. |
| Page, user, and file attributes | Core fields, post meta, taxonomy, or media metadata | Review: each attribute type returns a different native value shape. |
| Users used as owners/authors | WordPress authors | Standard with identity review: authorship can map; passwords and groups do not transfer automatically. |
| Comments | WordPress comments | Standard when configured: resolve destination page and author/thread relationships. |
| Files, file versions, and storage locations | WordPress media | Review: locate originals, validate, upload, and rewrite all accepted usages. |
| Stacks and Global Areas | Patterns, reusable blocks, template parts, or duplicated content | Review/custom: choose reusable destination semantics instead of flattening blindly. |
| Themes, Templates, packages, workflows, forms, and Express | Theme, plugins, forms, or applications | Rebuild/custom: behavior does not transfer as Page records. |
The mapping contract joins Page, version, path, Area, Block, attribute, and file records before creating destination content.
| Concrete value | Migration rule | WordPress result |
|---|---|---|
| cID and parent cID | Preserve identity and resolve hierarchy | Destination ID and parent |
| cvName, cvDescription, approval state | Select approved version and normalize editorial fields | Title, excerpt/body, and status |
| Page Type handle | Route through destination type matrix | Page, post, or custom post type |
| Area and block order | Assemble supported blocks in approved sequence | Gutenberg blocks or body structure |
| Block type and custom table values | Apply block-specific transformation | Block, field group, media, relation, or exclusion |
| Attribute handle/type/value | Normalize by attribute controller type | Post meta, taxonomy, SEO field, or relationship |
| file ID/version/path | Resolve original, validate, upload, and rewrite | WordPress media reference |
| canonical PagePath | Approve final permalink and URL-map entry | Destination URL plus redirect |
Concrete stores pages, versions, Areas, Blocks, and block-specific values separately.
Count block types by Page Type, Area, template, version, language, and package ownership.
Translate content, image, file, video, page list, and supported core blocks into destination-native structures.
Profile each custom block table, controller, relationships, and rendering before choosing blocks, fields, or child records.
Map Stacks and Global Areas to patterns, reusable blocks, template parts, intentional duplication, or rebuild scope.
Concrete page and file containers can have multiple versions, paths, attributes, and storage locations.
Use approved/current versions according to the scope and document any historical version retention.
Use canonical PagePaths plus the live crawl; do not infer public URLs from page names alone.
Follow file container, version, storage location, metadata, and Block/attribute usages before transfer.
Confirm image, file, rich-text, block, and attribute references use destination-owned URLs.
Acceptance must prove assembled WordPress pages match the approved source content and relationships.
Compare source, extracted, transformed, loaded, skipped, failed, approved, and draft totals.
Review multiple Areas, custom blocks, layouts, attributes, Stacks, files, comments, and long page hierarchies.
Test canonical and historical paths, redirects, metadata, canonicals, sitemap entries, internal links, and files.
Document unsupported blocks, package data, Express objects, workflows, forms, and accepted reconstruction work.
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
The current app has Bridge paths for Concrete5 5.4, 5.7, and Concrete CMS 8+. The source schema is verified before scope.
Supported Blocks can map after Area, order, value, and media review. Custom Blocks require their own transformation.
Yes when attribute keys, types, native values, and destination fields are mapped explicitly.
They can become patterns, reusable blocks, template parts, duplicated content, or rebuild scope depending on their semantics.
Yes when originals and usages can be resolved from file versions and storage locations.
No. Themes, templates, packages, controllers, forms, workflows, and integrations require WordPress-native implementation.
Combine canonical PagePaths with a live crawl, approve destination permalinks, prepare redirects, and validate launch behavior.
Next step
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.
