AEM 6.5 LTS Modernization: Java, OSGi and Legacy Code Readiness.

Declare the exact target release and verify its supported runtime and dependencies against current Adobe documentation. This page deliberately avoids a universal Java-version prescription, because compatibility must be assessed against the selected baseline.

Compilation, bundle resolution and service activation are different checkpoints. Older annotations, unavailable APIs and dependency imports should be examined independently instead of grouped under a single upgrade task.

Keep a reviewed dependency inventory alongside the expected OSGi service interfaces and configuration PIDs. Validate repository queries and Dispatcher behavior as consumers of the modernized application, rather than assuming a Java refactor leaves them unaffected.

Identify deprecated APIs and legacy SCR annotation usage, then plan replacements compatible with the target platform. Check generated component metadata and activation behavior when moving services to OSGi DS.

• Review Maven dependency convergence and bundle imports.
• Exercise service configuration, activation and reference availability.
• Run component, integration, Oak query and Dispatcher regression checks.

Use OSGi Declarative Services annotations supported by the target AEM baseline, while preserving intentional service interfaces, PIDs and reference filters. Review generated component descriptors as an output of the change. Convert each PoC finding into a reproducible acceptance check rather than relying on a one-off demonstration.

DS remediation requires refactoring and runtime regression validation; it is not a mechanical import replacement. Keeping legacy annotations avoids that immediate cost but prolongs upgrade coupling. Externalized configuration supports future cloud adoption, but cloud package structure, deployment assumptions and runtime constraints still need their own assessment.

For the service design behind those refactors, examine OSGi configuration and dependency boundaries.

Retain separate results for the platform baseline and custom code. The PoC is a readiness assessment, not evidence of a completed production migration.

• Record the selected runtime, dependency and package versions.
• Verify expected services are satisfied and functional after restart.
• Repeat authoring, content access, query and cache tests after refactoring.

Replacing SCR annotations can leave the expected service absent if generated DS metadata, configuration PIDs or reference target filters change. Compare the generated descriptors and test activation after a clean restart and configuration reload; a successful Maven build alone cannot establish service availability.

A finding such as “service reference unavailable after configuration reload” is actionable. A broad label such as “legacy code” does not explain what needs to change or how it will be verified.

These sources document product behavior. The design and validation approach above are engineering proposals, not claims made by the vendors.

• Adobe: upgrading code for AEM 6.5 LTS
• Adobe: mutable and immutable AEM Cloud package structure