Stop Migrating. Start Modernising.
What if your next AEM migration didn’t have to feel like one?
Insights from Sunali Paul, AEM Principal Consultant at Anchora
When was the last time someone in your organisation said the words “AEM migration” and the room didn’t collectively exhale?
We’ve been conditioned to treat migrations as these monolithic, multi-quarter marathons. Scope documents the size of novels. Regression testing that never seems to end. That familiar pit in your stomach when someone asks, “so when’s the go-live date?”
But what if the problem isn’t migration itself? What if it’s the way we’ve been approaching it?
The elephant in the room: traditional AEM delivery is showing its age
Let’s be honest for a second. If you’re still running a traditional AEM setup, you already know the friction points. You live them every day.
Slow page loads that make your performance team wince. Frontend frameworks so heavy they need their own project plan. Deployment pipelines so complex that “just pushing a content update” becomes a cross-functional event.
Sound familiar?
And it’s not that the teams are doing anything wrong. It’s that the architecture was built for a different era. An era where the origin server did all the heavy lifting, where performance was an afterthought you optimised for after launch, and where “agile content delivery” meant getting something live within the same quarter it was requested.
So the question isn’t really “should we modernise?”
it’s
“what does modernisation actually look like now?”
Enter Edge Delivery Services.
Adobe’s Edge Delivery Services (EDS) represents a genuinely different way of thinking about how AEM experiences get built and delivered. Not incrementally different. Architecturally different.
The core idea? Separate authoring from delivery. Completely.
Your content authors keep working where they’re comfortable, whether that’s within AEM itself, Google Docs, or Microsoft Word. But the delivery? That happens at the edge. Globally distributed CDN nodes serving content directly to users, with performance decided at the edge rather than back at the origin.
What does that actually mean in practice?
It means your Core Web Vitals (LCP, CLS, INP) aren’t an optimisation exercise anymore. They’re baked into the architecture. It means your developers get branch-based previews via .aem.page and .aem.live, so they can see exactly what they’re shipping before they ship it. It means updates are triggered via Git commits, not traditional deployment cycles. Push, preview, publish. That’s it.
And monitoring? CDN logs and Operational Telemetry (OpTel) give you observability at the edge, where it matters.
But here’s where it gets really interesting and where most people aren’t paying enough attention yet.
The AI multiplier: this is the part that changes the conversation
AEM Cloud’s Experience Modernization Console introduces something that would have sounded like wishful thinking two years ago: AI-assisted modernisation at scale.
We’re talking about AI-assisted content transformation. AI helping with code refactoring and experience modernisation. Migration workflows that are accelerated not by throwing more people at the problem, but by fundamentally reducing the manual effort involved.
Is it magic? No.
Does it replace the need for experienced AEM practitioners who understand the nuances of your specific implementation? Absolutely not.
But does it dramatically shift the effort-to-value equation? That’s what we wanted to find out.
So we tested it. On a weekend.
Our AEM Principal Consultant, Sunali Paul, decided to put this to the test using the Anchora homepage.
Over a weekend, Sunali used Adobe’s AI-assisted Experience Modernization capabilities to migrate the Anchora homepage to Edge Delivery Services.
A weekend.
Let that sink in for a moment. Think about the last migration project you were involved in. Think about the timeline. The resource plan. The number of meetings just to agree on the approach.
Now think about what it means when someone with deep AEM expertise, armed with the right AI-assisted tooling, can achieve a working migration of a production homepage in days rather than months.
You can see the result here: https://main–anchora-aemcoder-demo–anchoraorg.aem.page/
But this isn’t really about speed. It’s about what speed enables.
Fast is great. But fast without substance is just rushing. What makes this interesting isn’t just the timeline, it’s what the combination of EDS and AI-assisted modernisation opens up.
For developers: what if you could stop wrestling with deployment pipelines and actually focus on building? EDS’s cloud-based development pattern means less time on infrastructure, more time on the things that actually differentiate your digital experience.
For content authors: what if the latest AEM innovations weren’t something you had to wait for in the next major release? What if they were just… there? Delivered regularly, without a migration event?
For system administrators: what if “infrastructure maintenance” stopped being your entire job description? What if the manual configuration work that eats your weeks was genuinely reduced?
For marketing teams: what if faster time-to-value wasn’t just a slide in a vendor presentation, but something you could actually measure?
These aren’t hypothetical questions. This is what happens when you stop thinking about migration as a like-for-like lift-and-shift and start thinking about it as genuine modernisation.
The conversation that’s already happening (and you should be part of it)
Here’s what we’re seeing in the community right now: practitioners are building AI-powered workflows that go beyond what even Adobe has packaged yet. Automations that read requirements, interpret Figma designs, generate block-level implementations, write unit tests, run accessibility checks, handle code reviews – entire development pipelines augmented by AI at every stage.
Is everyone doing this? No.
Are the people who are doing it gaining a significant advantage? Without question.
The interesting question isn’t whether AI-assisted modernisation works. It’s how far it goes. Where are the boundaries? What still needs a human eye, human judgement, human experience? Where does the AI accelerate, and where does it mislead?
We don’t have all the answers. Nobody does yet. And honestly, anyone who claims they do is probably selling something. But we’re actively working at this edge (no pun intended), testing, learning, and building real expertise in what’s possible right now.
So what does this mean for you?
If you’re sitting on an AEM on-premise or Managed Services environment, and the word “migration” has been floating around your organisation like a storm cloud, maybe it’s time to reframe the conversation.
This isn’t about ripping and replacing. It’s not about another 18-month program of work. It’s about understanding that the tooling has fundamentally shifted, and the gap between where you are and where you could be might be smaller than you think.
But it does require people who understand both sides: the legacy landscape you’re coming from, and the cloud-native, edge-first architecture you’re heading towards. People who’ve actually done this, not just read about it.
Let’s talk.
At Anchora, we have dedicated AEM specialists working at the forefront of Edge Delivery Services and AI-assisted modernisation. People like Sunali Paul, who aren’t just following this evolution, they’re actively testing it, breaking it, and building with it.
If you’re curious about what modernisation could look like for your AEM environment, whether you’re just starting to explore or you’re deep in planning, we’d genuinely love to have that conversation.
No pitch deck. No 47-slide capability presentation. Just a real conversation about where you are, where you want to be, and what’s actually possible now.
Reach out to us at Anchora. Let’s figure it out together.
Sunali Paul is an AEM Principal Consultant and Adobe Certified Master at Anchora, specialising in AEM Cloud, Edge Delivery Services, and experience modernisation.