Migrating from AEM 6.0 to 6.3: Lessons from CIRCUIT 2015

Moving from AEM 6.0 to 6.3 was far more than replacing an application package and restarting a server. The upgrade changed expectations around repository structure, authoring interfaces, deployment practices, component development, and operational support. At CIRCUIT 2015 in Chicago, Adobe practitioners treated the migration as a programme of controlled changes rather than a single technical event.

That approach remains useful for Australian organisations planning an AEM upgrade today. A national retailer, a government department in Canberra, and a university with authors working across Sydney, Melbourne and Perth all face different publishing rhythms, integration requirements and compliance pressures. The common need is a migration method that protects content while improving the platform underneath it.

The conference brought Java developers, AEM architects, front-end specialists and systems engineers into the same conversation. Their experience highlighted a practical truth: an upgrade succeeds when repository work, code refactoring, dispatcher configuration, testing and author training are planned together.

For teams revisiting those lessons, the move from AEM 6.0 to 6.3 offers a useful case study in technical debt management. It also shows why a careful inventory, a realistic rehearsal environment and clear ownership matter more than rushing towards the first successful startup.

Treat The Upgrade As A Programme

AEM 6.0 implementations often carried assumptions from earlier CQ releases. Custom servlets, overlays, JSP components, client libraries and repository permissions could work reliably for years while remaining poorly documented. Before changing the target version, teams needed to record what existed, who depended on it and which parts were still actively used.

The CIRCUIT lessons favoured a staged assessment. Review installed packages, OSGi configurations, custom bundles, workflows, scheduled jobs, replication agents, dispatcher rules and third-party connectors. Map each item to a decision: retain, refactor, replace or remove. This makes the upgrade backlog visible and prevents an obsolete integration from becoming an emergency during cutover.

For an Australian business, the calendar matters as much as the code. A migration scheduled near the end of the financial year can collide with campaign launches, budget approvals and reduced availability over the summer holiday period. A short “arvo” maintenance window may suit a local team, but it is inadequate if authors span multiple time zones or customer traffic is continuous.

Stabilise The Repository First

Content migration is often the largest source of uncertainty. AEM 6.3 introduced a newer foundation for repository and Oak operations, so teams had to validate indexes, node types, permissions, version history and large binary assets rather than assuming that a clean application installation meant a clean migration.

A sensible rehearsal begins with a production-sized copy, not a small development export. Measure package creation, repository compaction, index reindexing, backup recovery and startup times. Check references between pages, tags, assets and content fragments. Test the process repeatedly until the runbook records commands, expected durations, validation checks and rollback conditions.

Repository hygiene is equally important. Remove abandoned versions and unused assets only under an approved retention policy, and never treat deletion as a shortcut for resolving structural problems. Australian organisations handling health, education or public-sector information may have strict retention and data-residency requirements, so storage location and backup handling deserve explicit review.

Refactor Components And Templates

AEM 6.0 projects commonly used a mixture of classic components, JSP, Sightly and early HTL patterns. By the time of the 6.3 migration, HTL was a stronger foundation for secure, maintainable presentation logic. The safest path was to identify components that could be carried forward and separately plan those requiring a controlled rewrite.

Avoid changing every component at once. Establish a small set of representative templates and components, then verify authoring dialogs, responsive behaviour, accessibility, client-library loading and content policies. Test empty states, long headings, translated strings and unusual asset formats. A component that looks correct on a developer’s laptop may fail when an Australian address, a long Aboriginal or Torres Strait Islander place name, or a mobile layout is rendered.

The upgrade was also a chance to reduce overlays and hard-coded assumptions. Keep business rules in appropriate services, use Sling Models where they improve separation, and make authoring behaviour explicit. This creates a clearer boundary between content structure and presentation, which helps when the same content later feeds mobile applications, search services or external channels.

Revisit Blueprint And Live Copy Design

