Most Linux migration stories get pitched as ideology. The one near Bergamo that landed in Mišo Oroz’s queue in early 2026 was arithmetic. Mišo runs a one person IT outfit called Zerolock out of Spirano, and the project was a five workstation transport operation that had finally decided to leave Windows behind. The boss had been paying for software that kept breaking for two years, and the math had stopped working.
This is what the office looked like, what replaced it, and the parts the glossy case studies skip, which is what week one actually costs.
What Mišo walked into on day one
The setup was familiar to anyone who has consulted in northern Italy. The hardware worked. The software stack was mostly paid for.
- Five Windows machines on the same commercial desktop OS.
- A per seat office suite renewed annually, used mostly for spreadsheets.
- A third party antivirus subscription on auto renewal that nobody had checked in a long time.
- A shared drive that functioned more like a habit than a system.
- Drivers reaching dispatch on personal phones, with no work trail to audit later.
What finally pushed the boss off the fence was a count, not a feeling. Somewhere between eight and ten third party service visits had been billed over the previous twenty four months. Each visit cost half a day, produced a callback later in the week, and reinforced the slow suspicion that he was paying for the privilege of worrying. That is the lever that actually moves a small business owner to migrate. Not the license audit. The running total.
Nothing was catastrophically broken. Everything still worked, sort of. The cost of staying on the existing stack was small per incident and enormous per year, which is the shape of bill that nobody questions until somebody sits down and adds it up.
The hour that decided everything
Before touching any hardware, Mišo sat with each employee and wrote down what they actually opened during a normal day. Not what was installed. What was actually used. That sounds trivial. It is the entire project, because the answer is almost always smaller than the software inventory suggests.
In this office the real workload was four things. A word processor. A spreadsheet. Email. A shared folder with versioning so the latest copy of a document was always the latest copy. The boss needed occasional remote access from the road so he could answer a question without driving back. The drivers needed a work channel that did not depend on their personal phones.
None of that requires a paid desktop OS. None of that requires a paid office suite. None of that requires a paid antivirus product. Coming to that realization took about an hour, and the rest of the project flowed from it.
What replaced the old stack
For an operation this small, Mišo’s recommendation was deliberately boring. A mainstream Linux desktop that looks and behaves like a normal office computer on day one, and stays out of the way after that. LibreOffice (a free office suite compatible with the common Microsoft file formats) for documents and spreadsheets. A standard mail setup. A proper shared drive with file versioning. Remote access over an open protocol, no proprietary license required.
Drivers ended up with something more valuable than new software. They got their personal phones back. Work moved onto a managed channel with logs, so a driver who quits does not walk out with six months of customer contacts sitting in his WhatsApp history. That part of a migration never gets a screenshot, and most consulting writeups skip it, but it is the part owners remember a year later. When business conversations live on employees’ personal devices, the owner does not really control the company. He is sharing custody with whoever currently has the phone.
Week one carries an honest cost. Staff have to relearn a handful of keyboard shortcuts. One person will not love the new spreadsheet. The consultant you hire has to actually know Linux, which is a narrower talent pool than the Windows pool, and that is something to budget for in advance. None of those are reasons to abandon the project. They are reasons to schedule it for a slow week.
The win shows up two months in
Two months after the cutover, Mišo reports what every small business owner who has done this properly will tell you. The phone stopped ringing. Not because the consultant vanished, but because the queue was empty. No update broke a printer. No license expired over a weekend. No antivirus popup panicked the receptionist into clicking the wrong thing. The boss stopped paying for software anxiety, and started paying for software that did its job.
That part of the story is hard to put on a slide, because there is no benchmark, no before and after graph, and no demo video. There is just a small logistics operation near Bergamo that used to lose half days to software drama and now does not, and a boss who can walk away on a Tuesday without checking on the office. That is the entire promise of moving to Linux in a small business context, and it is real.
Trade-offs
A migration like this is not free in time or in money. The first cost is the consultant’s bill, and the going rate for a competent Linux consultant in northern Italy in 2026 is real money. The second cost is internal, and it is the week of mild disruption while staff learn new shortcuts. The third cost is the long tail of small things that break a year later, because the consultant is not on retainer and the office has to call somebody new. None of those are fatal, but they are real, and they should be priced in writing before the project starts.
For a one to five person office, the math almost always works, and the breakeven point arrives sooner than you would guess, because paid service visits are expensive and they keep showing up every quarter. For a twenty to fifty person office, the calculus is more delicate, because by then you have hired an internal IT person and you probably have processes that do depend on a paid stack. For a fifty person plus office, you are not reading this article for advice. You have an IT director and a budget committee.
The other honest trade off is support. A paid stack comes with a vendor that takes your call. An open stack comes with a community that does not. If you are a one person owner with no interest in debugging, that gap matters. The fix is to keep the consultant on a small monthly retainer for the first six months, then taper. That is what the owner here effectively did, and it is the part of the plan I would copy.
If your office is somewhere between five and twenty workstations and the annual software bill feels like a tax rather than a tool, the next move is not shopping for a cheaper stack. Audit what each employee actually opens in a normal week. Audit what each paid product has actually prevented in the last year. If the second column is mostly empty, the case for migration writes itself. If it is not, your stack is probably earning its keep, and the right answer is to leave it alone. The mistake is paying for software that is not doing its job, and the fix for that is the audit, not the migration.