Why Is Replatforming on the Table Now?

Most replatforming conversations start because the business has changed or the current eCommerce platform has become harder to maintain.

In the replatforming evaluations we reviewed, five triggers came up most often:

• 43% included new business or commerce requirements the existing setup struggled to support
• 32% involved growth or scale pressure
• 25% involved fragmented systems, storefronts, or portals
• 18% involved vendor lifecycle or support issues
• 11% had an ERP change tied to the eCommerce platform migration decision.

These themes overlap. A growing business may also have accumulated several systems or introduced requirements the existing platform was never designed for.

Let’s look at the three most common eCommerce migration triggers more closely.

The business outgrew the original setup

A commerce setup can keep doing what it was built to do and still become a poor fit as the business changes around it.

Elsewhere, companies were adding subscription models, expanding internationally, or supporting much higher digital order volumes.

The commerce setup hadn’t necessarily failed. The job it was expected to do had changed.

The stack fragmented

In some cases, growth left companies managing several self-service portals or ordering systems at once.

Adding another integration may solve the next requirement. Over time, though, the bigger problem can become the number of systems, rules, and exceptions the team has to keep aligned. 

The MVP setup became the long-term platform

Some B2B companies start with a limited commerce setup to test whether customers will buy through an online store. That can work for an initial launch.

The problem comes when the experiment succeeds and the same platform is expected to support a much bigger job.

One HVAC/R distributor could handle the basics, but anything beyond them required paid custom functionality development. Customers still couldn’t see order status or credit limits online, and promotions had to be taken offline because the platform couldn’t apply them at checkout. What began as a practical way to get online eventually became the thing holding the next stage back.

A new requirement doesn’t automatically justify a new eCommerce platform, though. But several important requirements pushing against the same underlying architecture deserve closer scrutiny.

What Companies Tried Before Replatforming

The triggers above rarely lead straight to replatforming. Companies usually try to get more life out of what they already have first.

In our sample, at least one in three companies considering switching eCommerce platforms had already tried some form of extension or remediation. They customized the platform, added tools around it, changed integrations, or invested in keeping an older setup going.

Sometimes that works for years. The point is to understand what those decisions have added to the system along the way, and whether they are still helping the company deliver the business outcomes it needs.

They customized the platform itself

Custom development can be the fastest way to support a requirement the platform doesn’t handle well. The difficulty tends to surface later, when every new change has to account for what was built before it.

One manufacturer had customized its incumbent so heavily that upgrades had become difficult. 

At that point, customization affects more than development cost. It also affects how easily the company can upgrade, change direction, or eventually move to a new system.

They worked around gaps with other systems

Sometimes customizing the platform itself is not the easiest route. Companies add another system to handle the capability they are missing, then have to integrate it with the rest of the commerce stack.

One distributor added WordPress beside its homegrown commerce system because the original platform could not support the content management experience it needed. Over time, that meant maintaining another system and another connection between content and commerce.

Another manufacturer had accumulated enough technology around its operations that its own team called the result a “Frankenstein tech stack.”

A workaround may still be the most cost effective choice for a specific requirement. But once several accumulate, the team can end up maintaining the history of past decisions alongside the commerce platform itself.

When keeping the current setup becomes an investment of its own

Commerce systems rarely become unusable overnight. Teams keep funding them because they already contain years of integrations, custom logic, product data, and internal knowledge. Each fix makes keeping the current platform easier to justify than reopening the whole decision.

That can keep a system useful for a long time. It can also make past investment part of the reason the company keeps investing, even as the total cost of maintaining the setup grows.

One distributor was spending 75 hours every month maintaining its existing commerce site instead of building new capabilities. Another relied on a two-person agency to maintain a homegrown platform and described the setup as “not a long-term plan.”

At this point, past investment matters less than what the next investment will buy.

A few questions help make that clearer:

If those answers point to growing cost or dependency, the next step is figuring out what is creating it.

Where Is the Problem Coming From?

Replatforming is an expensive way to solve the wrong problem. A useful eCommerce replatforming strategy starts by identifying what is actually creating the constraint.

A commerce setup can be difficult to operate because the platform itself is limiting. It can also be difficult because of the implementation, integrations, product data, legacy systems, or internal processes built around it.

Before replacing the foundation or comparing what other platforms support, identify which of those is getting in the way.

Problems outside the commerce platform

Some commerce problems sit upstream of the platform.

One distributor said search was its number-one complaint. But the same SKU could have five different regional names, and there was no structured product-data system to manage those variations. Moving the same inconsistent store data to another platform would not solve the underlying issue.

