The team at a regional homeware retailer, which we will call Meridian Home, had a plan that looked tidy on a slide: replace the old online ordering system with a modern platform, and cut over every product line on a single date. Sales liked it, finance had signed off, and the developers were cautious but willing. What follows is the story of how a small pilot first approach changed that plan, and why the cut-over that finally happened was the quietest launch the company had ever run.
The plan everyone nearly approved
Meridian’s old system had grown by accumulation. Shipping rules, discount codes and stock counts all lived in different places, held together by habits that only a few long-serving staff fully understood. The proposal was to move everything to a new platform in one weekend, with a short freeze on orders to make the switch.
Priya, the operations lead, raised a worry in the final review meeting. Nobody in the room could say, with evidence, what would break. The vendor demonstration used clean sample data. Real orders were messier. She did not argue for cancelling the project. She argued for a trial.
Shrinking the project to one slice
The compromise was a pilot with a hard edge around it. Instead of the whole catalogue, the new platform would handle a single category, lamps and lighting, for a fixed window. These products were a good test because they included fragile items with special packaging, a handful of bundles, and one supplier who shipped directly to customers.
Before anything was switched on, Priya and the lead developer, Arjun, wrote a one-page note. It listed three conditions for a yes:
- Customers can place, pay for and track a lighting order without staff stepping in to repair it.
- Stock counts for the category match the warehouse floor when checked by hand at the end of the window.
- The support inbox does not see a rise in order-related complaints compared with the same category’s usual pattern.
They also wrote a no. If any condition failed badly, the category would return to the old system and the wider migration would pause until the cause was understood. Everyone signed the note, including the sceptics.
What the trial turned up
In the first few days the new platform behaved well. Then reality arrived. Three discoveries stand out from the pilot, and each would have been painful at full scale.
- The double-counted bundle. A lamp-and-bulb set deducted stock for both the set and its individual parts, so the system believed the warehouse was emptier than it was. Customers saw “out of stock” on items sitting on shelves.
- The direct-ship supplier. Orders for that supplier needed a hand-off message the old system sent silently every evening. Nobody had listed it anywhere because nobody remembered it existed.
- The rounding quirk. A discount code applied to a sale price produced totals that differed by a small amount from what finance expected, which would have complicated every month-end reconciliation.
None of these issues was dramatic. Each was fixed in a day or two. Together, however, they would have blindsided a company-wide launch, arriving in the same week as holiday demand.
The decision meeting
At the end of the window the group met and read the note aloud. Condition one: passed, once the bundle bug was fixed. Condition two: passed after a correction. Condition three: the support inbox had been quieter than normal, which pleasantly surprised everyone. Because the test had been written in advance, there was no debate about whether the result counted. The answer was yes, with a list of fixes already completed.
Arjun later said the written test made the meeting short. Without it, he suspected they would have spent an hour arguing about feelings.
Widening in waves
Rather than flipping everything at once, Meridian moved category by category over the following weeks. Each wave reused the same three conditions, adjusted for the products involved. Kitchen textiles went next, then furniture, which introduced delivery-slot rules that the lighting pilot had never exercised. That wave found a new issue, and because the exposure was limited, it cost an afternoon, not a crisis.
For readers who think about how a business sequences this kind of change, the roadmap in a stepwise services plan for newcomers takes a similar phased view, and the piece on bringing web, cloud and smart tooling together as a business grows sets out where the technical decisions tend to sit.
Where outside experience helped
Meridian did not have a large engineering department, so part of the design work, namely how to stage the move and what the pilot should prove, was shaped with advice from specialists. The team had looked at the public description of a studio that offers advisory, migration and implementation support for software delivery, which reinforced the idea of moving in phases and having an assessment before committing to anything large.
The objections along the way
Not everyone loved the pilot at first. The sales director worried that running two systems in parallel would confuse customers and staff. The finance manager asked whether the trial was simply a polite way of delaying the project. These are fair concerns, and the team answered them directly rather than waving them away.
On confusion, the answer was containment. Customers only ever saw one checkout, because each product belonged to exactly one system at a time. Staff received a short briefing and a single contact for questions during the window. On delay, Priya pointed to the calendar: the pilot added a few weeks, whereas a failed weekend cut-over would have cost far longer in rework and lost orders. The finance manager asked to see the stop condition written down, and once he had, he became one of the pilot’s strongest supporters.
How to run your own version
- List what the old system does. Include the silent duties, the nightly jobs and the habits people perform without thinking.
- Choose one slice with texture. It should contain at least one awkward case from your list.
- Write three or four conditions for a yes. Keep them observable, so that two people reading the results would reach the same verdict.
- Write the stop condition too. Agree in advance what failure looks like and what happens next.
- Fix the end date and hold it. Extensions should be a deliberate decision, never a drift.
- Review together and publish the result. Share what passed, what failed and what changed, so the next wave starts smarter.
Lessons the team wrote down afterwards
When the final category went live, Priya circulated a short retrospective. The points are worth borrowing.
- Pick the awkward slice. Lighting was chosen because it was fiddly, not because it was easy.
- Write the test first. A yes or no defined before the trial removes arguments afterwards.
- Keep the window fixed. The trial ended on its date, even though a few people wanted more time.
- Document the invisible duties. The old system did things nobody had listed. The pilot is the cheapest way to find them.
- Treat a stop as a valid result. The team agreed that if lighting had failed, pausing would have counted as the pilot doing its job.
What a leader can take from the story
If you sponsor a technology change, the most useful question you can ask is not “when do we launch?” but “what is the smallest real thing we could run first, and how will we know it worked?” It is a modest question, and it reliably changes the quality of the plan. Teams that answer it end up with a shorter list of unknowns, a clearer decision point and a launch that feels, afterwards, almost anticlimactic.
That anticlimax is the goal. Meridian’s full cut-over happened on an ordinary weekday with no freeze and no emergency channel. The dramatic parts of the project had already happened, safely, in a corner of the catalogue where mistakes were cheap.
