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 · Accepted solution]

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.

[Shashi_Mulugu]

Hi @bhushanKare ,

If you are using aem cloud, Please evaluate Adobe AEM Edge Delivery Services for fast, efficient and reliable sites 

You can have all 3 flavors depending on the page complexity,  integration needs and dynamic vs static natures.

[bhushanKare]

Thank you @ManviSharma @Shashi_Mulugu and @muskaanchandwani  for your resposne.

As we are new to AEM CMS, we would like to understand the recommended approach for implementing headless.We have 50+ sites that will include brochureware pages, and multiple dynamic pages with multiple themes. Based on this, we are considering the following options:

1. UI (Angular) + Cloud Headless CMS 

   • The Angular application communicates directly with AEM Headless APIs (GraphQL) to fetch and render the content, including theme details. The Angular app will handle rendering of pages and components using these theme details.

2. UI (Angular) + BFF + Cloud Headless CMS

   • The Angular UI communicates with a Java BFF layer via REST APIs, which in turn fetches content from AEM Headless CMS.

In both options, we are planning to keep static and brochureware pages in AEM for direct rendering.

Could you please suggest which approach would be more suitable for our use case?