Replatforming to Composable Commerce: Are You Leaving the Problem, or Only the Platform?

We’ve all seen the slide of a replatforming project that has just been approved with the title: “Reason for change: legacy platform.” It’s easy to approve because the old platform is everyone’s favorite villain, and it is easy to blame.

If you are leaving a platform now, or about to, you likely have good reasons. A homegrown system that only a few people still understand. A suite whose next major version means carrying everything you built across, at your own cost. And the reasons that make it into the business case: changes that take months when the business needs weeks, running costs that grow every year, and new markets or channels stuck waiting in the IT queue. Put together, they get a replatforming approved internally as a way out.

The question the business case rarely asks is a simple one: is the problem leaving with the old platform, or only the platform? Composable architecture isn’t the villain in what follows, and neither is any other model. The thing worth examining is a different one: what made your current platform expensive to change, and whether it can follow you into the next one.

1. COMMERCE PLATFORMS RARELY FAIL. THEY JUST BECOME TOO EXPENSIVE TO CHANGE.
2. WHY COMPOSABLE IS A LOGICAL PLACE TO GO
3. WILL IT COME BACK? THREE WAYS THE OLD PROBLEM RETURNS
4. THE MARKET ALREADY FEELS IT
5. WHAT BUYERS ARE ASKING FOR: NOT TO DO THIS AGAIN
6. WHAT WE SEE ACROSS OUR CUSTOMERS
7. THE QUESTION TO ASK BEFORE YOU REPLATFORM
8. ONE ANSWER TO THE LOOP
9. FIVE QUESTIONS FOR ANY PLATFORM, OURS INCLUDED

Few companies replace a commerce platform because it stopped taking orders. They replace it because every change started to cost more than the one before and changes in one place introduced problems somewhere else.

Anyone who has owned a platform for a few years will recognize the sequence. I call it a loop, because it runs the same way every time:

1. The business needs something the platform doesn’t do out of the box: a pricing rule, a product configurator, and a separate setup for each new market.
2. The team builds it where it is fastest to build, often inside the platform’s core or wired directly into another system’s internals.
3. The next upgrade has to carry that work across. Some of it breaks, and testing grows.
4. Upgrades get postponed, and the platform lags its own release path.
5. Each new change has to work around the older ones, so every feature becomes a project.
6. Eventually, the estimate to change the platform exceeds the estimate to replace it, or the risk that one more change will break another component becomes too high.

Step two is where the coupling forms: the change gets wired into something it shouldn’t touch. It looks harmless when it happens, and it decides how fast the rest of the loop turns.

The loop shows up in every model. What changes is where the coupling lives.

In a homegrown platform, it lives everywhere. A global photonics and optics manufacturer came to us after running a homegrown platform whose main architecture decisions were more than a decade old. Every new feature had become a project of its own. Keeping the platform secure took full-time internal effort. Two internal replatforming attempts had failed. When the team wrote down what success would look like, they asked for “a modern, extensible, externally supported platform.” Each of those words points at a stage of the loop they wanted out of.

In an enterprise suite, the vendor sets the clock. One suite supports each version for three years from release (Adobe Commerce lifecycle policy). Another’s final on-premises release left mainstream maintenance on July 31, 2026 (SAP Commerce on-premises maintenance). A third is moving to a new storefront architecture (Salesforce B2B Commerce, Aura-to-LWR migration), which means every legacy component must eventually be replaced. Whatever the customer built has to be carried across, at the customer’s cost. For one manufacturer we later worked with, upgrading its legacy platform would have cost about 60% of a full replatforming and still left key limitations unresolved.

In SaaS, the vendor decides what may change, and can change its mind. Updates are built for the whole customer base, so they follow the vendor’s assumption of what you need, not your own roadmap. SaaS also keeps a platform coherent by limiting what customers can modify, and that permission can be withdrawn. A leading SaaS commerce platform switched off its original checkout customization method for in-checkout pages on August 13, 2024 (Shopify checkout.liquid deprecation), and merchants had to rebuild those customizations in the vendor’s new framework, on the vendor’s timetable. For some businesses the limit shows up before they even sign. An online retailer we work with had seen its previous platform discontinued by its vendor. When it replatformed, it ruled out a leading SaaS platform because it lacked the technical depth and self-hosting the business needed.

Three models, three places for the coupling to live, one mechanism. Most teams know it by its symptoms long before they name it: the update they are afraid to run, and a platform that gets more expensive to change the longer they own it.

If coupling is the problem, composable commerce looks like the direct answer and in many ways, it is. Capabilities sit behind APIs. Each one can be chosen for fit and replaced on its own. Search doesn’t need to know how pricing is calculated. A new storefront doesn’t require a change to order management. For a team that has spent years working around one tightly wound system, that separation is the right instinct.

