migration

name migration description Migrates legacy AEM (6.x, AMS, on-prem) to AEM as a Cloud Service using BPA CSV/cache, CAM/MCP discovery, and a one-pattern-per-session workflow. Use to review/scan a project for AEMaaCS migration (generates a read-only migration-runbook.md covering all patterns via per-pattern detection strategies), for BPA/CAM findings, Cloud Service blockers, or fixes for scheduler, ResourceChangeListener, replication, EventListener, OSGi EventHandler, DAM AssetManager, HTL data-sly-test lint, Classic UI dialog migration (lui — ExtJS/Coral 2 → Coral 3), Custom Design Widgets (cdw), Guava cache → Caffeine swaps (guavaCache), and static→editable template modernization. OSGi configs → Cloud Manager — scan for secrets and $[secret:]/$[env:] placeholders. Converts AMS/on-prem Dispatcher configs to AEMaaCS (Branch E, beta). After discovery, migration hands off each (pattern, file) pair to code-assessment for pattern guides/shared references; template modernization, legacy UI, and Guava cache follow references/ modules. license Apache-2.0 AEM as a Cloud Service — Code Migration Source → target: Legacy AEM 6.x / AMS / on-prem → AEM as a Cloud Service . Scoped under skills/aem/cloud-service/skills/migration/ so this is not confused with Edge Delivery or 6.5 LTS. This skill drives the migration workflow : BPA data, CAM/MCP, one pattern per session , and target discovery. Transformation rules and steps live in the code-assessment skill — once a finding's pattern is identified, hand off to {code-assessment}/<pattern>/SKILL.md (or the relevant shared reference under {code-assessment}/references/ ). Setup: Use the aem-cloud-service install (see repository root README ) so both migration and code-assessment paths are available. If you already have the monorepo open with resolvable {code-assessment} paths, no separate install step is required. Quick start (for the person driving the agent) One pattern per chat/session — if you ask to "fix everything," the skill will ask you to pick first (e.g. scheduler vs replication vs htlLint). You have… Say something like… What happens A whole project to assess "Review my code for AEMaaCS migration" Generates read-only migration-runbook.md — all migration patterns (Java cascade + htlLint + osgiConfig ), affected files, sample prompts. No edits. A BPA CSV "Fix scheduler findings using ./path/to/bpa.csv " Fastest path: CSV → cached collection → files CAM + MCP only "Get scheduler findings from CAM; I'll pick the project when you list them." Agent lists projects → you confirm → MCP fetch ( cam-mcp.md ) Just a few files "Migrate scheduler in core/.../MyJob.java " Manual flow: no BPA required OSGi → Cloud Manager " Scan my config files and create Cloud Manager environment secrets or variables. " Agent auto-reads references/osgi-cfg-json-cloud-manager.md (full Adobe-aligned rules inlined there); no BPA pattern id HTL lint warnings "Fix htlLint issues in ui.apps " Proactive discovery via rg → fix per the HTL lint reference Template modernization " Migrate my static templates to editable templates and generate Modernize Tools rules. " / "Create editable templates from my static templates." / "Generate AEM Modernize Tools structure/component/policy rules." Agent auto-reads references/template-modernization/template-modernization-context.md (shared discovery + structured context), produces a per-template plan table , then executes the plan using editable-template-creation.md and aem-modernization.md , and validates via template-modernization-validation.md . No BPA pattern id. Dialog migration "Convert my Classic UI / ExtJS dialogs to Touch UI." / "Upgrade Coral 2 dialogs to Coral 3." / "Fix LUI dialog findings." Agent reads references/legacy-ui/dialog/context.md — filters BPA LUI to dialog sub-types, converts via extjs-to-coral3.md or coral2-to-coral3.md , validates via validation.md . BPA pattern id: lui . Custom widget migration "Fix my CDW findings." / "Migrate custom ExtJS widgets to Coral 3." Agent reads references/legacy-ui/cdw/context.md — inventories xtypes, maps or scaffolds Granite UI components via conversion.md , validates via validation.md . BPA pattern id: cdw . Run CDW before dialog migration when both are needed. Guava cache warnings "Fix guavaCache findings using BPA CSV." / "Swap Guava cache for Caffeine." Agent reads references/guava-cache.md — BPA is the source of truth (subtype custom.guava.cache ); one finding per bundle , not per Guava-internal class row. BPA pattern id: guavaCache . Not a code-assessment pattern — Guava cache usage only occurs in pre-migration code, never native AEMaaCS code. Dispatcher conversion (beta) "Convert my AMS / on-prem Dispatcher config to AEM as a Cloud Service." Agent reads references/dispatcher/context.md — detects the config mode , generates the tool config, runs Adobe's dispatcher-converter , verifies output (filter/ACL hard-gate), and validates. Branch E. Runbook pattern id: dispatcherConversion (heuristic). Starter prompts (copy-paste): "Review my code for AEMaaCS migration" — start here for a full runbook before changing anything. "Use the migration skill: scheduler only, BPA CSV at ./reports/bpa.csv , then apply the code-assessment pattern guide before editing." " Replication only from CAM; list projects first, I'll pick one." " Manual: event listener migration for .../Listener.java — read the code-assessment pattern guide first." "Scan my config files and create Cloud Manager environment secrets or variables." "Fix htlLint in ui.apps — scan for data-sly-test redundant constant warnings and fix them." "Migrate my static templates to editable templates and generate the Modernize Tools rewrite rules." "Fix LUI dialog findings using BPA CSV at ./reports/bpa.csv ." "Migrate custom ExtJS widgets (CDW findings) from CAM." "Fix all Classic UI and custom widget findings — CDW first, then dialogs." "Fix guavaCache findings using BPA CSV at ./reports/bpa.csv ." Path convention (Adobe Skills monorepo) From the repository root (parent of the skills/ directory): Symbol Path {code-assessment} skills/aem/cloud-service/skills/code-assessment/ Examples: {code-assessment}/SKILL.md , {code-assessment}/scheduler/SKILL.md , {code-assessment}/references/scr-to-osgi-ds.md . Workspace scope (IDE) — user code only Applies to finding and editing the user's AEM project (Java, bundles, config, HTL), not to reading installed skill files under {code-assessment} . Treat the current IDE workspace root folder(s) (single- or multi-root) as the only boundary for searches, globs, grep , and file reads/writes for migration targets. Do not search parent directories, sibling folders on disk, ~ , other clones, or arbitrary absolute paths to "discover" sources unless the user explicitly names those paths or asks you to include them. BPA CSV / CAM targets: If a filePath or class-to-file mapping does not resolve under a workspace root, stop and tell the user which paths are missing — do not hunt elsewhere on the filesystem. Ask them to open the correct project in the IDE or adjust paths. Manual flow: Only migrate files the user named that live under the workspace (or paths they explicitly provided). Do not expand scope by searching outside the workspace. Required delegation (do this first) Branch A — OSGi configs → Cloud Manager (no Java BPA pattern this session): If the user asks to scan config files , create / set up Cloud Manager environment secrets or variables , move passwords or secrets out of OSGi / .cfg.json / ui.config , or mentions $[secret:] / $[env:] for AEM CS, then read references/osgi-cfg-json-cloud-manager.md immediately and follow the product rules and workflow defined in that file (Adobe AEM as a Cloud Service OSGi + Cloud Manager behavior is reproduced there—no external doc URL required). Sleek prompts are enough — no need to name the reference file. Skip branch B for that work. Branch B — Java / HTL / BPA pattern migration: Read {code-assessment}/SKILL.md — critical rules, Java baseline links, Pattern Guides table, Manual Pattern Hints . Read the pattern guide (or reference) for the single active pattern: scheduler → {code-assessment}/scheduler/SKILL.md (pattern guide) resourceChangeListener → {code-assessment}/resource-change-listener/SKILL.md (pattern guide) replication → {code-assessment}/replication/SKILL.md (pattern guide) eventListener / eventHandler → {code-assessment}/event-migration/SKILL.md (pattern guide — both JCR and OSGi Event Admin paths) assetApi → {code-assessment}/asset-manager/SKILL.md (pattern guide) htlLint → {code-assessment}/references/data-sly-test-redundant-constant.md (reference — HTL lint is a single shared reference, not a dedicated pattern guide) guavaCache → references/guava-cache.md (reference — Guava cache → Caffeine swap; lives under migration only, not code-assessment , since Guava cache usage does not occur in native AEMaaCS code, only in code carried over from legacy AEM) When code uses SCR, ResourceResolver , or console logging, read {code-assessment}/references/scr-to-osgi-ds.md and {code-assessment}/references/resource-resolver-logging.md (or the hub {code-assessment}/references/aem-cloud-service-pattern-prerequisites.md ). Do not transform Java or HTL until the pattern guide (or reference) is read (branch B). Branch A does not require {code-assessment} pattern guidance. Branch C — Template Modernization (no BPA): static → editable templates and/or AEM Modernize Tools rules (structure/component/policy). Three phases: context → per-template execute → validate. Start at references/template-modernization/template-modernization-context.md ; generators are editable-template-creation.md and aem-modernization.md ; post-gen checks in template-modernization-validation.md . Skip branch B. Branch D — Legacy UI Migration ( legacy-ui/ sub-folders): If the user asks to convert Classic UI / ExtJS dialogs, upgrade Coral 2 dialogs, migrate custom ExtJS widgets, fix LUI or CDW BPA findings, or mentions cq:Dialog / xtype / cq:Widget : For dialog findings ( lui pattern, legacy.dialog.classic or legacy.dialog.coral2 only): Read references/legacy-ui/dialog/context.md — getBpaFindings('lui', …) , filter to dialog sub-types, skip all others with a note. convert-extjs → references/legacy-ui/dialog/extjs-to-coral3.md . upgrade-coral2 → references/legacy-ui/dialog/coral2-to-coral3.md . Validate: references/legacy-ui/dialog/validation.md . For custom widget findings ( cdw pattern): Read references/legacy-ui/cdw/context.md — getBpaFindings('cdw', …) , inventory xtypes. Per xtype: references/legacy-ui/cdw/conversion.md (apply mapping or scaffold Granite UI component). Validate: references/legacy-ui/cdw/validation.md . If the same components also have LUI legacy.dialog.classic findings, run dialog migration afterwards — all xtypes are now resolved. Run order when both are needed: CDW first, then dialog. CDW resolves custom xtypes so dialog conversion can proceed without stops. Skip Branch B. Skip Branch C. Branch E — Dispatcher Conversion (AMS / on-premise Apache httpd + Dispatcher → AEMaaCS; no Java BPA pattern this session): Beta : Dispatcher conversion (Branch E) is in beta and under active development. Review its output carefully before using it on production dispatcher configurations. If the user asks to convert / migrate a Dispatcher configuration to AEM as a Cloud Service, follow the 6-phase flow . It wraps Adobe's maintained @adobe/aem-cs-source-migration-dispatcher-converter as the conversion engine and adds detection, config generation, output verification, judgment, and validation on top. Start by reading references/dispatcher/context.md . Skip Branch B. Inventory — run scripts/dispatcher-inventory.js ( buildInventory ) to detect the mode ( standard / flexible / already-cloud / not-dispatcher / v1 / unknown ) and count filter / rewrite / cache rules. Modes and signals are defined in references/dispatcher/context.md . If the mode is already-cloud , not-dispatcher , or unknown , STOP with that finding — the first two have nothing to convert, and unknown is an ambiguous/incomplete layout to confirm with the user before running the content-blind tool ( resolveExecutor falls unknown through to the on-prem executor, so the agent is the gate here).