Expand my Community achievements bar.

Submissions are now open for the 2026 Adobe Experience Maker Awards.
SOLVED

AEM Sites migration: Cloud with components or EDS?

Avatar

Level 2
We recently went live with a new corporate website built in AEM Sites hosted in Adobe Cloud using traditional components. Now we need to split off from the parent company and set up a separate license for our division site. Considering moving to EDS instead of just keeping what we've just built, as there are some issues and frustrations with the components approach. Just wondering how the community feels about AEM Sites EDS since it's still relatively new. We do not need the ability for lots of editors to create content in Word or Docs, but I'm hoping that the blocks approach will be more flexible and easier to work with than components, since we do not have any in-house IT resources to support component creation/customization. Any thoughts/opinions? Is EDS ready for prime time or are there still areas of weakness that need to be addressed? What are some of its limitations or reasons for holding off? Does it still follow a similar interface for editors, use language masters, experience fragments, etc.? Appreciate anything you can share. If there are any good comparisons of traditional AEM Sites (cloud) vs EDS, please point me in the right direction. Thanks much.
Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @AlexNathanson ,

 

EDS is not yet a full replacement for traditional AEM Sites - but it is a fantastic tool for marketing teams that need fast publishing without IT involvement. You will trade customization for simplicity, and structured authoring for content speed.

If you are already live with AEMaaCS and your site is complex or relies on JCR-based content models, stick with Sites. If your new division needs a clean break with minimal dev overhead, EDS might be the right tool - but test carefully.

 

In fact, if you do not have a single site on EDS, you will need to setup it, define a list of additional components (except for the default ones), as well as styles according to the theme of your brand. From my experience, this can take some time, which will be excessive for the setup of one site. In addition to the configuration of components, you will need to train editors to work in the universal editor or in document-based authoring.

If you already have components, templates, styles in AEMaaCS Sites that you want to reuse on a new license, then simply copy them or select them into a common module (kind a brand core components).

 

What people like about EDS

  • Fast Time to Market: Ideal for microsites or campaign pages - minimal setup. True only if you have basic implementation with site theming and list of components.
  • Developer Simplicity: Front-end teams can own the site fully using GitHub, Markdown, and static HTML.
  • No DevOps or Java Devs Needed: Eliminates the need for deep AEM stack knowledge or OSGi/JCR maintenance.
  • Performance: Near-instant rendering via CDN (Fastly) with Edge-side Includes (ESI) when needed.
  • Reduced Costs: No backend hosting burden; easier to scale for low-complexity sites.

Key Limitations / Reasons to Hold Off

  • Limited Extensibility: You can't build complex applications (e.g., logged-in user portals, search facets) like you can with full AEM Sites.
  • Experience Fragment Support: Still evolving; some XF rendering and rewriter limitations exist.
  • Preview Workflow Is Primitive: Authors preview via GitHub/Docs - not as intuitive as Touch UI or Sites Editor.
  • Multilingual Support Still Maturing: Language copies, live copy management, and translation workflows are not as robust.
  • No Structured Content / JCR: If your site requires structured data (products, locations), EDS will be a mismatch.

 

Kostiantyn Diachenko



Check out AEM VLT Intellij plugin


View solution in original post

2 Replies

Avatar

Correct answer by
Community Advisor

Hi @AlexNathanson ,

 

EDS is not yet a full replacement for traditional AEM Sites - but it is a fantastic tool for marketing teams that need fast publishing without IT involvement. You will trade customization for simplicity, and structured authoring for content speed.

If you are already live with AEMaaCS and your site is complex or relies on JCR-based content models, stick with Sites. If your new division needs a clean break with minimal dev overhead, EDS might be the right tool - but test carefully.

 

In fact, if you do not have a single site on EDS, you will need to setup it, define a list of additional components (except for the default ones), as well as styles according to the theme of your brand. From my experience, this can take some time, which will be excessive for the setup of one site. In addition to the configuration of components, you will need to train editors to work in the universal editor or in document-based authoring.

If you already have components, templates, styles in AEMaaCS Sites that you want to reuse on a new license, then simply copy them or select them into a common module (kind a brand core components).

 

What people like about EDS

  • Fast Time to Market: Ideal for microsites or campaign pages - minimal setup. True only if you have basic implementation with site theming and list of components.
  • Developer Simplicity: Front-end teams can own the site fully using GitHub, Markdown, and static HTML.
  • No DevOps or Java Devs Needed: Eliminates the need for deep AEM stack knowledge or OSGi/JCR maintenance.
  • Performance: Near-instant rendering via CDN (Fastly) with Edge-side Includes (ESI) when needed.
  • Reduced Costs: No backend hosting burden; easier to scale for low-complexity sites.

Key Limitations / Reasons to Hold Off

  • Limited Extensibility: You can't build complex applications (e.g., logged-in user portals, search facets) like you can with full AEM Sites.
  • Experience Fragment Support: Still evolving; some XF rendering and rewriter limitations exist.
  • Preview Workflow Is Primitive: Authors preview via GitHub/Docs - not as intuitive as Touch UI or Sites Editor.
  • Multilingual Support Still Maturing: Language copies, live copy management, and translation workflows are not as robust.
  • No Structured Content / JCR: If your site requires structured data (products, locations), EDS will be a mismatch.

 

Kostiantyn Diachenko



Check out AEM VLT Intellij plugin


Avatar

Community Advisor

Hi @AlexNathanson 

As @konstantyn_diachenko mentioned EDS also required IT resources but eliminate the backend/CI-CD overhead. It doe ssupport MSM with EDS-xwalk and also the feature similar to experience-fragment.
with EDS you can decide to use :

- Document-based authoring : Since content is being hosted either in sharepoint or google drive, This may required custom solution for MSM

- AEM based authoring : Uses UE for authoring and support MSM, Adobe is keep adding new capabilities based on customer use cases

- DA (https://da.live/) : Uses UE/doc like authoring and support MSM

For more info you can directly reach out to Adobe engineering team at their discord channel : https://discord.com/channels/1131492224371277874/1148893229316587550 

Arun Patidar

AEM LinksLinkedIn