The trading calendar outranks the vendor's roadmap

Every large retailer eventually receives the same letter. A software supplier announces that a product the business depends on will leave support on a given date, offers a successor and proposes a migration plan that finishes comfortably before the deadline. The plan is usually sensible from the supplier's side of the table: its engineers are free in the right months, and moving every customer at once suits its own economics. What the plan rarely contains is the shape of the retailer's year.

I have now replaced store or merchandising systems at three retailers, and I have arrived at a position that some finance colleagues consider expensive. In grocery, a replacement programme should be planned backwards from the trading calendar, not forwards from the supplier's date. When the two collide, the supplier's date is usually the one to buy out. It is a commercial term with a price. A disrupted Christmas, a failed Easter or a week of empty shelves in January also has a price, and in my experience it is almost always the larger one.

What a cutover night actually costs

Programme budgets record what a cutover costs the project: overtime, engineers on site, hardware shipped in advance, the rehearsal of a rollback. They seldom record what it costs the store. At Ravessa, a supermarket of average size takes well over €1,000 an hour on an ordinary weekday afternoon and several times that on the Saturday before Christmas. A cutover that slows each transaction by twenty seconds does not close the store. It lengthens the queue until some shoppers leave a basket in an aisle, and a few of them try another supermarket the following week and do not come back.

That damage is real and hard to see, which is why it is usually left out. When we planned the replacement of the till software in all our stores, I asked finance to estimate the trading cost of a poor cutover for each week of the year, using our own sales curves and a deliberately cautious assumption about lost baskets. The estimate was not precise, and the paper said so. It was precise enough to show that the cost of a bad night varied by a factor of about six across the calendar. Holy Week, the summer months in our coastal stores and the seven weeks from mid-November to the Epiphany sat at the top. A Monday night in late February sat near the bottom.

That curve became the spine of the programme. We cut stores over on Monday nights after closing, took a go or no-go decision at five the following morning and kept the old software ready for seventy-two hours. We declared three freeze windows in which nothing changed in any store, whatever the programme plan said. The supplier's support for the old platform ended in December 2023. Our last store moved in November 2024. We paid €3.8 million to extend support for the year in between, and I would make the same decision again.

The devices nobody put in scope

The second lesson concerns what a till actually is. In a project plan it is software running on a terminal. In a supermarket it sits at the centre of a small network of devices that the plan tends to treat as somebody else's business: the scales at the delicatessen and fish counters that print price-embedded barcodes, receipt printers, card terminals, cash-recycling machines in larger stores, the security scales under self-checkouts, the handheld scanners used for price changes. Each was bought at a different time, from a different supplier, and each has a way of failing that appears only when a real shopper presents a real item.

Our pilot, in six stores in Teruel province, found that 2.7 per cent of weighed fresh items scanned with the wrong price or not at all, because the new software read the barcodes from older counter scales differently from the software it replaced. Nobody had listed the scales in scope. Had we found the problem in a regional wave of ninety stores in December, the fish and meat counters of a whole region would have been unable to sell reliably in the busiest fortnight of the year. We added the scales and label printers to the programme at a cost of €5.1 million and moved the first regional wave from October 2022 to January 2023, past the Christmas freeze.

A board cannot be expected to know about price-embedded barcodes. It can ask a simpler question: which devices on the shop floor touch this system, and who has tested each of them in a trading store? If the answer is a list of the supplier's certified hardware, the programme has not yet met the store. I now ask for that inventory before any store programme comes to the board, and I ask for it to be signed by an operations manager as well as an engineer.

Buying time is cheaper than buying a bad January

I learnt this expensively, and before Ravessa. In January 2015, at a drugstore and perfumery chain in Madrid where I was IT director, we moved our merchandising system to a new platform in the first week of the year. The date suited the financial year and the supplier's team. It did not suit the business: the Epiphany is the largest gift day of the Spanish year for perfumery, and the winter sales traditionally begin the day after. Store replenishment failed for nine days. I had agreed to the date. I had not argued hard enough against it, because the supplier's plan looked tidy and the alternative meant asking for money to stand still.

The case against buying time is usually made in the language of discipline. Extended support is expensive, it rewards the supplier for its own deadline, and a programme without a firm end tends to drift. All three points are fair. My answer is to make any extension conditional and visible: a fixed term, priced in the original business case rather than negotiated in a hurry, with the board told in advance which windows the programme will not touch. At Ravessa we negotiated the extension late, under pressure, and paid more than we needed to. That was my error, and the practical lesson is to price the extension when the new contract is signed, while the supplier still wants the business.

There is a second cost that the discipline argument misses. A programme run against an immovable supplier date pushes its risk towards the stores, because the only variable left is how many stores move each night. A programme that has bought itself room can push risk the other way, into rehearsal, into pilots that are allowed to fail and into waves small enough to roll back. Room is what lets the project team say no to a bad night.

None of this argues for slowness. Our nine regional waves moved 5,240 checkouts in twenty-two months, and no store lost the ability to trade. It argues for a different idea of what a deadline is. In a supermarket the deadlines that matter are set by when people shop, and a technology plan that ignores them is not ambitious. It has simply been written for someone else's calendar.