When the Servers in the Building Fail: What Boston Scientific's Outage Teaches Every SME

On 24 October 2024, a supplier called Blue Yonder — the software behind a lot of the world's supply chain planning — got hit by ransomware. The blast radius reached names you'd recognise. Starbucks staff went back to writing down hours on paper because their scheduling system went dark. Two of Britain's biggest grocers, Morrisons and Sainsbury's, saw warehouse operations wobble in the run-up to their busiest week of the year.

Throughout 2024 and into 2025, a pattern kept repeating across manufacturing and healthcare: an attack lands on systems physically sitting in the building — the machines running the production line, the warehouse, the shipping desk — and the business grinds to a halt. Meanwhile the email, the collaboration tools, the customer records living in the cloud carry on as if nothing happened. Boston Scientific, the medical device giant, is one of many organisations that has had to reckon publicly with this exact split: cloud services humming along, on-premises operations stalled, orders unable to ship.

That split is the whole point. And it's the most useful thing you can put in front of a client who's been nodding politely at your disaster recovery pitch for three years without ever signing off the budget.

Why abstract DR arguments never land

Every MSP has given the talk. Recovery time objective. Recovery point objective. Backup rotation. Immutable snapshots. The client hears it, agrees it sounds sensible, and files it under 'things we'll sort out next quarter'. Next quarter never comes, because nothing has gone wrong yet, and the invoice for proper resilience is real money spent against a risk that feels theoretical.

The problem isn't that the client is careless. It's that the language is abstract. 'RTO of four hours' means nothing to a managing director who's thinking about payroll and the sales pipeline. It doesn't connect to anything they can feel.

An outage like Boston Scientific's connects. Not because it's dramatic, but because it maps onto something concrete: goods that couldn't leave the warehouse. Orders that customers had placed and paid for, sitting there, because the system that tells the floor what to pick and pack was unavailable. That's not a metric. That's revenue with a date attached.

The lesson hiding in plain sight

Here's the part worth dwelling on. In these incidents, the cloud systems were fine. The attack hit the on-premises kit — the servers running the manufacturing and logistics workflows that had never been moved off-site.

That matters for two reasons, and they pull in slightly different directions.

First, it's a live argument for moving critical operational systems off ageing on-premises hardware. A well-run cloud platform gives you geographic redundancy, patching cadence, and recovery tooling that most SMEs simply can't replicate in a server cupboard behind reception. When the on-prem box dies — from ransomware, a failed drive, a flood, or someone unplugging the wrong thing — there's often no clean way back quickly. The business waits.

Second, and this is the bit that stops the conversation becoming a lazy 'just move everything to the cloud' pitch: cloud is not automatically safe. Blue Yonder was a cloud service, and it got ransomed. Moving a workload to Azure or AWS doesn't hand you resilience for free. It changes where the risk lives and who's responsible for what. If you don't back up your Microsoft 365 data, Microsoft won't do it for you in the way you assume. If you don't test your restore, you don't have a restore — you have a hope.

So the honest lesson isn't 'cloud good, on-prem bad'. It's this: the systems your business genuinely cannot operate without deserve deliberate resilience, wherever they sit. The organisations caught out by these outages weren't victims of bad luck. They were running mission-critical operations on infrastructure that had one point of failure and no fast path back.

How to run the conversation with a client

Don't lead with the technology. Lead with the question that makes a director sit up: If the system that runs your production line, or your order processing, or your dispatch went down at 9am on a Monday, what happens by lunchtime?

Then walk it through with them, using their actual business.

Map the critical path. Every SME has a small number of systems that, if they stop, the money stops. For a manufacturer it might be the ERP and the machine controllers. For a distributor, the warehouse management system. For a professional services firm, the case or project management platform. Find those. Everything else is secondary.

Ask where each one lives and what happens if it dies. Is it a physical server on-site? A cloud SaaS product? A hybrid mess where the app is in the cloud but depends on a local database? For each, get a real answer to: how do we get it back, how long does that take, and how much data do we lose?

Put a pound figure on the downtime. This is where it stops being abstract. If dispatch can't ship for a day, what's a day's shipping worth? If the whole team is idle, what's a day of payroll against zero output? Boston Scientific and Sainsbury's could count that in millions. Your client counts it in thousands — but thousands is still enough to make a resilience budget look cheap.

Then, and only then, talk solutions. Immutable backups so ransomware can't encrypt your recovery copy. Tested restores, run on a schedule, not assumed. A documented recovery plan someone can actually follow at 3am. Backup for cloud data, because the SaaS vendor's uptime is not your backup. Segmentation so an attack on one system doesn't roll straight into the next.

The immutability point deserves its own moment

Ransomware crews learned years ago to go for the backups first. If they can encrypt or delete your recovery copies, your ransom leverage goes to the roof. This is why 'we back up nightly to a NAS in the office' is not a plan — it's a target.

Immutable backups can't be altered or deleted for a set retention period, even by someone with admin credentials. Offsite copies survive the fire or the flood that takes the building. The old 3-2-1 rule — three copies, two different media, one offsite — has grown a fourth number: one immutable, one air-gapped or offline. When you're showing a client the Boston Scientific example, this is the concrete answer to their obvious next question: so how would we have avoided that?

Make it this quarter's conversation

The reason to raise this now, rather than at the next review, is that the examples are fresh and named. You're not asking a client to imagine a risk. You're pointing at a medical device manufacturer, a supermarket, a global coffee chain — real organisations, real dates, real disruption — and asking a simple question: are we any more protected than they were?

For most SMEs, the honest answer is no. They've got a server in the building running something the business can't live without, a backup nobody has tested, and a quiet assumption that it'll be fine.

Your job isn't to frighten them. It's to make the risk real enough to act on, and then to hand them a plan that's proportionate to their business. The outage did the frightening part for you. Use it while it's fresh, and turn a three-year-stalled DR conversation into a signed-off resilience project before the next incident makes the headlines with someone else's name on it.