Moving an AEM project to AEM as a Cloud Service has two halves: the content, and the code. We’ve written about moving content. This post is about the other half: Java code, OSGi configurations, Dispatcher configuration, and legacy UI that were written for AEM 6.x, AMS, or on-premise and need to be reworked for the cloud. Adobe documents an agent-based toolset for that work, built around the Best Practices Analyzer’s findings. Here is how the pieces fit together, what the documentation says about how a session runs, and what it leaves out.
Status: What the Pages Do and Don’t Say
| Item | What the documentation says |
| Migration Skill and Cloud Migration MCP | NO STATUS LABELS STATED. Adobe’s overview page and its Cloud Migration MCP page (both last updated October 9, 2026) show no GA, Beta, or Early Access label. Don’t assume either; confirm maturity with Adobe. |
| What’s new vs. existing | The AEM 2026.9.0 release notes list additions to the Cloud Migration skill: a read-only migration runbook and additional patterns. In our reading of the notes, those included Guava-to-Caffeine and Dispatcher configuration conversion, and possibly Legacy UI conversion and template modernization; confirm the exact list in the notes. The skill page itself does not say which patterns are new, so we can’t tell you which ones predate that release. |
| Scope | Java code and OSGi configurations from AEM 6.x, AMS, or on-premise; Dispatcher conversion covers AMS or on-premise Apache HTTPD and Dispatcher configurations. Repository structure and content transfer are handled by other tools (Adobe names the Refactoring Tools and the Content Transfer Tool). |
Different from our content-migration post. “AEM + AI Migration” covers moving legacy CMS content into AEM. This post covers moving existing AEM code and configuration to the cloud.
How the Process Flows
Findings sources, runbook, one-pattern sessions, and batched review, as described in Adobe’s documentation.
How the Pieces Fit
| Piece | Role, per Adobe’s documentation |
| Best Practices Analyzer (BPA) | Produces the findings that drive the migration skill. |
| Cloud Acceleration Manager (CAM) | Hosts BPA reports and tracks overall migration progress. |
| Cloud Migration MCP | A hosted MCP server that lets the agent in your IDE fetch BPA findings directly from a CAM project, so you don’t have to export a CSV. |
| Migration Skill | Orchestrates the workflow and applies transformations. |
| code-assessment skill | Companion skill to which the code transformations are delegated. Ships in the same skill package as the Migration Skill. |
What It Can Migrate
The overview page groups the supported patterns into three areas. We list them as Adobe names them and explain only what the page itself explains; check the skill’s own documentation for what each pattern transforms.
| Area | Patterns named on the page |
| Code and configuration | scheduler, resourceChangeListener, replication, eventListener, eventHandler, assetApi, guavaCache (swaps Guava cache usage for Caffeine), and htlLint. For OSGi configurations: JSON-format config conversion, runmode scoping, extracting Cloud Manager secrets and environment variables, and detecting unsupported run modes. |
| Legacy UI and templates | lui (dialog migration), cdw (custom design widgets), and template modernization (static to editable templates). |
| Dispatcher | dispatcherConversion, for AMS or on-premise Apache HTTPD and Dispatcher configurations. |
How a Session Runs (as Documented)
- A read-only runbook comes first. It is generated before any code changes and covers every supported pattern, with affected files, finding counts, and a prompt to start each fix. No code is changed until you start a pattern session.
- One pattern per session. If a BPA report contains several patterns, the agent asks you to pick one.
- Changes come in batches of five. The agent applies a batch, then pauses for your review before continuing.
- Code changes are delegated to the companion code-assessment skill.
Inputs and Prerequisites
- A project: a Maven or Gradle AEM project open in your IDE.
- Findings source (recommended, not required for manual flows): either a BPA CSV export from your AEM instance, or a CAM project with an uploaded BPA report plus the Cloud Migration MCP configured.
- The MCP: endpoint https://mcp.adobeaemcloud.com/adobe/mcp/cloud-migration. You sign in with an Adobe ID that has access to the CAM project and, per the page, “appropriate permissions” in CAM (the page does not say which). The agent does not fetch findings until you explicitly select a project.
- An AI-enabled IDE that supports agent skills and remote MCP servers. The pages name no specific IDE.
The two MCP tools
| MCP tool | What it returns |
| fetch-cam-bpa-findings-by-pattern | Findings for one pattern from the latest BPA report. The page lists these patterns: scheduler, assetApi, eventListener, resourceChangeListener, eventHandler, guavaCache, lui, cdw, or all. |
| fetch-cam-bpa-findings-by-importance | All findings at one severity (CRITICAL, MAJOR, ADVISORY, or INFO) from the latest report, sorted by descending count. |
A detail worth checking: the MCP’s pattern list is shorter than the skill’s. For example, replication, htlLint, and dispatcherConversion appear in the skill’s list but not in the MCP tool’s. The pages don’t explain how findings for the remaining patterns are sourced, so confirm with Adobe or test it on a project before assuming every pattern can be driven from CAM.
What the Documentation Doesn’t Say
- No accuracy guarantees or known gaps for the transformations.
- No guidance on validation, testing, or rollback beyond the review pause after each batch.
- No description of data handling for the MCP: retention, storage, or transmission.
- No status labels and no named supported IDEs.
How This Might Fit Your Project (Our Reading)
This is our interpretation, not Adobe guidance, and we have not used these tools on a customer project. None of it is a documented outcome.
- The runbook may be useful on its own. Because it is read-only and generated before any change, it works as an assessment of what needs attention, even if you decide to do some of the work by hand.
- Work on a branch and treat each batch of five like a pull request. The pause for review is where your judgment goes: business logic, edge cases, and anything the tool can’t know about your project.
- Keep your normal safety nets. Build, run your tests, and use your pipeline’s code quality checks on the result. The documentation doesn’t offer rollback or validation guidance, so rely on version control and your usual process.
- Ask Adobe about data handling if you have constraints on what leaves your environment, since the pages don’t say.
- Start with one low-risk pattern on a non-critical project to see how the batches and review pauses feel before scaling up.
What We Haven’t Verified
- We read Adobe’s pages on October 22, 2026 (last updated October 9, 2026) and have not run these tools on a project.
- The pages state no maturity label, and the skill page does not indicate which patterns are new. Our reading of the release notes is approximate; check the notes themselves.
- We did not test the quality of any transformation or measure any time savings. Evaluate on your own codebase.
- We did not review the separate skill-usage page or the Best Practices Analyzer and CAM setup guides in detail.
- Patterns, tool names, and prerequisites may change; re-check Adobe’s pages before relying on specifics.
Before-You-Start Checklist
- Confirm with Adobe the current maturity of the Migration Skill and the Cloud Migration MCP
- Confirm your source is AEM 6.x, AMS, or on-premise Java code and OSGi configuration (Maven or Gradle project)
- Generate BPA reports and decide whether you’ll use a CSV export or a CAM project with the MCP
- If using the MCP, confirm your Adobe ID has access and the right CAM permissions
- Check which patterns you need against both the skill’s list and the MCP’s shorter list
- Ask Adobe about data handling if you have constraints on what leaves your environment
- Work on a branch, one pattern at a time
- Review every batch of five changes before continuing
- Run your build, tests, and code quality checks on the result before merging
- Plan separately for repository structure and content transfer, which these tools don’t cover
Final Thoughts
Code migration is the part of a cloud move that rarely gets headlines: a long list of small, mechanical changes that each need a developer’s attention. Tooling that reads the analyzer’s findings, writes a plan, and applies changes in reviewable batches is a sensible way to shape that work. How well it performs on a real codebase is something Adobe’s pages don’t claim, and neither do we. Try it on a branch, keep your review process, and judge the results yourself.
