When a Legacy Commerce Platform Stops Fitting the Business

Most legacy platforms do not fail all at once. They become expensive by degrees.

A supplier feed needs its own importer. Pricing needs an extension. A quotation-led sale is pushed through a checkout-shaped journey. Staff copy information into a separate operational process. The website still works, but every meaningful change takes longer than it should.

This is the point where legacy commerce replatforming stops being a software upgrade and becomes an operating-model decision.

The real cost is change friction

Licence and hosting costs are visible. Change friction is harder to see. It appears as specialist dependencies, regression risk, manual checks, slow pages, duplicated data and roadmap compromises.

One of our most recent projects began with a general-purpose commerce system supporting a large, multi-source catalogue. Its commercial journey was quotation-led, with quantity pricing, configuration, artwork and human approval. The platform, however, carried assumptions for transactional ecommerce that the business did not need.

The issue was not that the legacy product was inherently poor. It was a poor fit for the job being asked of it.

Rebuild the business capability, not the old screens

The replacement began with a capability map:

• normalise supplier product data;
• calculate commercial rules consistently;
• help customers find and configure products;
• capture quotation intent;
• let staff refine, price and issue quotes;
• manage artwork and proof approval;
• turn accepted quotes into operational orders without rekeying;
• observe imports, releases and failures.

This reframed the build. Instead of reproducing the legacy platform feature by feature, the team built around the flow of information and decisions.

Create one internal language for product data

Supplier feeds are external opinions about your catalogue. They should not define the internal application.

The new platform mapped supplier-specific products, variants, prices, decoration options, stock and media into a canonical model. Source identifiers and raw evidence remained available for audit, but the storefront and operational workflows worked with one internal language.

That separation made it possible to protect manually curated fields, replay individual import stages, index data for fast search and change a connector without rewriting the customer journey.

Pull pricing out of the plugin layer

Pricing rules are commercial IP. When they are trapped in extensions or jobs that few people understand, the company does not truly own them.

The replacement used explicit, tested calculators for supplier rules, variants, quantities, setup, decoration, carriage and margin. Representative examples became regression fixtures. Price changes could be exported and reviewed.

The result was not merely cleaner code. It created a shared object that commercial and technical teams could reason about.

Design one continuous quotation journey

A familiar catalogue experience still mattered: categories, filters, search, product pages, variants and a basket. But payment was not the destination. A well-formed quote request was.

After submission, the same data continued through staff quotation, customer communication, artwork, proof, approval and order operations. The platform reduced the seams where teams usually resort to inboxes and spreadsheets.

This is where bespoke UX can outperform configured ecommerce: it is free to follow the customer’s real intent.

Scale the operating model, not just the servers

The initial infrastructure was deliberately modest: containerised application roles on a cost-conscious host, with private object storage, scheduled work, backups and automated releases. The architecture also documented a move to managed containers, database and content delivery when demand justified it.

Scalability came from decisions that applied at either size:

• stateless web processes;
• separate background workers and scheduler;
• immutable releases;
• indexed local catalogue data;
• no supplier API dependency during page requests;
• private, versioned object storage;
• health checks, monitoring and rollback;
• operational runbooks.

“Cloud native” is less important than knowing how state, failure and recovery are governed.

How to decide whether bespoke is right

Do not rebuild simply because the current system is frustrating. Bespoke is a strong choice when:

• the workflow is genuinely distinctive;
• commercial rules create competitive advantage;
• integrations and operational hand-offs dominate the roadmap;
• the long-term cost of framework workarounds is measurable;
• the organisation is prepared to own operation and maintenance.

Configured software remains the right answer for standard processes. The key is to compare whole-system costs and constraints rather than licence fees against development estimates.

What ownership looks like

By its current repository snapshot, this transformation had established a governed catalogue, testable pricing, quotation and order workflows, private file handling, automated supplier operations, infrastructure as code, deployment gates, monitoring and a documented path to scale.

The claim is not that bespoke software magically creates growth. It is that the business can now change its core workflow directly, measure it properly and improve it without negotiating against an inherited platform model.

If your platform works but your roadmap does not, start with a platform-fit review. Map the workflow, rules, data and cost of change. The most valuable outcome may be a rebuild. It may be a smaller integration. It may be a decision to keep what you have.

The important thing is to make the decision around the business you operate now—not the software category you bought years ago.