Tom Johnson leads infrastructure and delivery at Hirobe, a professional services firm that has helped enterprise teams navigate AEM deployments for over a decade. I sat down with him to talk about what it really takes to move from on-prem or AMS AEM to Adobe's cloud-native offering — and what most organizations get wrong before they start.
The technical migration is honestly the easier part. Where teams struggle is the organizational readiness — who owns what, how decisions get made, and whether the people in the room actually have authority to commit.
The cloud vs. on-prem decision
A lot of organizations still run AEM on-prem or through Adobe Managed Services, and they're under real pressure to evaluate AEM as a Cloud Service. The pitch is continuous updates, lower ops burden, tighter integration across Adobe products. But the tradeoffs are real, and they're not always the ones the slide decks talk about.
Q: TAD
When you're advising a client about whether to move to AEM as a Cloud Service, what's the first question you ask?
A: TOM
How much custom code they're running. Not just the volume — the kind. Tightly coupled integrations, custom OSGi services with weird lifecycle dependencies, heavy use of deprecated APIs — the migration story gets complicated fast. That doesn't mean don't go. It means the prep work is bigger than they think.
Q: TAD
What about cost? Cloud is usually sold as a cost-saving move.
A: TOM
It can be. But teams routinely undercount the transition costs — refactor time, the learning curve for cloud-native AEM patterns, possibly rethinking how content is delivered. The licensing model is different too. You're paying for a managed service, not a perpetual license. That's not bad. It's just a different shape, and you need to plan honestly for it.
Staffing and team structure
The underreported challenge in AEM cloud migrations is organizational: who knows what, who owns the new environment, and how do you build institutional knowledge as the platform evolves under continuous delivery?
Q: TAD
How do you advise clients on staffing for a migration?
A: TOM
You need someone — ideally more than one person — who deeply understands both the existing implementation and the target state. That's rare. Most teams have either people who know the current system intimately but haven't worked cloud-native, or consultants who know AEMaaCS patterns but don't know the client's specific quirks. The overlap is hard to find. We usually recommend building a small tiger team of internal engineers who get deep training on the cloud environment before the migration work begins in earnest.
Don't outsource your architectural understanding. You can outsource execution, but someone on your team needs to own the 'why' of every decision — or you'll be dependent on external support forever.
What actually goes wrong
I asked Tom to be direct about the failure modes he sees most often. His answer was unambiguous.
A: TOM
In order: underestimating the BPA findings, starting the migration before the content strategy is defined, and assuming the Dispatcher config from on-prem will translate cleanly. It almost never does. The cache invalidation model is different, the delivery tier behaves differently — teams that just lift and shift their vhost and dispatcher config are in for a rough go-live.
The bottom line
Moving to AEM as a Cloud Service is the right direction for most organizations heavily invested in the Adobe ecosystem. But it's a genuine migration, not an upgrade, and it deserves a genuine plan: an inventory of custom code, a hard look at organizational readiness, a realistic timeline, and people who understand what they're building toward — not just what they're moving away from.