The problem
In 2010 I put into production the software 250 newsagents use to run their shops: sales, returns, orders, and the daily link to the distributor who delivers the papers. It isn’t a portal people browse. It’s what they open the till with at six in the morning.
I wrote it in Silverlight — at the time, Microsoft’s bet on rich web applications.
The constraint
Silverlight died long before I removed it. Microsoft stopped backing it, browsers began refusing it, and everyone who had used it moved on.
Technically it could still be kept alive: browser plugins and configuration were enough. But a workaround that holds on one machine, multiplied by 250 shops that open at six in the morning and have no IT department, stops being a technical problem and becomes an operational one. And that, not the code, is what decides when a migration can no longer wait.
The real constraint was different: nothing could be switched off. No maintenance window, no migration weekend, no «everything changes on Monday» for 250 shopkeepers who hadn’t asked for any of it.
How I solved it
Not with a rewrite. By replacing one subsystem at a time, in the order that mattered.
2017 — the part the shops use. That one first, because it’s the one that can’t stop. Rebuilt on ASP.NET MVC with the same habits and the same screens: the goal wasn’t to modernise, it was to get off Silverlight without the shopkeeper noticing. That codebase is still in production today, and still under development nine years later.
2020 — the back office. With the shops already safe, I could rebuild administration properly, on a new platform rather than a compatible one.
2022 — the back office again, this time by choice rather than necessity. Plus the distributor synchronisation, rewritten separately.
All at once would have made a shorter story and a far riskier project. In sixteen years the system has never been down for more than a few hours, and that one time was a planned migration from on-premise to cloud.