CIRCUIT

Migrating AEM Workflows from Classic to Touch UI Interface

The shift from the legacy Classic UI to the Touch UI in Adobe Experience Manager represents one of the most consequential architectural changes for Australian enterprises running content-driven platforms. For teams in Sydney, Melbourne and Brisbane who have relied on Classic UI workflow consoles for years, the migration is rarely a simple skin swap. Touch UI workflow editing behaves differently, exposes different endpoints, and assumes a modern Coral-based component library that did not exist when most Classic workflows were first authored.

This guide walks through the technical decisions, the tooling, and the validation steps required to move a working Classic workflow into the Touch UI environment. It draws on patterns shared at the CIRCUIT conferences in Chicago and reflects the realities of distributed AEM teams collaborating across AEST time zones, where handoffs between developers and content authors often span a single business day.

Why Move from Classic to Touch UI

Adobe formally deprecated the Classic UI workflow editor in AEM 6.4 and removed it from later service packs, which means every Australian organisation still authoring process steps through the old console is operating on borrowed time. Large customers in the banking sector — the big four Australian banks included — have been quietly migrating their authoring environments because support contracts increasingly reference Touch UI as the supported path forward.

Beyond compliance, the Touch UI offers tangible productivity gains. Authors can approve or reject workflow items from the unified inbox on a tablet during their commute from Parramatta into the CBD, rather than being tied to a desktop instance. Granite UI components render consistently across devices, and the new participant step chooser integrates with the same user picker used elsewhere in the product, reducing the training burden on content editors in regional offices.

There is also a strategic reason. Adobe's roadmap for AEM as a Cloud Service treats Touch UI as the only supported authoring surface. Any team planning an eventual move to AEMaaCS — or evaluating managed services offered through Adobe partners in Sydney and Melbourne — needs a workflow layer that will translate cleanly.

Interface Differences That Affect Workflows

The two interfaces look superficially similar when editing components, but workflow authoring reveals deeper architectural gaps. The Classic UI uses ExtJS-based dialogs that read from /libs/cq/workflow/admin/components nodes, while Touch UI workflows render through Granite UI foundation components under /libs/cq/gui/components/siteadmin/admin/workflows.

Capability Classic UI Touch UI
Workflow editing path /libs/cq/workflow/admin/console /libs/cq/gui/content/coral/wcm/workflows
Dialog framework ExtJS widgets Granite UI Coral 3 components
Mobile authoring Limited, not officially supported Full responsive inbox
Inbox integration Standalone classic inbox Unified inbox with mobile parity
Custom step rendering Xtype-based plugins Sling model + HTL templates
API exposure JSP-driven servlets Sling Models exposed via JSON exporter

The practical consequence for a team in Brisbane preparing a migration sprint is that custom step dialogs authored with xtypes will not render in Touch UI. They must be rewritten as Granite UI fields — typically granite/ui/components/coral/foundation/form/textfield, pathfield, or multifield — and the backing component logic must move from JSP scriptlets to Sling Models written in Java.

A Phased Migration Strategy

A safe migration rarely happens in a single sprint. Australian teams that have done this successfully tend to follow a phased approach that limits risk to a single content tree at a time.

  • Audit existing workflows by exporting the /var/workflow/models tree from the Classic-enabled author and reviewing each model for legacy xtypes or JSP-based dialogs.
  • Rebuild custom dialogs against the Granite UI Coral 3 specification, keeping the same Sling resource types so that any in-flight workflow payloads remain valid.
  • Migrate models one business unit at a time, starting with non-customer-facing approval flows used by internal communications teams.
  • Switch the production author to Touch UI workflow editing and monitor the unified inbox for orphaned or stalled items.

Each phase should be owned by a named engineer, and the schedule should account for the overlap between Australian and offshore teams. A typical AEST handover window with teams in India or Eastern Europe means that broken models discovered at 5pm AEST can be fixed overnight before the next morning's authors arrive.

Pitfalls That Trip Up Australian Teams

Several recurring issues have surfaced across CIRCUIT sessions and across Australian customer engagements. Awareness of these patterns saves weeks of debugging.

  • Orphaned payloads: Workflows that reference custom step types which no longer resolve will silently leave payloads stranded in /var/workflow/instances. A scheduled purge job is essential after migration.
  • Permission inheritance drift: Touch UI uses different ACL evaluation paths through Sling, so workflow groups that worked under Classic UI sometimes lose visibility into their assigned steps.
  • Date formatting surprises: Classic UI rendered timestamps using the JVM default locale; Touch UI respects the author profile's preferred locale. Australian authors who previously saw DD/MM/YYYY may now see ISO-formatted output until browser language is set correctly.
  • Notification emails: The Classic UI email template lives under /etc/workflow/notification/email, but Touch UI expects Coral-compatible templates at /conf/global/settings/workflow/notification. A redirect rule often clears up missing notifications without rebuilding every model.

Teams that skip the audit phase frequently discover these issues only after a regulatory update workflow — common in financial services under APRA reporting requirements — fails to fire. A staged rollout with feature flags per business unit is the safest path.

Validating and Testing Migrated Workflows

Before flipping the production author to Touch UI, every migrated workflow model should run through a structured validation pass. The simplest checklist covers three areas: rendering, payload integrity, and notification routing.

  • Rendering: Open each model in the Touch UI editor and confirm that step properties, dialogs, and transitions all save correctly. Watch for fields that silently strip values, which often indicates a missing name attribute on the Granite UI field.
  • Payload integrity: Start a workflow instance on a representative content path and verify that all metadata survives end-to-end. If your workflow includes a post-replication step, the AEM event listeners for replication pattern discussed in earlier CIRCUIT sessions remains the recommended way to chain downstream actions.
  • Notification routing: Trigger an inbox assignment and confirm that the email template renders and reaches the inbox. Touch UI requires the notification templates to live under /conf, and missing templates are the most common cause of silent workflow failures after a migration.

Beyond these mechanical checks, consider the broader content model. If the migrated workflow touches content fragments or experience fragments, validate that the variant references and template bindings still resolve. Fragment-based architectures are increasingly common in Australian headless implementations, and a workflow that once operated on simple page properties may now need to iterate over fragment variation nodes.

When validation is complete, schedule the production cutover during a low-traffic window — Sunday morning AEST works well for consumer-facing properties because the eastern seaboard activity peaks later in the day. Keep the Classic UI console accessible in read-only mode for one release cycle so that any historical workflow instance can still be inspected.

Run a 30-day post-migration review with your authoring leads in Melbourne or Sydney, capture every regression in a shared ledger, and prioritise fixes by user impact rather than by technical elegance. Workflows touch every part of an AEM platform, and a clean migration pays dividends every time a content author needs to publish a campaign, a press release, or a regulatory disclosure under the Privacy Act 1988 without waiting on a developer.