By Antons Sapriko
As legacy commerce systems become harder to maintain, retailers must rebuild critical infrastructure without disrupting the operations that generate revenue.
Many retailers are reaching a point where legacy commerce systems no longer support the speed, visibility, and operational control modern business requires. The article explores how organisations can rebuild critical infrastructure without interrupting day-to-day operations. Antons Sapriko examines the warning signs, common mistakes, and practical steps involved in large-scale commerce transformation.
Across Europe, many retailers are operating on systems they have outgrown. These platforms still process orders, support stores, and connect to warehouses, but they do not provide a consistent or reliable representation of the business. Data is fragmented and integrations still require manual intervention.
At the same time, any changes involve substantial risk. The business cannot pause, so any rebuild has to happen while the system remains in use.
Preparing for change and identifying the signs
The primary difficulty, and where most companies make costly mistakes, is executing the rebuild without disrupting the operations that generate revenue. However, there is also a timing element, because three pressures are converging.
Investors are asking for measurable progress on AI. Competitors with faster systems are gaining share. And the cost of operating legacy platforms is becoming visible in financial results.
Revenue can grow, but the company starts making losses, and no one understands why. At that point, the business becomes a hostage of its own systems.
Costs increase across departments without a clear understanding of what is driving them or how they relate to value creation. The organisation loses visibility across its own operations, which causes more signs to appear in day-to-day work.
These are clear: manual workarounds increase, or teams export data from one system, adjust it, and upload it into another. These processes are rarely documented and often depend on specific individuals. When that person leaves, the process breaks.
When systems don’t work, people start doing things manually. Files move between systems, scripts are used, and processes depend on specific individuals. That’s a major red flag.
Think about this. In many organisations, preparing and reconciling data can take up to 80% of the time spent on analytics and operational reporting.
At the same time, data is inconsistent across systems. Products are named differently and customer data is fragmented.
A product’s purchase price may change in the ERP, while the website continues to display the old price because there is no structured process to sync updates. In some cases, companies may continue selling items that are out of stock, or fail to sell items that are available. This creates operational inefficiencies and affects customer trust.
Why companies wait, and what it costs
Most retailers continue operating under these conditions because the system still works at a basic level. Orders are processed, and revenue continues. The cost of the system’s limitations is distributed. It appears in additional work, in delays, and in errors across different teams. But because it is spread out, it is not always treated as a single problem.
Additionally, the financial aspect of it is often underestimated. Poor data quality alone is estimated to cost organizations an average of $12.9 million per year, much of it embedded in inefficiencies that are never tracked as a single line item.
A rebuild requires a defined investment and clear ownership. In many organisations, neither is present. Hence, companies extend the existing system instead of restructuring it.
Intervention typically happens when the impact becomes visible at the financial level or escalates to the board. By that point, inefficiencies have accumulated across the organisation, and the rebuild becomes more complex and more expensive.
The most common mistakes companies make
When companies decide to act, the initial focus is often misplaced.
Sometimes, companies think improving user experience means redesigning the interface and allocating budget only to that. That’s the first mistake.
Why? Because they ignore the budget for data cleanup, integrations, and reviewing integrations.
For example, showing real-time stock availability requires consistent data across ERP systems, warehouses, and stores, as well as reliable integrations and, in some cases, middleware. Without addressing these elements, interface improvements do not resolve the underlying issue.
Another common mistake is attempting to rebuild everything at once. Companies pursue large, complex transformations that aim to replace the entire system in a single step.
In practice, complex systems do not work when built this way. They require incremental validation. The result is often a project that is technically ambitious but disconnected from how the business actually operates.
You can build something complex that doesn’t work, which is completely useless.
A third mistake is attempting to pause the business to accelerate the transition. Even if it were possible to stop operations for a short period, it removes the primary source of validation.
Systems built in isolation may function technically, but fail when exposed to real world conditions.
How to sequence a rebuild while the business keeps running
The first step to a more effective approach is to identify and protect revenue-critical flows, such as checkout, pricing, ordering, and fulfillment. These cannot be disrupted during the rebuild.
Stability requires defined controls. Monitoring, testing procedures, and rollback mechanisms need to be in place before changes are introduced. It is not sufficient to assume that these areas will continue to function.
The next step is to structure the rebuild by domain. Instead of treating the system as a single unit, it is broken down into areas.
In complex systems, dependencies define what you rebuild first, addressing foundational domains initially.
For example, stabilising inventory is a prerequisite for improving order accuracy or customer experience. Starting with areas like user interfaces or customer service does not produce meaningful improvements if the systems underneath remain inconsistent.
Each domain is tested and validated in isolation before moving to the next. Testing is continuous. A typical sequence includes a proof of concept, followed by iterations based on feedback, then a pilot rollout in a limited environment such as a single country or a small number of stores, and finally a gradual expansion. Each iteration takes place over days or weeks and is validated through real usage.
Remember that when evaluating what to protect, what to cut, and what to fix first, the objective is to reduce operational friction and restore clarity in how the system supports the business.
How to know the transformation is working
Progress is measured at the level of each domain. If inventory processes are improved, discrepancies decrease. Fewer orders require manual correction, and refunds linked to stock issues decline. If inventory accuracy was previously causing customers to order unavailable products, improvements should be reflected in fewer cancellations and refunds
Similarly, If customer or product data is aligned, updates propagate consistently across systems. Teams spend less time reconciling information, and decisions can be made with greater confidence in the data.
Each step is evaluated based on observable changes in operations. Once a domain shows clear improvement, the process moves to the next, and the transformation continues.
Final thoughts
There is no fixed size or threshold that determines when a company should rebuild its platform. Smaller organisations often adapt more quickly because they have less complexity and fewer decision layers. Larger organisations may take longer to make decisions and implement changes.
The more reliable sign is the accumulation of inefficiencies across the organisation. At that point, incremental fixes are not enough, and the system itself needs to be reworked. Rebuilding under these conditions requires working within a system that remains active. The process is incremental, each step is validated through real operations, and stability in core processes is maintained throughout.
It is critical to understand that this is not a one-time transition, but a structured way of restoring alignment between the system and the business, and maintaining that alignment over time.
Antons Sapriko
