Best Approach for Migrating 50+ Multiregional Websites from Umbraco to AEM (Headless vs Server-Side)

[bhushanKare]

Hello Team,

We are planning to migrate 50+ websites currently hosted in Umbraco into Adobe AEM. These websites are distributed across multiple regions including AU, NZ, and the UK.

Key considerations:

• Each region will have multiple themes and brand variations.
• The sites will contain a mix of static content and dynamic pages.
• Most dynamic pages will require API integration from different backend services.
• The frontend stack will be Angular, and backend services will be built using Java Spring Boot.
• Multi-region rollout will require proper CDN strategy and caching layer.

We are evaluating two possible approaches:

1. Server-Side (AEM Site Rendering / Editable Templates)

• Traditional AEM experience using editable templates/components.
• AEM handles rendering pages server-side and exposes final HTML.

1. Headless Approach (AEM Content Fragments, GraphQL API)

• Angular will consume content from AEM via GraphQL APIs or REST endpoints.
• AEM will act purely as a headless CMS.

Questions:

1. For a multi-theme and large multi-region setup, is the headless approach recommended over server-side rendering?
2. If using headless with Angular, how do we best manage:
• Theme variations per site/region
• Editorial flexibility similar to Umbraco templates/components
3. What are the recommended practices for CDN setup (Akamai/Azure CDN/CloudFront) with:
• AEM as a headless API
• Multi-region caching
• Content invalidation strategies
4. Are there any architectural references or Adobe blueprints for scaling multi-site headless setups with dynamic UI frameworks?

Any guidance, examples, or best practices would be highly appreciated — especially from teams who have migrated similar multi-site platforms from a monolithic CMS to AEM.

Thank you!

[ManviSharma]

Hello @bhushanKare ,

I hope you are doing well!

Given your description (“50+ sites, multi‑theme, multi‑region, API heavy, Angular is the standard”) the answer is:

Use AEM as a headless CMS for the core application surfaces, and keep the classic AEM Sites stack in reserve for brand/marketing experiences where in‑context authoring is genuinely required.

So not “headless everywhere by dogma”, but a headless‑first architecture with a clear escape hatch:

• Headless for: product, tools, logged‑in flows, heavy Angular.
• Headful (Sites) for: campaign microsites, heavy editorial, or where time‑to‑market and governance matter more than front‑end purity.

If you know the org is strongly committed to Angular and to owning the full rendering stack, then pure headless for all 50+ sites is a defensible choice.

[muskaanchandwani]

Hello @bhushanKare 
A few suggestions :

1. Headless vs server‑side AEM

For 50+ sites, multiple regions/brands, Angular front end and Java services, use AEM in headless or hybrid mode, not pure server‑side page rendering.
Pattern that works:
- AEM Content Fragments + GraphQL (persisted queries) as the canonical content store.
- Angular SPA as the rendering head.
- Use AEM Sites only where it adds clear value (MSM, translations, Experience Fragments, workflows, Universal Editor/SP A Editor).

2. Headless + Angular: theming & editorial flexibility

- Theming per site/region:
- Model a Site/Brand config in AEM (logo, colors, typography, feature flags).
- Expose it via GraphQL; Angular loads it at startup and maps to SCSS/CSS variables for per‑brand/per‑region themes.
“Umbraco‑like” flexibility:
- Use Content Fragment Models to represent “page” + “sections” (hero, text block, card grid, etc.).
- Authors build pages by ordering these section fragments; Angular maps them 1:1 to components.
- For in‑context editing, layer on SPA Editor (if SPA hosted in AEM) or Universal Editor for external Angular apps.

3. CDN, multi‑region caching & invalidation
Default: Adobe‑managed CDN (Fastly) → dispatcher → publish.
If you need Akamai/Azure CDN/CloudFront, put them in front of Adobe’s CDN and follow the documented BYO‑CDN pattern.

- For headless:
Use GraphQL persisted queries over GET; cache them at CDN and dispatcher.
Design for TTL‑based caching + stale‑while‑revalidate + ETag revalidation instead of purging on every publish; reserve explicit purges for truly time‑critical paths.
Dispatcher remains a second cache layer to protect publish on CDN cold‑cache or outages.

4. Further recommendation

- Authoring & content:
AEM CS Sites + Assets.
Content modeled as Content Fragments (with MSM and translations) exposed via GraphQL persisted queries.

- Front end:
Single Angular SPA codebase, configuration‑driven theming per brand/region, consuming AEM GraphQL + your Spring Boot APIs.
Optional SPA Editor / Universal Editor for visual editing where needed.

- Delivery:
Adobe CDN (or existing CDN in front of it) + dispatcher + publish.
Headless endpoints designed for cache‑friendliness and multi‑region TTLs.