AEM to WordPress for Norwegian Teams: Decide What Happens to Content Fragments
A migration decision guide for teams whose AEM content serves more than the visible website pages.
In this article
Illustrative workspace. Screens show concepts, not a delivered client system.
An AEM website rebuild can underestimate its scope if the brief lists only public pages. Content fragments may feed several pages or a separate application. For a Norwegian team considering WordPress, the first assessment should identify those consumers and decide which relationships the new system must retain. A visually similar page is not proof that every content use has been migrated.
Identify page-independent content
Adobe’s AEM headless introduction describes content fragment models, structured fragments and API delivery. This distinction matters because a fragment can have a role beyond the page where a reviewer happens to see it.
Inventory models, fragments, referenced assets and known consumers. Record the AEM version and supported export access. The developer should assess the actual source rather than assume a generic page export includes every dependency.
- Structured content and field definitions.
- References to other fragments or assets.
- Website and application consumers.
- The owners of those content uses.
Decide what WordPress will own
Some content may become editable website sections; other records may need a structured model or remain in another system. Choose that boundary explicitly. Copying the visible text into a page can remove a useful shared relationship or duplicate information that previously had one owner.
For each content family, document the future editor, destination and permitted uses. Native Elementor controls are appropriate for agreed page composition, while shared structured data may need its own interface and API strategy.
Assess application consumers before changing delivery
If a mobile application or another site reads the existing content, include its owner in the assessment. Identify required fields, identifiers, update expectations and fallback behaviour. A replacement content API is a separate deliverable from a marketing website redesign.
Where a consumer remains on AEM during transition, agree the temporary source of truth and final handover. Avoid a period in which two teams publish contradictory updates without knowing which system is authoritative.
Rebuild the editor workflow with representative content
Choose a sample containing shared content, an asset reference and a revised fragment. Ask the future WordPress editor to make a normal change and preview its effect. Check whether the shared content changes where intended and remains independent where required.
Do not approve the destination solely from a static screenshot. The acceptance example should demonstrate the editing relationship the team is commissioning, including any limits on page composition.
Plan reconciliation and launch by dependency
Use a mapping record for source identifiers, destination records and consumers. Check counts, but also follow the references. Prepare a final-content update plan so changes made after the first export are reconciled.
Map public addresses, media destinations and search metadata separately from API consumers. Agree which system is kept available for rollback or historical review and who authorises the final switch.
Must all AEM capabilities be recreated? No. Retain the functions the business needs and explicitly retire the rest. The proposal should show that decision rather than quietly omitting a dependency.
For the wider implementation decisions, see the AEM migration planning guide.
Discuss a scoped implementation
Share the public site, content model examples, known applications and the intended editor workflow. We can scope a representative migration sample before estimating the wider WordPress rebuild.
I’m Jagjeet Singh, based in India and working remotely with businesses and agencies. Discuss your AEM migration assessment. Share the current site or workflow and the first outcome you want to review; I can assess the requirements and propose an implementation scope.
Written by
Jagjeet Singh
Full stack development, WordPress engineering and practical web products. I work with businesses, teams and agencies in India and worldwide.
Explore my work
