Guide · updated
Converting Classic UI dialogs and legacy components at scale: what the tools miss
Long-lived AEM sites often still carry ExtJS (Classic UI) dialogs and Foundation components. Authors on Cloud Service use the Touch UI, so every Classic dialog needs a Granite UI (Coral 3) equivalent, and Foundation components are best replaced by Core Components. Best Practices Analyzer reports these as CDW and LUI findings.
What Adobe's tools cover
Adobe's open-source AEM Modernization Tools (for AEM 6.5 or newer) currently list three converters: static to editable templates, design configurations to policies, and legacy to modern or Core components. They are rules-based: you write rewrite rules for your components, the tool applies them to content. Check the project's documentation for dialog conversion support in the version you use.
What the tools miss
- Custom ExtJS widgets and listeners: JavaScript logic in a dialog has no automatic Coral 3 translation.
- Multifields that stored data in custom formats: the content may need migrating as well as the dialog.
- Behaviour hidden in JSPs that read dialog properties in unusual ways.
- Design-mode settings that should become template policies rather than component properties.
A plan that scales
- Inventory: count dialogs, widgets and components by type; most estates have a long tail of near-duplicates.
- Decide per component: map to a Core Component, convert the dialog, or rebuild. Fewer custom components is usually cheaper to run.
- Write rewrite rules for the common cases and run them on a copy of production content.
- Convert the long tail by hand, with a reviewer comparing author behaviour side by side.
- Test authoring for every template with real authors before the content freeze.