How to start modernizing a legacy e-commerce platform without derailing everything else

It usually starts with something small

A developer mentions, almost in passing, that the new checkout feature will take six weeks. You thought it would take two. You don’t push back – you’ve learned not to push back on estimates anymore, because they always turn out to be optimistic anyway. So you say fine, and you move on.

Then a release goes wrong on a Friday evening and the team spends the weekend fixing it. At some point the Sunday evening slot gets informally reserved for this. Then the Monday morning slot for fixing what Sunday broke. Then a new developer joins and needs three months before they can ship anything independently. Then someone asks about integrating one of the AI tools everyone’s talking about, and the answer comes back: “our system doesn’t really support that.”

At some point you realize: the platform isn’t failing. It’s just quietly making everything harder than it should be. And you don’t know where to start.

That’s a more common situation than most founders admit. And it’s more urgent than it used to be – because a platform that slows down your development also now blocks your ability to adopt the tools that are reshaping how e-commerce operates. Every month you wait, the gap between what your system can do and what your competitors are building gets wider. And it compounds.
Here’s what I’ve learned from walking into enough of these: the platform is almost never the problem people think it is. And the first move is almost never the one that feels obvious.

The audit nobody wants to do

Not estimating. Not assuming. Actually understanding.

The first move is always an audit – a thorough read of the codebase before anything gets changed. Not to produce a document that ends up in a drawer, but to actually map the terrain: where the real risk sits, which parts of the system are structurally fine and just need cleanup, which parts need careful handling, and what a realistic path forward looks like.

This matters more than it sounds. Legacy platforms almost always have a gap between what looks bad and what is bad. Some things are messy but safe to leave alone for now. Some things look fine and are quietly dangerous. You can’t prioritize work you don’t understand – and if you start fixing things without that map, you’ll spend time on the wrong problems and create new ones.

The audit also gives you something concrete. After it, you know what you have. You can make decisions based on facts rather than assumptions – about scope, about cost, about risk. That’s a different conversation than “we need to modernize the platform” with no further definition.

What you end up with is a short document:

• here’s what we found,
• here’s what’s actually risky,
• here’s what the first three months look like.

Not a roadmap built on guesses. A plan built on the actual system.

The unglamorous work that makes everything else possible

Once you understand the system, the instinct is to get to the features. The backlog is long. The business has been waiting. There’s pressure to show progress.

That instinct leads to problems. The first real move – before any architecture changes, before any new features – is building the safety net.

That means automated deployments, so releases stop being events anyone holds their breath through. Production monitoring, so problems surface before customers find them. You add test coverage incrementally as you work through the codebase – starting from zero on most platforms that have been running for years without it.

None of this is glamorous. None of it ships new functionality. But it changes everything that comes after. Once deployments are automated, releases become boring – something that happens on a Tuesday afternoon with nobody watching. The goal of a good release process is that nobody notices it happened. If your team is congratulating each other afterwards, something is wrong. Once there’s monitoring, incidents stop being surprises. Once there are tests, the codebase stops being something you’re afraid to touch.

Most modernization projects skip this step or defer it. It’s not hard to see why – it doesn’t look like progress, and everyone involved is under pressure to show progress. So they go straight to the exciting work – the new architecture, the new features – and leave the infrastructure for later. Later usually doesn’t come. And without the safety net, every change carries more risk than it should.

Most of it doesn’t need fixing. Finding out which part does is the whole game

With the safety net in place, the real work begins. And this is where prioritization matters more than almost anything else.

Not everything in a legacy codebase needs to be fixed. Some things are ugly but harmless. Some things have been wrong for years and the business has quietly adapted around them – to the point where fixing them would first require a meeting to explain why they need fixing, which itself becomes a problem to manage. Trying to fix everything – every corner of the system, every accumulated shortcut – is how modernization projects turn into year-long ordeals with no clear end and no clear results.

The right question isn’t “what’s wrong” – it’s “what’s actively costing the business right now.” The critical paths where slow architecture is compressing every deadline. The modules where one person leaving would cause a real crisis. The integrations that are leaking revenue or reliability. The changes that unblock the most future work.

There’s an e-commerce platform built around second-hand goods sold through live auctions – handling thousands of requests per minute – that ran into this exact problem a few years ago. The issue that surfaced first was a spike in infrastructure costs that nobody could explain. The developers had been looking at it for weeks. No diagnosis.

When the codebase was properly audited, the cost spikes turned out to be a symptom. The actual problems ran deeper: no CI/CD pipeline, no automated tests, no production monitoring. Every release was manual, deployed instance by instance. The payment integration had known issues that were silently affecting conversion. The cost spikes were the thing they could measure. Underneath were the things they’d stopped noticing.

The cost spikes got fixed first – because that was bleeding immediately. Then the safety net went in. Then the rest of the platform got worked through, one critical path at a time. No rewrite. No feature freeze. The platform kept running and shipping throughout.

The numbers at the end of the engagement: revenue had doubled from the first release. Uptime went from below 95% – which sounds acceptable until you realize it means over 400 hours of downtime a year – to 99.99%+ in the most recent year. Every release became fully automated. Data operations that used to take minutes started taking seconds.

None of that required starting from scratch. It required working through the right problems in the right order.

The platform keeps running through all of it

The concern most founders have when they think about modernization is reasonable: you have a live platform, it’s generating revenue, and you can’t afford to take it down for six months while someone rebuilds it.

You don’t have to.

The approach described above – audit first, safety net before features, incremental improvement one critical path at a time – is specifically designed to keep the product running throughout. Modernization work happens in parallel with normal development. Features still get built. The business still operates. The platform gets healthier in increments rather than in one high-risk lurch.

It’s slower than a rewrite in the short term. It requires discipline – careful decisions about what to fix now and what can wait, building real understanding before making structural changes. But for a platform that’s already serving real customers and real revenue, it’s the right call. A full rewrite carries more risk than most teams anticipate going in, and far fewer of them ship on time and on scope than anyone wants to admit.

Where to start, concretely

The question “where do I start” usually has a boring answer: start by finding out what you actually have. Not by planning the rewrite, not by scoping a six-month project – by getting an honest picture of the codebase, where the risk actually sits, and what the first move should be.

It’s a smaller first step than most people expect. And it’s the one that makes everything else possible to decide.

If this is where you are, we’re happy to talk through it. No pitch, no proposal on the first call – just an honest conversation about what you’re dealing with and whether we’re the right fit.