Who this is for. MSP owners and technical directors choosing, or re-checking, the supplier that will sit underneath client workloads. You carry the client relationship, so whatever your supplier fails to deliver becomes your incident, your credit note and sometimes your contract dispute. This article is about getting evidence before you commit. It names no supplier and does not rank any, and it cannot tell you what a good price or a good service level looks like for your situation.
Treat claims as hypotheses
Hosting suppliers describe their services in marketing language that is easy to compare and hard to verify. Every statement falls into one of four classes, and you should know which class you are holding:
- Contractual. Written into the agreement or an incorporated schedule, with a stated remedy.
- Documented but not contractual. Described in a data sheet or a knowledge-base article. It may change without notice.
- Claimed in sales conversation. Not written anywhere you can rely on.
- Demonstrated. You saw it work, in your own test, on your own workload.
Aim to move every claim that matters to you from class three up to class one or four. A statement like “our platform is highly available” tells you nothing until it is tied to what is measured, how, and what happens when it is missed.
Questions by area
Use these as a worksheet. Record the answer, the evidence offered and which of the four classes it belongs to. The requirements planner generates a version tailored to your tenant mix and recovery objectives.
| Area | Questions to ask | Evidence to request |
|---|---|---|
| Isolation | Which layers are shared with other customers? How are CPU, memory, storage and network limited per customer? Can you see contention metrics? | Architecture description, a worked example of a noisy-neighbour event and its resolution |
| Capacity | What capacity is held for host failure? How is growth provisioned, and what is the lead time? | Description of N+1 or equivalent, lead time in writing |
| Backup and recovery | Where do backups sit relative to production? Are they immutable? Who can delete them? What do recovery statements measure? | Backup architecture, retention schedule, a recent restore test result |
| Security | How is administrative access controlled and logged? Which staff can see my data? How are vulnerabilities patched, and in what time? | Access policy, patching policy, summary of recent independent assessments |
| Assurance | Which independent reports or certifications exist? What do they cover? | The report itself, not the badge |
| Network | What are the uplinks, redundancy and peering? How are tenants separated? | Network design summary, tenant separation description |
| Support | How do I reach support at 3 a.m.? What are escalation routes, and how are response and resolution measured? | Support terms, escalation matrix, named roles |
| Operations | What are maintenance windows and notice periods? Can specific tenants be deferred? | Change policy |
| Commercial | What are minimum terms, step sizes, transfer charges and renewal terms? | Draft agreement and price schedule |
| Exit | How do I get data and configuration out, how fast, in what format, at what cost? | Exit schedule, sample export |
Reading an SLA
A service level agreement is a legal and commercial document, not an engineering promise. Read these parts first:
- What exactly is measured. Availability of what: the physical host, the virtual machine, the network path, the management interface, or the service as a customer experiences it? Measured where, and by whom?
- The measurement period and the exclusions. Scheduled maintenance, force majeure and customer-caused outages are commonly excluded. Excluded time can be large.
- The remedy. Many agreements limit remedies to service credits, sometimes stated as the sole remedy, and credits are often a fraction of the fee. A credit does not repay the cost of your client’s outage.
- How you claim. Deadlines, evidence requirements and who decides.
- Support response versus resolution. A response time commitment says someone acknowledged the ticket, not that it was fixed.
Compare what the SLA promises with what you have promised your clients. If your client contract commits you to a recovery time that the supplier’s contract does not support, the gap is yours.
Reading assurance reports and certificates
Suppliers often point at an independent report or certification. These are useful, and each has limits:
- A SOC 2 report is an auditor’s report on controls relevant to security and other criteria. A Type I report describes the design of controls at a point in time; a Type II report also tests whether they operated over a period. Read the scope (which services, which locations), the period, any exceptions noted by the auditor, and the complementary user entity controls, the controls the report assumes you will provide. Note also which functions are carved out to subservice organisations.
- An ISO/IEC 27001 certificate states that an information security management system was audited and found to conform to the standard within a stated scope. Ask for the scope statement and the statement of applicability, since the scope can be a small part of what you will use.
- Anything else: ask what was examined, by whom, when, and whether you can read it.
A logo on a web page does not tell you any of that. If the supplier will not share a report under confidentiality, record that as an answer.
Test, do not just ask
Where the supplier allows a trial or proof-of-concept environment, use it to turn claims into demonstrations. Test only the environment you have been given and within the terms of your agreement. In particular, do not scan or probe other customers’ systems or the supplier’s wider network.
- Network path and latency from where your users and tools are:
ping -c 20 test-endpoint.example.net
mtr -rwbc 100 test-endpoint.example.net # per-hop loss and latency over 100 probes- Storage behaviour with the load profile of your heaviest workload class, in an agreed window and on a scratch volume. See the test approach in virtual servers and capacity planning.
- A restore. Back up a test workload and restore it, timing both. Then ask for the same on a larger data set.
- Failure behaviour, if the supplier will agree: a controlled host evacuation or failover in the trial environment.
- Support. Open a low-severity ticket, then a more urgent one, and record acknowledgement and resolution times. Do it a few times over different hours.
- Access paths. Confirm you can get into the management interface, console and logs you will need, and that multi-factor authentication works as described.
Keep the results. They are the basis for your decision and your record if the service later falls short of what you saw.
Contract and exit terms
Exit terms decide how much leverage you keep once your tenants are running on the platform. Check:
- Data return: what you receive, in which formats, how quickly, and whether you can perform exports yourself at any time.
- Configuration return: virtual machine images, network and firewall configuration, backup repositories. Data without the configuration is half a migration.
- Cost of leaving: transfer charges, assistance charges, and any minimum term you would still owe.
- Overlap: whether you can run in parallel for a defined period while you migrate, and what that costs.
- Termination triggers: your right to terminate for repeated SLA failures, for security incidents, and for a change of control of the supplier.
- Price and term changes: notice periods, caps on increases, and auto-renewal.
- Deletion: the process and evidence when your data is removed, including from backups, and the timeline.
- Subprocessors and locations: who else touches your data and where, and what notice you receive of changes.
- Liability limits and insurance: how they compare with the exposure your clients’ contracts place on you.
Take legal advice on the contract itself. This article describes what to look for, not what the law requires in your jurisdiction.
A weighted comparison you build yourself
Once you have evidence, compare suppliers with a simple weighted matrix. The weights are yours and should be agreed before you look at any quotation, so the matrix cannot be tuned to a favourite.
score(supplier) = sum over criteria of weight(criterion) x rating(supplier, criterion)For instance, with ratings from 0 to 5 and weights adding to 100, you might weight isolation, recovery and exit terms heavily because they are expensive to fix later, and weight convenience features lightly. Rate only on evidence you hold, and give “unknown” a rating of zero rather than an optimistic guess. If two suppliers finish close, the tie-breaker should be the criterion where the cost of being wrong is highest.
Common mistakes
- Comparing price lists before comparing what is shared, what is measured and what is returned on exit.
- Accepting a badge as evidence. Ask for the scope, the period and the report.
- Believing recovery statements that measure one server when your risk is many tenants at once.
- Skipping the exit conversation because it feels pessimistic at the start of a relationship. It is cheapest then.
- Assuming the supplier’s support hours match yours.
- Never testing support until the first real incident.
- Letting one champion choose. Have someone who did not shortlist the supplier read the contract and the evidence.
What to do next
Take the question table to your shortlist and mark each answer by class. Run the requirements planner first so the question list reflects your estate, and read hosting economics so the commercial answers feed a model rather than a hunch.