AEM Sites: Should New Projects Start with Universal Editor, While Existing Sites Continue with Page Editor?
AEM Sites is evolving with multiple authoring and delivery approaches. Universal Editor is becoming an important option for new projects, especially those using Edge Delivery Services or headless architectures. At the same time, Page Editor remains supported and continues to be relevant for many existing traditional AEM Sites implementations.
However, choosing between Page Editor and Universal Editor is not only an editor decision. It can also affect:
- Authoring experience
- Front-end development approach
- Performance expectations
- Content governance and workflows
- Templates, styles and responsive layouts
- Integrations and custom dialogs
- Migration and maintenance effort
I would like to know the community's practical experience:
- For a new AEM Sites project, which approach would you choose—Page Editor, Universal Editor, or another authoring model?
- If you have an existing Page Editor implementation, would you consider moving to Universal Editor? Why or why not?
- For teams using Universal Editor with Edge Delivery Services, what has been your experience so far?
- Did the differences in templates, Style System, Responsive Grid or custom dialog functionality affect your decision?
- What was the most important factor in your project—author productivity, performance, developer flexibility, governance, localization, integrations or maintenance?
- What would you recommend to a team starting a new AEM Sites project today?
Please share your views, implementation experience, lessons learned and challenges. It would also be helpful if you mention your AEM version, project type—greenfield or migration—and your role.
There may not be one answer that fits every project. Real-world feedback from the community can help others make a more informed AEM Sites architecture decision.