AEM Sites: Should New Projects Start with Universal Editor, While Existing Sites Continue with Page Editor?

​@AmitVishwakarma,
This is a very relevant discussion, especially because the choice between Page Editor and Universal Editor is really becoming an architecture and delivery decision, not just an authoring-tool decision.

Adobe's current guidance seems to align closely with the direction mentioned in the post: new projects should generally default to Universal Editor, while existing Page Editor implementations can continue with Page Editor and evaluate Universal Editor when moving toward Edge Delivery Services or headless architectures. At the same time, Adobe notes that the feature gap is still narrowing and the final choice should be driven by the project's specific requirements.

One point I find particularly interesting is that Universal Editor doesn't necessarily mean only Edge Delivery Services. Adobe documents it for both Edge Delivery Services and headless implementations, while Edge Delivery Services can also support document-based authoring. So I think the more useful architectural question is:

What are we optimizing for - traditional AEM page delivery, headless delivery, Edge Delivery Services, authoring flexibility, or the existing investment in the Page Editor component model?

For an existing Page Editor implementation, I would also be cautious about treating Universal Editor as a straightforward editor upgrade. The existing component architecture, templates, dialogs, Style System, Responsive Grid, workflows, and integrations can all influence the migration effort. Adobe explicitly calls out feature differences between the two editors, so the current implementation needs to be assessed before deciding on migration.

For a greenfield project, though, the combination of Universal Editor + Edge Delivery Services is particularly interesting because it also changes the development and delivery model. Adobe's current Edge Delivery guidance describes a composable approach where website code is managed through GitHub and the site is delivered without the traditional AEM Publish/Dispatcher model.

One question I'd be interested in hearing from teams with real project experience:

When making this decision for a greenfield project, did you start with the authoring requirements and choose the editor afterward, or did the desired delivery architecture (traditional AEM, headless, or Edge Delivery Services) determine the editor choice first?

That distinction could be very useful for teams trying to avoid choosing the editor in isolation from the overall AEM architecture.

​@AmitVishwakarma 

Good timing on this post, we just went through this exact decision on two parallel projects, one greenfield and one migration, so I can give you both sides.

Greenfield project: AEM as a Cloud Service with Edge Delivery Services, we went with Universal Editor without much debate. The team was small, nobody had years of Page Editor muscle memory to unlearn, and the client wanted fast page turnaround more than deep custom dialog complexity. From a PM standpoint the biggest win wasn't technical, it was onboarding speed. New authors were productive in days instead of weeks because the editing experience is so much closer to "click the thing you see and change it" rather than learning component dialogs.

Migration project: this is the harder story. Existing Page Editor implementation, heavy investment in custom components, several complex dialogs driving business logic, and a governance process built entirely around the classic authoring workflow. We evaluated moving to Universal Editor and decided against it for now. Not because Universal Editor isn't capable, but because the cost of rebuilding those dialogs and retraining a fairly large author base didn't pencil out against the business value this year. We're revisiting it as a phased conversation for next year instead of a rip and replace.

A few things that mattered more than I expected going in:

• Governance and workflows took the longest to sort out, more than the tech itself. Universal Editor changes who can do what and when in ways that don't map cleanly onto existing approval chains, especially if you have strict content governance today. Budget real time for this conversation with your content ops team, not just your dev team.
• Developer experience is genuinely different, not just a new API to learn. Front end devs on the Universal Editor project were writing more standard web components and leaning less on AEM specific patterns. That's a plus for hiring and long term maintenance, but it's a real ramp up cost if your team has years of classic AEM development habits.
• Performance expectations were mostly met with Edge Delivery Services, but that's really an EDS win more than a Universal Editor win specifically. Worth separating those two things when you're evaluating, since they often get bundled together in conversation but they're separate decisions with separate tradeoffs.

My honest recommendation: for a team starting fresh today, default to Universal Editor plus Edge Delivery Services unless you have a specific reason not to, like heavy reliance on existing custom dialogs or an authoring team that's not ready for the workflow change. For an existing Page Editor site that's working fine, I would not move it just because Universal Editor is newer. Move it when you have a real driver, a redesign, a platform migration, something that already requires significant rework, and fold the editor change into that effort rather than treating it as its own initiative.

Curious whether anyone has actually done a live migration from Page Editor to Universal Editor on a large site, versus starting fresh. That's the scenario I have the least real data on and would like to hear how painful it actually was.

Thanks.