It fits best where the business really is different from the template: large and sophisticated catalogs, negotiated pricing per account, many markets and routes to market, deep ERP integration. Those businesses tend to outgrow packaged platforms first, and they have the most to gain from choosing each part.

What buyers tell us they value is more specific than the freedom to assemble. One buyer required that components such as CMS, search or personalization could be deployed and replaced easily. Another one required that new business models could be added later without a major platform redesign. Being able to replace one piece without destabilizing the rest may be worth more than the freedom to pick every piece on day one, because most of the time, you simply can’t know. Real freedom is to know you are able to change and grow as the business changes and you are not locked.

So the destination makes sense. The open question is what travels with you.

A composable platform can still run the same loop. When it does, the old problem usually returns in one of three forms, each moved to a new place.

Higher costs, on a different budget line. License costs may fall. In their place comes the running cost of assembly: integration, orchestration, DevOps, and a team whose job is keeping the parts compatible. That cost is hard to see at selection, because it is paid later, by a different team, under a different budget line. Some buyers already price it in. One told vendors not to propose composable or headless architectures unless they could justify who would run them, the staff and support they need, the upkeep of their integrations and their total cost.

Over-customization, moved out of the core and into the glue. The customization that used to live inside the suite now lives in middleware, integration code and custom services around the parts. It is still custom code the business depends on. Now it is spread across several vendors’ APIs, and no single upgrade path covers it.

Rigidity, moved to the seams. Each vendor versions its own APIs and tests its own product. Nobody tests the combination, and the combination is what you run. A change that touches several parts waits on several release schedules. In research published in 2026 on AI adoption across composable stacks, the MACH Alliance, the industry association for composable technology, found that 37% of 600 enterprise technology decision-makers named integration complexity as a primary concern.

An illustrative example makes the pattern easier to see. This is a composite, not a real company. A retailer assembles search, PIM, payments and CMS from four vendors. Two of them ship releases four weeks apart, and each changes an API the others rely on. By the end of the year the retailer has a team of four whose main job is maintaining a compatibility matrix. None of the four products is at fault. The cost lives in the combination.

None of this is inevitable. A composable stack avoids it when someone decides, early and on purpose, the questions that trapped the old platform: where customization is allowed to live, what integrations can depend on, and who answers for the whole once it starts changing. The loop doesn’t care what the architecture is called. It cares where coupling is allowed to form, and who holds the whole together as it changes.

Composable-first vendors now sell pre-composed packages (Elastic Path): sets of capabilities integrated in advance so a customer can launch without stitching the parts together. Some now argue it in so many words: composable isn’t the goal, pre-composed is (Chord Commerce). It’s a sensible move. It is also an acknowledgement, from inside the composable camp, that assembly is the burden.

Pre-composed solves the launch. Read the definitions closely, though, and none of them says who keeps the system working together as it is changed and upgraded. That is exactly where the loop turns: in year three, after the fortieth change, in the month two vendors ship at once. Launch is when a platform is easiest to keep coherent. The years after are when that gets tested.

The clearest signal comes from buyers themselves. In the requirements buyers send us, the same two asks keep showing up in a single document: the ability to keep extending and changing the platform, and a vendor that runs it or keeps it upgradeable. The market usually treats those as a trade-off.

The details read like lessons from a previous platform, written into the next RFP. Some require customization to stay out of the platform’s core. Others reject any proposal that bends their workflows to fit out-of-the-box templates. And some make upgradeability a requirement in its own right: how far behind the current release they can stay and still be supported, the right to defer updates, and upgrades that land with minimal impact on the organization.

These buyers aren’t choosing between depth and stability. They want both, and they’re putting it in writing.

From where I sit, I see the loop in many customers’ before stories. In some of them I have also watched it stop. What follows isn’t a list of success stories, it’s what it looked like years later.

The photonics manufacturer I mentioned earlier is a clear before-and-after. About seven months after going live, it moved its four-region production deployment to a new major .NET long-term-support runtime without downtime. The 90% of the solution built on standard modules upgraded by following the migration guide. Its four custom modules took a few days. After validation in three environments, the cutover took 21 minutes. The rollout ran one region at a time, each with health checks and a go/no-go before traffic moved, designed by our cloud team together with the implementation partner.

As a previous architect, I don’t find the 21 minutes the most important number. What matters is that the effort followed what had been customized, not the size of the solution.

Longer timelines show the same thing over more years:

• A global manufacturer’s order platform went live one country at a time. New markets were added every year from 2018 to 2024, across four regions, all on the same shared solution.
• An online retailer serving consumers and businesses has built a heavily customized solution with its own team for more than seven years, and has kept taking platform updates throughout.
• A long-standing travel and mobility commerce customer, after about nine years with us, built a new business without replatforming. It upgraded the platform it already had and built the new solution on it.

Then there is change nobody planned for: one of a purchasing organization’s most important growth features was not on its original roadmap: a way for buyers to reach several suppliers at once. It has become one of the organization’s main sources of new business. A platform that stays changeable matters most for this kind of change, the kind no selection process could have scored.

