How we went from six platforms to two

When I arrived at Chantelle as Director of Engineering, the estate had six platforms doing work that two could do. Nobody had planned it that way. It accreted, the way these things always do: an acquisition here, a pet project there, a vendor deal that made sense the year it was signed and stopped making sense the year after. The run-rate was about €4M a year. By the time we were done it was about €3M, four of those platforms were gone, and uptime never dropped below 99.99%.

The number on the homepage is the easy part to say. The story is what took five years.

You do not save money by deciding to save money

Every consolidation starts with a spreadsheet that says you will save a fortune, and most of them end with a re-platform death march that costs more than the thing it replaced. The trap is treating it as a migration project: pick the survivor, pick the losers, set a cutover date, march everyone toward it. That is how you take a healthy system, freeze all its improvements for eighteen months, and hand the business a big-bang launch that either slips or breaks.

We did not do that. We treated it as a portfolio decision made continuously, not a project with a finish line. For each platform the question was not “is this the future” but “what does it cost to keep alive, what does it earn, and what breaks if it goes.” Some of the six were cheap to run and carried real revenue. Those you keep. Some were expensive, half-maintained, and duplicated a capability we already had somewhere better. Those you kill, but only once the thing they did lives somewhere else and has been proven in production.

Kill platforms, not capabilities

A capability the business depends on does not go away because a platform does. It moves. So the sequence is always the same. Find where the capability already exists in better shape, or build the smallest bridge that lets it live there. Move the traffic quietly, a slice at a time, watching the SLO the whole way. Only when the old platform is serving nothing does it get decommissioned. By then, turning it off is a non-event, which is exactly what you want. A decommission that feels dramatic means you moved too fast.

Sometimes moving the capability means building it. Our US store ran a points loyalty programme, and the app we were steered toward could not meet the requirements, so we built our own on GCP rather than bend the business to a tool. That is the discipline: the platform is disposable, the capability is not.

Europe was the easy half

The European estate was mostly Magento, on the licensed Enterprise edition. Each site was its own codebase, its own version, its own frontend and its own hosting, so nothing could be shared and every change meant an engineer relearning that one project’s quirks. That is what made the old estate expensive: not one big line item, but the same work done six slightly different ways. The first migration, from Magento 1 Enterprise to Magento 2 Open Source, had happened just before I arrived, and it had taken a dedicated team the better part of a year and a two-day cutover for the French site. My job was to make the rest routine, and we did: Germany, Denmark and the Netherlands moved onto the shared Magento 2 Open Source platform between the autumn of 2021 and early 2022, in under a year, with near-zero downtime. Shedding the Enterprise licence along the way was a quiet part of the saving.

The surprise was where the difficulty actually lived. It was not the technology, it was the calendar. Even a clean replatform dents your SEO and paid search for days to weeks while the search engines relearn the new stack, so every migration had to drop into a window with no promotions running. Coordinating those windows across countries and a marketing calendar was more of the work than the migration itself.

The US was the hard half, and we got it wrong first

The US did not want Magento at all. They saw it as heavy and dated and wanted something more modern, so we did the honest thing and ran a proper best-of-breed study: a SaaS storefront in front of a GCP data lake, BigQuery and Firestore and Cloud Functions and Pub/Sub, with an event-driven layer keeping everything in sync. We shortlisted three SaaS platforms, the stakeholders voted, and we started building on the winner.

Six months in, the winner turned out to have oversold its US tax compliance, which is not something you can wave away in American retail, so we pivoted to the runner-up, BigCommerce, in a headless setup. What had been scoped at six to nine months took eighteen. We lost time, we lost a couple of the freelancers we had brought in for the build, and the headless integration was harder than we had been led to expect.

The whole time, I was nursing the platform we were leaving. The old Magento 1 had to stay safe and up while the US built its replacement: security patches from MageOS, a dedicated firewall in front of it, a PHP upgrade to 7.4, and Solr, database and cache versions to keep current as our cloud provider retired the ones it depended on. Keeping the thing you are trying to kill alive and secure is the unglamorous tax of every long migration, and it is rarely in the plan.

The ending was the good part. When the US finally cut over, it cut over smoothly, and the business grew double digits after the switch. The eighteen months were not wasted. They were the price of getting the destination right instead of fast.

Protecting the team and the SLO while the cost comes out

Here is the thing nobody puts in the business case: consolidation is mostly a leadership problem, not a technical one. The technical moves are known. The hard part is that every platform has people attached to it, and “we are consolidating” sounds a lot like “we are cutting” if you do not say otherwise clearly and early.

So we were explicit. The goal was to spend less running the estate so we could spend more building the parts that mattered, and to give engineers fewer, deeper systems to be good at instead of six shallow ones to babysit. That is a better job, not a smaller one. The SLO was the guardrail that made all of it safe. 99.99% uptime is not a vanity metric here, it is the contract that let us move fast: as long as we could take cost out without moving that number, we had permission to keep going. It never moved, and that is not luck. It is the direct result of migrating in slices, never big-bang, and never decommissioning anything that was still doing real work.

What I would tell anyone facing the same estate

Do not fall for the elegant target architecture on the slide. The value is not in the destination, it is in the path you take to get there without breaking anything on the way. Consolidate continuously. Move capabilities before you retire platforms. Guard a real reliability number and treat it as a hard stop. Be honest with your team about why. And be honest with yourself when a vendor was the wrong pick, because the six months you spend admitting it are cheaper than the two years you spend pretending.

We are still at it, which is the point. The last of the six, a custom microservice platform we put into maintenance mode two years ago, moves onto Magento 2 this November. Taking a million out of a run-rate while holding four nines is not a heroic sprint. It is a boring, deliberate, well-led campaign. That campaign is the kind of work I take on with the teams I partner with now, whether as their engineering leader or as the outside read on whether a consolidation is worth the risk before they commit to it.