Migrating to Composable Commerce Before Your Platform Reaches End of Life

Migrating to composable commerce means moving off a single, version-bound commerce platform onto one built from modular capabilities, such as catalog, checkout, content and search, that connect through APIs and update continuously. Most teams start the move for one of two reasons: their platform is about to lose support, or it has stopped keeping up with the business.

In 2026, the first reason applies to a lot of teams at once. SAP Commerce on-premise reached the end of mainstream maintenance on July 31, Adobe Commerce 2.4.6 left standard support on August 11, and Drupal 10, Umbraco 13, Kentico Xperience 13 and Sitecore XP 10.0 and 10.1 all lose support in December.

If either reason applies to you, a migration project is already on next year's plan. What's left to decide is where it lands, and how to make sure the next platform doesn't hand you the same deadline.

End-of-Life Dates for Commerce and CMS Platforms in 2026

Start with the version each of your stores and sites actually runs in production, then find it below. Each date links to the vendor's own lifecycle page.

HCL Commerce publishes end-of-support dates by version and fix pack in its product lifecycle search. Check the release you run before you set next year's budget.

What changes on the day support ends

The site keeps running. What stops is the vendor's side of the arrangement: new security fixes, compatibility updates for the PHP, Java or .NET versions underneath, and access to the support desk. Every vulnerability found after that date becomes your team's problem to patch, mitigate or accept.

For a commerce site, that has a compliance edge. PCI DSS v4.0.1 requirement 6.3.3 expects patches for critical vulnerabilities to be installed within one month of release. Once the vendor stops releasing patches for your version, meeting that requirement for any system in PCI scope depends on workarounds your team builds and maintains.

What to Do First When Your Platform Is Losing Support

Before you speak to a single vendor, get four things straight. They set your budget, your timeline and how much room you have to negotiate.

1. Confirm what you actually run

List every store and site, the version each one runs in production, and the support dates that apply to it, including any extended or security-only period. Estates with several sites often run more than one version, and the oldest one sets your deadline.

2. Price the upgrade realistically

Staying on the same platform is also a project. An upgrade means auditing and rebuilding custom code, checking every extension or module for compatibility, and retesting integrations with ERP, PIM, payments and search. On Drupal, custom modules are reworked at every major version, which we cover in Migrating to Drupal 12. Moving from Kentico Xperience 13 to Xperience by Kentico is a rebuild on a new architecture, covered in Kentico alternatives for multi-property operators. Set that figure against the cost of a move. The gap is usually smaller than teams expect.

3. Decide whether you need extended support

Extended support keeps a version patched for a set period. It adds no new features, and what it includes varies by vendor:

• Adobe Commerce gives 2.4.6 and 2.4.7 customers a further year of quality and security patches for the core application at no extra cost.
• Kentico Xperience 13 receives security hotfixes only through the end of 2026.
• Sitecore XP 10.0 and 10.1 no longer include production incident help in extended support from June 1, 2026.
• SAP Commerce 2205 moves to customer-specific maintenance, with no new on-premise releases.

Use the extended period as the window to migrate in, and check whether your extensions, hosting images and language runtime are covered too, since they often lose support on their own schedules.

4. Work back from your change freeze

Many retailers freeze code changes from October or early November until after the holiday peak. For a platform that loses support in December, testing, content migration and cutover either finish before the freeze or move to the first quarter of the new year, with extended support or a hardening plan covering the gap. Decide which path you are on now, while there is still a choice.

What Teams Miss in an End-of-Life Migration

The platform switch is the visible part of the project. The problems that surface after go-live usually come from things nobody listed at the start. Check these before you sign anything:

• Custom code nobody documented. Years of patches and workarounds often live only in the codebase. Inventory it, and separate what serves the business from what exists to make the old platform behave.
• Extensions with no equivalent. Marketplace modules for tax, shipping, loyalty or B2B pricing may have no direct replacement. Each gap becomes a configuration, an integration or a build, and each has a different cost.
• Integrations with ERP, PIM, tax and fulfillment. These carry your business rules. Map every data flow and its owner before you choose a migration approach.
• Customer passwords and stored payment tokens. Password hashes and saved cards may not transfer. Plan for password resets or a token migration with your payment provider, and tell customers early.
• Gift card balances, store credit and order history. Customers notice straight away when these go missing. Reconcile them before and after cutover.
• Redirects and search rankings. Map every URL that earns traffic or links. Google's site move guidance recommends keeping redirects in place for at least a year.
• PCI scope. How the new checkout handles card data decides which PCI DSS self-assessment applies to you. Confirm it with the vendor and your payment provider early.
• Contract notice periods. License, hosting and agency contracts often renew automatically and need months of notice. Find those dates before you set a cutover.
• Governance across sites and brands. If several teams publish to several properties, the new platform has to carry roles, approvals and shared components across all of them from day one.

The 47-point eCommerce platform migration checklist covers each of these in detail, with the data objects, SEO steps and go-live tests that go with them.

Your Alternatives When a Platform Reaches End of Life

There are three broad paths off a platform that is losing support. None is a tier above the others. Each one optimizes for something different and asks something different of your team.

• Your vendor's next product. Optimizes for continuity with a vendor you know, whether that is SAP Commerce Cloud, Xperience by Kentico, Sitecore's SaaS products, or the next Drupal or Adobe Commerce release. It asks for a rebuild or a major upgrade anyway, and you stay on the vendor's lifecycle.
• A DIY composable stack. Optimizes for choosing a separate vendor for each capability, such as commerce, content, search and payments, and connecting them through APIs. It asks for an engineering team that can own the integration layer and manage several vendors' roadmaps and contracts.
• A unified platform that is composable by design. Optimizes for having the essentials, CMS, commerce, payments, search and personalization, on one platform, extended through APIs wherever you need a specialist service. It asks you to work within the platform's core model and integrate everything else.

