Adobe Experience Manager End of Life: What It Means for Communications-Generating Teams in Banking and Insurance

Any communications operations lead or manager who has kept a legacy platform running beyond its prime is at risk of being caught out by the next situation. The system never announces its own decline; it just keeps working, with workarounds constantly being added, right up until the vendor sets an end-of-life date. This changes the whole conversation.

That is where Adobe Experience Manager (AEM) 6.5 finds itself now. The statements still render, the policy letters still go out, and the platform behind them has done nothing wrong. Adobe has simply given it a leaving date. For teams in banking, financial services, and insurance (BFSI) generating client communications on AEM Forms, a single line on a support roadmap turns a quiet piece of infrastructure into a budgeted decision with a deadline attached.

This is what AEM end of life actually means in practice: AEM 6.5 end of support closes on a fixed date, and Adobe’s own documentation already shows where AEM Forms and customer communications on AEM are heading next, whether that is AEM 6.5 LTS or the cloud.

This article sets out what is actually ending, where the product is heading, and what the 2 realistic paths look like for BFSI communications teams weighing their options. Choosing between those paths is a separate conversation; the job here is mapping the terrain before the deadline forces a rushed one.

What exactly ends on Adobe Experience Manager?

This particular deadline belongs to AEM 6.5. What ends on Adobe ecosystem are Adobe’s on-premise and Adobe Managed Services (AMS). AEM as a Cloud Service (AEMaaCS) sits on its own separate release cadence, so this clock does not touch that part of the product line.

AEM Sites, the web content and digital-experience side of the platform, and AEM Forms, the module BFSI comms teams actually rely on most for statements, policies, and correspondence, are worth separating too. Both fall under the same support deadline, though the operational stakes concentrate heavily on Forms.

When does the AEM support end?

According to Adobe’s release roadmap, service pack 6.5.26.0 is the last supported service pack for AEM 6.5. Support for AEM 6.5 on Adobe Managed Services ends 31 August 2026, and core support for on-premise AEM 6.5 customers is currently planned to close on 28 February 2027 – roughly 18 months after that final service pack.

Beyond that date, Adobe continues the 6.5 line through AEM 6.5 LTS, a long-term support branch built on Java 17 and 21 in place of the ageing Java 8/11 baseline.

We don’t do comparisons here. In turn, each one is worth rechecking against Adobe’s current release roadmap before it goes into an internal timeline, since roadmap wording can shift.

Why Does AEM Support End Now?

The root cause traces back to Java. AEM 6.5 runs on Java 8 and Java 11, and both versions left Oracle’s public support behind in 2023, continuing only under paid extended support since then. Adobe’s own timeline for AEM 6.5 simply tracks that underlying Java lifecycle – an inherited deadline more than a fresh decision about the product’s future.

For anyone outside the engineering team, the short version is simpler. The software AEM 6.5 depends on is losing vendor support, so the platform needs to move onto newer foundations too, either through the LTS upgrade or into the cloud service, which already runs on current Java versions. A support-end date, in that context, works as a fixed horizon for planning rather than a verdict on how the system is running today.

How AEM Forms 6.5 End of Life Influences Customer Communication Management Workflow?

For teams running customer communications on AEM Forms 6.5, 28 February 2027 does not stop documents from being generated, but it ends standard support unless they upgrade to AEM 6.5 LTS or migrate to the cloud.

AEM Forms as a Cloud Service can generate personalised statements, invoices and letters through real-time and batch APIs, while the browser-based Interactive Communication Editor provides a newer way to design print and digital communications.

However, moving existing Forms workloads is not a lift-and-shift: organisations must assess templates, XDP assets, business rules, integrations, workflows and output fidelity. The new editor should therefore not be described as a complete replacement for the Windows-based Designer without verifying the organisation’s specific use cases and feature requirements. For BFSI teams, the deadline creates an immediate need to choose between the lower-disruption AEM 6.5 LTS upgrade and a broader cloud migration whose communications capabilities must first be tested against the current estate.

Adobe’s documentation point: Cloud. Whatever it takes.

Adobe’s release notes point firmly toward the cloud. AEMaaCS now ships on a monthly feature-release cadence rather than the quarterly service-pack model built into 6.5: the 2026.5.0 feature release landed on 28 May 2026, with the following release confirmed for the month after. Recent releases show ongoing work on Edge Delivery Services, AI-assisted authoring, and closer integration with the wider Experience Cloud stack – Target, Experience Platform, and Journey Optimizer – alongside forward-looking Java runtime upgrades already being communicated for AEMaaCS itself. Inside that picture, AEM 6.5 LTS reads as a stable bridge for teams not yet ready to move, rather than a lasting second home for the platform.

The AEM as a Cloud Service (AEMaaCS) direction

For teams that mainly need the web and forms front end, this direction already looks fairly mature. Cloud Service has carried production workloads for several years, and Adobe’s own migration guides and acceleration tooling are built around it.