The same company had another issue: branch employees regularly put online pickup orders behind other work. A better storefront could improve ordering, but it would not fix the sales process or how branches prioritize those orders.

Before blaming the platform, separate the problem by source:

A new platform can inherit the same problem if its source sits elsewhere. Separate those issues first, then look at what the commerce foundation itself can and can’t support.

How to tell when the eCommerce platform is the problem

A platform-level constraint usually shows up in a few ways:

If several of these are showing up at once, the commerce foundation itself deserves to be part of the replatforming decision.

Ciranda faced this with its first B2B portal, which ran on a platform built mainly for B2C. Within a year, adoption was low enough that leadership questioned whether eCommerce made sense for the business at all.

Low adoption can look like a problem with users, but the team investigated and found that buyers lacked order history and invoices, and the ERP integration only pushed orders one way.

Ciranda decided that continuing to customize the platform would only make the setup harder to manage, and chose to replatform.

What Are You Committing To If You Stay?

Keeping the current foundation avoids a replatforming project today, but it still comes with a roadmap of its own. Staying is a platform choice too. Before deciding, look at what the setup will ask from the business over the next few years and whether it still supports your business goals.

Price the next few years

Include the costs that tend to sit outside the platform license:

• Ongoing maintenance and specialist support.
• Upgrades and the work needed to keep customizations compatible.
• Custom development for capabilities the platform doesn’t support well.
• Additional tools or integrations needed to close gaps.

Then look at what that spending buys.

If the next few years are dominated by maintenance, compatibility work, and more fixes around the same gaps, staying starts to look less attractive.

One of the key benefits of staying is avoiding the disruption and cost of a platform change. But that benefit matters less if the old platform keeps absorbing budget that could otherwise go toward new capabilities.

Can it keep up with how commerce is evolving?

If you keep investing in the current setup, how much room does it give the business to change?

Look at the roadmap. If upcoming business requirements fit the way the platform is designed to work, staying may still make sense. If each meaningful change starts with custom development or another system around the core, the same cost pattern is likely to continue.

That matters especially when the business is adding new business models or more complicated B2B capabilities. Supporting custom pricing, for example, may be straightforward on one platform and a major customization project on another.

AI is another useful example. AI sales order automation or smart search depend on access to commerce data, pricing, and account rules. If the current platform makes that difficult, adopting those AI use cases will come with more integration work.

The same applies to more familiar changes such as entering another country, introducing subscriptions, supporting a marketplace model, or consolidating multi brand operations in one platform.

You don’t need all of the advanced features today. You do need confidence that you are still on the right platform for the direction the business is heading.

Bringing the Decision Together

By this point, the decision should come down to a few questions.

You don’t need every row to point in the same direction. Look at the pattern. If the same platform limits keep showing up across the roadmap, upgrade path, and cost of staying, the case for replacement becomes much stronger.

The business may have grown beyond the job the platform was originally chosen to do. What started as a practical first step can become harder to extend as the business changes and buyers expect more from digital commerce.

The decision comes down to fit: can the current foundation support the business you’re building now, or are you still designing around limits that were set when it was chosen?

Where to Go From Here

If you’ve decided the current commerce foundation needs to change, a new set of decisions starts. Should you build or buy? Which B2B platforms belong on the shortlist? How do you turn what you’ve learned into requirements and a migration plan?

Here are a few resources to help with those next decisions.

If you’re deciding whether to build or buy

AI has changed the development equation enough that custom commerce may deserve another look. But implementation effort is only part of the decision. Ongoing ownership, maintenance, and the ability to keep adapting the platform still matter.

Building vs. Buying B2B eCommerce in the AI Era is a complete guide to where AI changes the economics and where the long-term costs remain, with practical comparisons to help judge both paths.

If you’re starting a new platform shortlist

If the previous platform was a poor fit, start platform selection with what the market offers for B2B commerce today rather than carrying the old shortlist forward.

The B2B Digital Commerce Comparison Table  evaluates 12 major vendors serving large enterprise and midmarket B2B organizations and can help you narrow the field around the requirements that matter to your business.

If you’re ready to define requirements

Once you have a clearer idea of the type of platform you need, turn that into requirements vendors can respond to consistently.

Our B2B eCommerce RFP Template helps you document those requirements and see whether each vendor supports them natively, through customization, or through third-party technology.

Whichever path comes next, the work you’ve done here gives a successful replatforming a better starting point. You know why the current setup is under review and what the replacement needs to do differently.