If you are weighing a specific platform, we have written guides for teams in that position: Kentico alternatives, why businesses are leaving Sitecore, migrating to Drupal 12, Salesforce Commerce Cloud alternatives, Adobe AEM alternatives and Contentful alternatives.

How to Make Sure Your Next Platform Doesn't Reach End of Life

Our view is that an end-of-life date is the worst position an enterprise can be in with a platform vendor. The vendor sets the date. The vendor decides what the next version looks like, what carries over and what has to be rebuilt. The vendor prices extended support, knowing the customer has a deadline. The enterprise funds a project it didn't plan, on a timeline it didn't choose.

The 2026 dates show how this plays out:

• SAP stopped new on-premise releases of SAP Commerce, so on-premise customers move to SAP's cloud product, rely on customer-specific or third-party maintenance, or leave.
• Kentico replaced Xperience 13 with Xperience by Kentico, a new architecture, so staying with the vendor means a rebuild.
• Sitecore changed what extended support includes from June 1, 2026, part-way through the remaining support window for XP 10.0 and 10.1 customers.
• Drupal and Adobe Commerce run on fixed release cycles, so the next deadline is already on the calendar the day an upgrade finishes.

None of this reflects on the teams running these platforms. It is how version-based software works: every major version eventually loses support, and the customer carries the cost of moving off it.

Questions to put in your RFP

Ask every shortlisted vendor the same questions, in writing:

1. Do all customers run on the same codebase, or do different customers run different versions?
2. Does the platform have major versions with published end-of-support dates? Where is the lifecycle policy?
3. How are updates delivered, and what happens to our configuration, integrations and custom components when they are?
4. Is there a charge for extended support, and what does it cover?
5. How do we export our content, product, customer and order data if we leave?
6. Which new capabilities from the last 12 months reached every customer without an upgrade project?

If a vendor's answers include version numbers and support dates, your next end-of-life project is already scheduled. Our CMS and eCommerce RFP templates give you the rest of the questions to sit alongside these.

How Core dna answers them

Core dna runs every customer on the same codebase, with no product versions to maintain. When the platform improves, every customer gets the update, including security patches, performance work and new capabilities such as the Core dna MCP server. There is no version 13, no release 2205 and no end-of-life date for a customer to be left on.

Flexibility sits on top of that shared core. Each customer's content models, layouts, workflows, integrations and third-party services are configured on the platform and connected through APIs, so the composable layer is specific to the business while the core stays common to everyone. That separation is what lets the platform update continuously without asking customers to rebuild what they have configured.

The result is the operating model enterprises want from SaaS, continuous updates and no upgrade projects, with the stability of staying on the same platform for years.

What a Modern Commerce Platform Looks Like

Use these as the bar for your shortlist.

Content and commerce on one model

Product data, pricing, promotions and content share one model, so a product page, a campaign page and a feed all draw on the same records. Teams update catalogs, pricing and pages in one place, and customers see the same information on every channel. For teams running a separate CMS beside a commerce engine, consolidating content and commerce also removes a second set of version upgrades and support dates.

Composable where you need it

The essentials come built in, and APIs, webhooks and integrations connect specialist services such as ERP, PIM, tax or search where they add clear value. Orchestration across those systems happens inside the platform, without a layer of custom middleware to maintain.

Continuous updates

Security patches, performance improvements and new features arrive as part of the service, with no upgrade project to schedule and no version to fall behind on.

Governance across every property

Roles, approval workflows and shared components apply across every site, brand and region, so local teams publish within limits the central team sets. See how this works for multi-brand retailers and multi-location operators.

Capacity for peak trading

Infrastructure scales horizontally and vertically with demand, so seasonal spikes are handled by the platform and don't need a project of their own.

Core dna is built to this model, with CMS, commerce, payments, search and personalization on one platform.

How AI Changes What You Need From Your Next Platform

Two questions belong in every platform evaluation now. Can AI assistants read your product data correctly? And can AI tools work inside your platform under the same controls as your team?

AI as a shopping channel

More shopping journeys now start in ChatGPT, Google's AI results and other assistants, which read your product pages, structured data and feeds to answer questions about price, stock and fit. The next platform has to keep that information accurate and consistent wherever it is published. Our guide to product feed optimization for AI shopping covers how to structure a catalog for these systems, and agentic commerce covers where buying through AI agents is heading. To see where you stand today, run the 15 product retrieval prompts against your own catalog.

AI working inside the platform

The second shift is AI tools that do the work: updating content, adjusting products and running checks across sites. Ask each vendor how that access is governed. On Core dna, the MCP server is off by default and enabled per user. An AI assistant inherits the permissions of the person using it, every action is logged against that user, and content changes can be staged as unpublished revisions for review.

We explain the difference between AI that operates a platform and AI that buys from it in agentic operations vs agentic commerce, and why we built our MCP server for marketers.

Plan the Move Around Your Support Date

To plan the move, work back from your support date:

1. Support end date for every version you run, including any extended and security-only periods.
2. Change freeze for your peak season, if you have one.
3. Cutover and post-launch support, with time to fix issues before the freeze starts.
4. Build, data migration and testing, including redirects and integrations.
5. Platform selection and contract.

The time between today and step five is your real decision window. Our step-by-step roadmap for migrating to composable commerce covers how to sequence the work, and you can see how a replatform with Core dna runs.

A consolidated move doesn't have to take years. Save a Life spent more than a year building its own certification platform before moving to Core dna. The first working prototype took a few weeks, and the full project went live in six months, including the migration, the LMS and all content, replacing WordPress, a standalone LMS and a separate eCommerce system.

Use the interactive checklist below to build your plan. Step 0 covers your support dates.