AEM Forms as a Cloud Service

For the AEM Forms and customer communications management side that banking & insurance comms teams rely on, the picture reads more like a documented direction still finding itself in. AEM Forms as a Cloud Service supports 2 core use cases, Digital Enrollment and Customer Communications, and Adobe has been rolling out an Interactive Communication Editor: a browser-based tool for building data-driven correspondence such as statements, bills, and benefit notices, replacing the older Windows-only Designer application. Several adjacent capabilities, including certain Experience Platform connectors and document-assurance APIs, sit under Adobe’s Early Adopter programme at the time of writing. Functional parity with the current on-premise Forms toolset is worth verifying directly against Adobe’s live documentation.

What Does This Mean for BFSI Communications Teams?

For banks and insurers using AEM Forms, the support deadline brings a practical decision: does the next investment in Adobe still make sense for the organisation’s customer communications?

The existing platform may continue to produce statements, policy documents and renewal notices reliably. But the cost of maintaining a supported environment now needs to be considered alongside what the business needs next: faster changes to approved wording, simpler template management, multilingual correspondence or more consistent delivery across print and digital channels.

That assessment starts with the communications already in production. A policy document may depend on data from several systems, country-specific clauses, approval workflows and archive connections. These dependencies determine how much work an upgrade or migration will involve—and which capabilities the target platform must preserve.

Adobe documents functional differences between AEM 6.5 Forms and Cloud Service, including differences in document services and migration tooling. Their significance depends on which features the organisation actually uses. A documented limitation becomes a business concern when it affects a required communication or production process.

Cost needs the same level of specificity. Adobe provides customised pricing, so there is no reliable blanket conclusion that staying or moving will be cheaper. A meaningful total cost of ownership comparison includes licensing, implementation, integration work, testing, training and ongoing operations. Where a transition requires parallel production, that belongs in the budget too.

If keeping customer communications on Adobe requires substantial rebuilding, it is worth comparing alternative CCM platforms before approving that investment. The comparison should establish whether another platform offers a better fit for the same requirements, after accounting for its migration costs and risks.

Paths forward

The decision involves three possible routes: upgrade to AEM 6.5 LTS, migrate suitable workloads to AEM Forms as a Cloud Service, or evaluate another CCM platform. Each should be assessed against the same communications requirements, operational constraints and planning horizon.

AEM 6.5 LTS: continue where the existing platform still fits

LTS provides a supported continuation of the 6.5 line on newer Java foundations. It can be a reasonable choice where the existing communications environment meets business needs, and retaining it offers a proportionate route forward.

The upgrade still requires assessment. Adobe notes that some legacy features and artefacts have been removed and recommends checking the impact on customisations and integrations. Teams should validate the document production processes affected by those changes.

The business case should also distinguish platform maintenance from improvements to the existing implementation. If duplicated templates or poorly documented rules already slow down customer correspondence changes, those issues may need separate work.

LTS does not have to be a temporary stop. But where a later migration is already planned, its cost and timing should be considered alongside the upgrade, including any work that would need to be repeated.

AEM Forms as a Cloud Service: establish the fit before committing

Cloud Service offers managed infrastructure, automatic scaling and ongoing updates. For an existing customer communication operation, the assessment is whether its document services and working practices can support the required communications with an acceptable level of adaptation.

Migration tooling covers specific assets and deployment models. Adobe’s Forms migration guidance describes a route from Forms on OSGi and excludes Forms on JEE content migration through that route. Establishing the current setup is therefore an early scoping task.

A proof of concept should test representative communications: a high-volume statement run, a multilingual policy with conditional clauses and a letter requiring manual review. The assessment should cover output accuracy, business rules, approvals, applicable accessibility requirements, delivery and archiving.

The result should be a scoped transition plan: what can be reused, what needs adaptation, what remains unresolved and how much effort the move requires.

Another, dedicated CCM solution: compare against the same requirements

Where the Adobe route involves substantial redevelopment, an alternative CCM assessment can help determine whether that investment would deliver greater value elsewhere.

The alternative needs to prove its case on the same documents, production volumes and business processes. Useful comparison points include the effort required to maintain templates, implement wording changes, manage approvals and operate integrations, alongside the full cost of migration and support.

Moving away from Adobe also introduces transition risk. A convincing case therefore needs evidence that the target platform improves the organisation’s position enough to justify that work.

A focused comparison can begin with the most demanding communications and a defined set of acceptance criteria. This gives the team a basis for deciding whether a broader evaluation is warranted.

The takeaway

The AEM 6.5 support deadline is a reason to reassess the next investment in customer communications. It does not, by itself, establish that Adobe is the wrong platform.

LTS may remain a sound fit. Cloud Service may offer benefits that justify the transition. Where either route requires substantial work, another CCM platform deserves consideration before the budget is committed.

The decision should rest on what each option can demonstrate: reliable document production, manageable change processes and a credible total cost over the years ahead.