A client calls. They've just had a board meeting, or a near-miss, or a cyber insurance renewal that asked an uncomfortable question: "What's your disaster recovery position?" They need failover infrastructure, or capacity for a seasonal spike, and they need it inside a timeframe that makes "let's put together a capex proposal for new hardware" a non-starter.
You now have a decision to make that has nothing to do with the client's problem and everything to do with your balance sheet.
The three options, and why two of them are wrong for most MSPs
Option one: build it yourself. Buy the hardware, find the rack space, carry the depreciation, staff the refresh cycle. This works if DR and overflow are a meaningful, recurring line of business for you. For most MSPs, they're not — they're an occasional client requirement that shows up unpredictably and needs to be solved fast. Capital tied up in idle failover capacity that might get used twice a year is capital that isn't doing anything else for your business.
Option two: push it to a hyperscaler. This solves the capital problem but creates a different one — cost predictability. Egress fees, burst pricing, and the general unpredictability of cloud billing under load are fine when you're testing something. They're a liability when the bill lands the month after a client's DR event actually triggered, and you're the one explaining the invoice.
Option three: partner with a dedicated server provider who treats this as their actual job. You get physical infrastructure without owning it, predictable costs, and — if you pick the right partner — someone who answers the phone when the failover is live and something's not behaving. This is the option most MSPs land on once they've priced out the other two, and it's worth understanding why.
Billing predictability: what "predictable" actually means
"Predictable billing" gets used as a throwaway line in every hosting company's marketing. It's worth being specific about what it actually buys you, because the alternative isn't abstract — it's a real number on a real invoice.
Say a client's primary site goes down and their environment fails over to your DR infrastructure for four days while the incident is resolved. On a flat-rate dedicated server, that's the same monthly cost whether it's sat idle or carrying full production load — call it £[X]/month, no matter what happens during the failover window. On a hyperscaler equivalent, that same four-day failover — with the compute spin-up, the data egress as systems resync, and the burst pricing tier you get pushed into under load — can land anywhere from £[Y] to £[Z], and you often don't know which until the invoice arrives.
The difference isn't that dedicated is always cheaper. It's that you can put a number in a client contract and stand behind it. When you're the one who has to explain infrastructure costs to a client who's already having a bad week because their primary site went down, "it's always £[X], full stop" is worth more than a theoretical cost advantage that only shows up if nothing goes wrong.
Proof, not promises
Every hosting provider claims reliability. Almost none of them let you check.
Our Status page shows 100% over the last 90 days with 99.99% on our billing platform.
Our status page is public, live, and not curated for a sales page — it's the same view we use internally. Right now it shows [X]% uptime across the fleet over the past 12 months, updated in real time, not a quarterly summary written by someone in marketing. If you're evaluating a DR partner, that's the first thing worth asking for: not a claim, a page you can bookmark and check the morning of your client's board meeting, before you've committed to anything.
This matters more for DR and overflow specifically than for general hosting, because the whole point of the arrangement is that it works when your primary infrastructure doesn't. A DR provider whose own reliability you can't independently verify is asking you to take a claim on faith at the exact moment you can least afford to be wrong.
When it goes wrong, you need a person
Here's the scenario that actually tests a DR partnership: it's outside office hours, the client's primary environment is down, the failover isn't behaving quite the way it did in testing, and you need someone who understands infrastructure — not a ticket queue with a four-hour SLA and a first-line agent reading from a script.
This is where a lot of the value in "human support" actually lives, and it's not a soft benefit. During an active DR event, the difference between a phone call answered by someone who can look at your specific setup and an email ticket that gets triaged is the difference between a contained incident and a client who loses another six hours. If your DR partner's support model is built around ticket volume rather than actual engineering knowledge, you find out at the worst possible time.
We run support as a two-person operation with sixteen years of enterprise and MSP background behind it — not because it scales infinitely, but because when your client's failover is live, you're not getting a first-line script-reader. You're getting someone who's actually run this kind of infrastructure under pressure before.
Data residency isn't paperwork — it's part of the DR plan itself
If your client has any UK or EU compliance obligation — and increasingly, most do — where their failover data physically sits is part of the DR plan, not an afterthought to sort out later. A dedicated server with confirmed UK data residency means you're not adding a data protection question to an already stressful failover event. This is easy to overlook when you're evaluating providers on uptime and price alone, and it's exactly the kind of detail that surfaces at the worst time if you haven't checked it in advance.
What this actually means for how you sell DR to clients
You don't need to own DR infrastructure to offer it credibly. What you need is a partner whose numbers you can verify, whose costs don't move under load, and whose support model matches the actual stakes of a failover event — not a marketing page promising all three.
If you're currently quoting DR or overflow capacity to clients and building it in-house or through a hyperscaler by default, it's worth pricing the alternative before your next proposal goes out. The maths usually looks different than expected.
Sorting Your Hosting provides UK-based dedicated servers, VPS, and private cloud infrastructure for MSPs who'd rather not carry idle DR capacity themselves. Live status: status.sortingyourhosting.com. Call 0333 335 6936 to talk through a specific DR or overflow scenario.