Multi-site management can become fragile when blueprint relationships have grown organically. During an AEM 6.0 to 6.3 migration, teams should inspect rollout configurations, inheritance status, cancelled relationships and locally modified properties. A page tree that appears orderly may contain years of exceptions that make a bulk rollout risky.

The practical lesson is to test live copies with realistic editorial scenarios. Create a change in the blueprint, roll it out, modify a local page, cancel inheritance, and then attempt a later rollout. Confirm what happens to navigation, metadata, experience fragments and asset references. The blueprint and live copy guidance provides a useful way to think about governance as well as configuration.

This matters in Australia’s distributed market, where national content may need state-specific variations for New South Wales, Victoria or Western Australia. A retailer may share brand assets while changing delivery information, and a government service may need different regional contacts. The migration should preserve those controlled differences rather than flattening them into one common tree.

Make Dispatcher And Integrations Part Of Testing

AEM can appear healthy while the delivery tier is misconfigured. Dispatcher filters, cache rules, invalidation paths, vanity URLs, headers and compression settings must be tested against the new publish environment. Compare cache-hit rates and response behaviour before and after the upgrade, particularly for high-traffic landing pages and authenticated areas.

External services deserve the same scrutiny. Analytics, search, marketing automation, payment providers, identity platforms and asset repositories may rely on old endpoints or authentication behaviour. Test timeouts, retries, certificate renewal and failure handling. For organisations serving customers from Brisbane to Hobart, latency and content delivery should be measured from multiple regions rather than inferred from a single office connection.

GraphQL and headless delivery were becoming increasingly relevant in the broader AEM conversation. A migration is a good time to document which APIs are public, which fields are approved for exposure and how caching works. The discussion of flexible content delivery helps frame this as an architecture decision, rather than an automatic reason to expose the repository.

Improve Workflow And Author Operations

A platform upgrade is visible to authors through the Touch UI, dialogs, search, asset handling and workflow steps. If those experiences become slower or less predictable, the technical success of the migration will not feel successful to the publishing team. Capture baseline timings for activation, asset upload, search and common approval routes before making changes.

Workflow review should focus on actual editorial behaviour. Remove redundant participant steps, avoid unnecessary serial approvals and check whether scripts handle retries safely. Large workflows can create queues, repository growth and operational noise. Practical workflow optimisation for authors is therefore part of performance engineering, not merely a user-experience exercise.

Training needs to reflect local working conditions. An author in a regional office may have a slower connection, while a national newsroom may publish urgent material outside standard Sydney business hours. Provide short scenario-based training, clear escalation paths and a temporary migration helpdesk. Do not rely on a single demonstration delivered to a room in Melbourne and assume every team has absorbed it.

Build A Cutover You Can Prove

A reliable cutover plan is built from rehearsals. Freeze content at an agreed point, complete the final delta migration, run automated and manual validation, warm critical caches, check integrations and monitor error rates. Define who can approve each stage and what evidence is required before traffic moves to the upgraded publish tier.

Validation should cover more than page availability. Compare key URLs, metadata, redirects, permissions, search results, forms, analytics events and personalised experiences. Check authoring rights by role and verify that backups can be restored. A business owner should sign off on content accuracy, while technical owners confirm logs, monitoring and capacity.

Keep rollback practical. Preserve the previous environment until the new platform has passed an agreed observation period, and document how DNS, load balancing, dispatcher routing and content changes will be reversed. This discipline is especially valuable when a national campaign, a bushfire information page or a public-service announcement makes an unplanned traffic surge possible.

The enduring message from CIRCUIT 2015 is that a version upgrade creates an opportunity to simplify. Inventory the old platform, rehearse repository operations, modernise selectively, test the delivery path and support the people who publish every day. For Australian AEM teams, that combination turns a risky 6.0-to-6.3 migration into a controlled platform renewal.

Use these lessons to build a migration register, assign owners for content and code, and schedule a production-sized rehearsal before selecting a cutover date. Review the relevant CIRCUIT session material with developers, architects, infrastructure staff and authors together, then make each approval measurable. A migration that can be demonstrated, tested and rolled back is one that can be trusted.