Tags
Share
The shift to AEM as a Cloud Service (AEMaaCS) disrupted some of the delivery routines we relied on. Adobe I/O helped us bring them back even better than before.
A mature AEM project can feel as big as an entire world. Over time, development teams put in a lot of effort to make it comfortable to live in. So, they add customizations, utilities and all the small add-ons that make day-to-day tasks easier.
But then you move to the Cloud, and your world gets shaken up. AEMaaCS may be built for scalability, but the changes in architecture put your customizations at risk. This presents you with a new challenge: how do you make the project work in AEMaaCS while preserving the manageability your team has already achieved?
Fortunately, Adobe Cloud provides tools that can help.
What Tends to Get Left Behind
The transition can be tough, but Adobe Cloud gives you the tools to handle it. And Adobe I/O plays a bigger role than you might expect.
We’ve already handled several migrations from AEM 6.5 to AEM Cloud for large, complex websites. To tell the truth, the changes left us exasperated at times: “Why can’t it just look and work the same way it used to?!”
One of the best examples of this disruption is build automation. In several AEM 6.5 projects, we relied on Jenkins for static code analysis and builds. It was fully scripted: every build triggered a Slack notification: start and end times, build status, and a list of included commits.
In AEM as a Cloud Service, builds are automated through Adobe Cloud Manager, but there is no way to attach custom scripts to the pipeline.
Was this a disruption? Definitely.
Was it a blocker? Not at all.
Restoring Control with Adobe I/O
Because this is where Adobe I/O (AIO) came into play. It’s a platform for building lightweight applications on top of the APIs provided by Adobe Cloud: Experience Cloud, Creative Cloud, and Document Cloud. It also supports integration with third-party services through webhooks, custom I/O events, or Amazon EventBridge. AIO performs like an event-driven data hub: it connects systems by consuming events generated by cloud services and other external peers, and triggering some processing in response.
For example, AIO can subscribe to the “user uploaded a file” event in Adobe Workfront and start a workflow in a connected AEM instance. Since AIO also provides basic file and data storage, it’s easier to keep systems in sync and share the status of a build or an event across tools.
Once we checked that AIO was available under our Adobe corporate subscription and the right permissions were in place, we could set up the development environment with Node.js. We installed the AIO SDK via the “aio-cli” NPM package, created a test project, ran it locally (no Docker needed), and deployed it to the cloud. Before long, we had a working application up and running at https://<some-id>.adobeio-static.net.
Our first step? Recreate the Slack notifications we had in place before. This turned out to be straightforward: we subscribed to the “build started” and “build ended” events in Adobe Cloud Manager, and routed them to Slack using its messaging API.
We hit an early snag when we couldn’t set up notifications for the commits included in the current build—Cloud Manager doesn’t provide that info. To get around this, we integrated a TeamCity instance already connected to the project’s GitHub repository. It now handles commit history reporting.
AIO also offers a useful bonus: 200 MB key-value data storage with periodic automatic cleanup. We used it to set up a searchable history of builds and associated commits within the AIO app. A word of caution here—commit messages can reveal sensitive commercial or project-specific details.
To manage that risk, we split the AIO interface into two sections. Think of it as a dashboard with a hidden admin panel. The public section shows only the build timeline. The restricted section includes commit history and is accessible only to a defined group of authenticated users. AIO provides built-in tools for authorization which it connects to the web interface with minimal effort.
Building on the New Foundation
Meanwhile, our AIO project continues to evolve. We’ve added a “health check” panel for builds and a playground for testing Cloud Manager requests. We’re exploring deeper integrations too—like connecting a corporate Figma account to sync design updates directly to AEM. We’re also exploring ways to retrieve and display curated logs from AEM and Cloud Manager using AIO’s built-in file storage.
Our opinion? Adobe I/O is a powerful orchestration layer—even if it’s still underrated by many AEM developers. If you’re planning (or stuck in!) an AEMaaCS migration, it might be just the tool you didn’t know you needed.
And we’re not done yet either. We’ll keep sharing insights as we continue building more tailored, automated solutions for our clients. Stay tuned.
Put Our AEM Cloud Migration Expertise to Work