That work is sized to what was customized, and it isn’t free. Replacing one component inside a running solution is something I can show only in part so far. A Canadian aircraft manufacturer is moving its content management onto our platform in phases: new content is created there, while about 200 legacy pages migrate over time instead of in a single cutover. That is a phased move onto a platform, and not a swap inside a running one.

Most replatforming decisions are framed as a choice of architecture: suite, SaaS, composable, or build. The loop suggests a different first question. Will this platform stay changeable?

Two tests matter more than the label. Does the platform hold together while it is being changed? And will the tenth change cost close to the first?

Map today’s options on two axes, how deeply you can change the platform and who holds it together as it changes, and a pattern appears. Each model gets one and pays with the other.

SaaS stays coherent by limiting what you can change. Homegrown platforms, suites and assembled stacks allow deep change and hand coherence to your team: in a suite, at every upgrade on the vendor’s clock; in an assembled stack, at every seam between vendors.

Is that trade-off a law, or a result of how these systems were built? The buyers whose requirements I described above are asking for the empty cell, in writing.

So, getting back to the question: “is that trade-off a law?” I don’t think so. It comes from where coupling is allowed to form and who holds the whole together as it changes, and both of those can be designed. Three properties make that possible, and you can check each one without taking our word for it.

• The seams are checked, not trusted. Every module declares which platform and module versions it works with. The platform checks the whole installed set, custom modules included, each time it installs or starts. A combination that doesn’t hold is refused rather than half-loaded. That covers our own contracts; third-party libraries sit outside them.
• Customization stays off the upgrade path. Customizations attach to modules through extension points instead of editing them, so a platform update flows in around them. The default update is a version change and a re-test, not a rewrite. The larger steps, such as a new major runtime, are named in advance and come with migration notes.
• Breaking changes arrive explained. Stable releases pass full regression, end-to-end and load testing before they ship. When a release does change a contract, it ships with migration guides, so a breaking change arrives explained instead of being discovered.

This is what puts a platform in the empty cell. Deep change is permitted, and coherence is held by the platform instead of being handed to your team. Effort at upgrade time follows what you customized, not the size of the solution.

At Virto Commerce, we call this a managed composable platform. It is our own term. No analyst maintains it, this is in a nutshell what we mean by it:

It has two halves. The first is the set of properties above, which come from how the platform is built. The second half is operational responsibility, and that part is a service. On Virto Cloud, we run the platform underneath the customer’s solution: we provision and scale the supporting services, keep them highly available across regions, monitor every environment and deploy platform updates. The customer keeps ownership of its architecture, integrations, customizations and business logic. It doesn’t have to be all or nothing. One B2B distributor runs its commerce platform and search with us, while its homegrown ERP and its own customer portal stay on its own infrastructure, connected through the platform’s APIs. This half answers the first way the old problem returns: the cost of running the platform doesn’t land on the customer’s team.

Some boundaries matter as much as this idea:

• Upgrades still take work. For the photonics manufacturer it was a few days for four custom modules and validation across three environments. Sized to what was customized, not free.
• We own our contracts. You own what you build on them. Third-party libraries sit outside both.
• The property doesn’t depend on who hosts it. A manufacturer’s loyalty portal for professional installers has run on our platform since 2017, with the customer’s own team building the front end and keeping control of DevOps and infrastructure. It has grown from 5,000 orders in its first year to more than 35,000 a year, across 50+ brand-country combinations. That customer runs the operational half itself, and the property holds.
• No guarantee stands behind this. It rests on the architecture, which is why the architecture is what I would ask you to examine.

I don’t think the lesson here is “don’t go composable.” Go, if it fits your business. Go knowing what you are leaving. A replatforming is a chance to review what works and what doesn’t in how you run the business today, before you build the path to the new platform. New technology won’t fix what that review would have found.

Before you commit to any target platform, ask yourself:

1. Where will our customizations live, and what happens to them at the next upgrade?
2. Who keeps the combination working, not just each part?
3. Will the tenth change cost close to the first?
4. Who runs it, and on whose budget?
5. Can we replace one piece without a new program?

Look for the answers in how the platform is built and in what its customers’ later years look like, not in the launch demo. That test applies to us as much as anyone.

A replatforming buys you a new launch day. What you are really choosing is the years after it. So before you sign: are you leaving the problem, or only the platform?

Ricardo Lopez is Director of Client & Product Solutions at Virto Commerce. A former solution architect, he has worked on digital commerce replatforming projects from the inside and now works with manufacturers, distributors and multi-entity businesses on how their platforms hold up in the years after launch.

• How Bosch runs its installer loyalty portal on Virto Commerce
• How a Canadian aircraft manufacturer is moving its content management in phases
• Why Embroidery Designs chose depth over a SaaS platform