When keeping the platform is the right decision

I have been in plenty of rooms where everyone agreed the platform had to go. Ask what it cannot do and the agreement gets fuzzy fast.

Sometimes they are right. Sometimes the old platform is just where years of integrations, process, and organizational decisions have accumulated. Replacing it gives those problems a new home. It does not necessarily solve them.

Old is not the same as broken.

Start with the actual problem

“The platform is old” tells me almost nothing.

What can the business not do? What costs too much? Where does work slow down? Which change takes months when it should take days?

Then ask whether the platform is causing it.

Sometimes it is. Sometimes the real constraint is an integration nobody owns, a painful release process, a data model shaped by years of exceptions, or a company that cannot make a cross-functional decision. Replacing the commerce platform will not automatically fix any of those things.

I usually want to see something like this:

Claim	Evidence to request
The platform is too expensive	Total operating cost, not just the license
It prevents growth	Specific blocked capabilities and the revenue or operating consequence
It is too slow to change	Lead time by change type and where that time is actually spent
The architecture cannot scale	Load, bottlenecks, failure modes, and forecast demand
The team cannot support it	Skills, ownership, attrition risk, documentation, and vendor dependency

If the evidence is thin, that does not mean the current system is good. It means there is not a replacement case yet.

The estimate is not the cost

The implementation estimate is the easiest number to see. The real cost also includes migration, parallel operations, retraining, process change, integration work, search recovery, analytics continuity, content, and everything else the company delays while the program is underway.

Another easy thing to miss: the current system probably has mature behavior nobody talks about because it works. That behavior has to be found, understood, and rebuilt, or deliberately dropped.

This is why I usually want to compare more than “keep it” and “replace it”:

1. Keep the platform and remove a specific constraint.
2. Stabilize now, then replace in a deliberate sequence.
3. Replace a bounded layer rather than the whole estate.
4. Replace the platform and fund the operating change around it.

Those paths have different costs, risks, and timing. Put them next to each other and the tradeoffs become much easier to discuss.

When I would replace it

I would move toward replacement when:

• The system creates a material business constraint that cannot be removed at a reasonable cost.
• Operational risk is concentrated in unsupported technology or skills the company cannot retain.
• The architecture blocks the next business model, not just a nicer feature list.
• Incremental repair costs more than a sequenced transition.

I would also look at timing. Keeping the platform may be reasonable now and expensive two years from now if the window for an orderly transition is closing.

I am not arguing that old systems should live forever.

I just do not want a company to spend two years and a lot of money rebuilding the same problem in newer technology.