Choosing a Managed Cloud Service Provider: Five Questions to Ask Before You Sign

Picking a managed cloud service provider is a multi-year commitment that will touch every part of your infrastructure. It is also one of the IT decisions where marketing quality and service quality correlate least reliably. The vendors with the best slide decks are often not the vendors with the best operations practices, and the reverse is frequently true — the MSPs we respect most tend to be the ones who do not have a dedicated marketing team.

After 23 years in the managed services business, here are the five questions we would ask any MSP before signing a contract, including questions we would ask ourselves. If a vendor dodges any of them, take it as a warning.

1. Who is on call tonight, and how fast do they know my environment?

This question sounds mundane and is actually diagnostic. An MSP with a real 24x7 operations practice can answer it specifically: here is our on-call rotation, here is the tier-one engineer who takes the initial page, here is how they escalate, here is the tier-two engineer who has access to your environment, here is the documented handoff process. The whole thing should take the MSP about two minutes to walk through because they walk through it with every new customer.

An MSP that fakes 24x7 coverage will give you a vaguer answer. "We have on-call engineers." "Tickets get routed to our overnight team." "We guarantee a response within X hours." The tells are the passive voice, the absence of names, and the lack of detail about the handoff from triage to resolution. Vague answers here mean vague coverage. When the outage happens at 2 a.m. — and it will — the difference between an engineer who can start working immediately and a triage technician who has to escalate twice is the difference between a 20-minute outage and a 4-hour outage.

While you are at it, ask specifically how long it takes for an on-call engineer to load your environment context. Do they have dashboards pre-built for your stack? Do they have runbooks for your common incidents? Have they practiced the response, or is this the first time they will see it? The answers tell you what you are actually paying for.

2. Show me a runbook for a real incident.

This is the single highest-signal question in an MSP evaluation and almost nobody asks it. Runbooks are the operational documentation that tells an engineer, step by step, how to respond to a known class of incident. A mature operations practice has dozens of them. An immature one has none, and the responses are improvised by whoever happens to be on call.

Ask the MSP to walk you through a real runbook for a common incident — a failed backup, a disk full alert, a high CPU condition, a certificate about to expire, a ransomware indicator of compromise. You are not looking for the secret sauce. You are looking for whether the document exists, whether it is current, whether it includes specific commands and decision points, and whether the engineer showing it to you actually uses it day to day.

A good MSP will hand you a sanitized example without flinching. A bad MSP will tell you that runbooks are proprietary, or that they do not share them with prospects, or that they use a "ticket-based approach" instead of runbooks. All of these are polite ways of admitting that the runbooks do not exist and the operations practice is improvised. Improvised operations work until they do not, which tends to be during the incidents you most needed them to work.

3. How does a change get approved, scheduled, and rolled back?

Change management is the second-highest-signal question. Most IT outages are self-inflicted — somebody made a change that broke something, and the recovery time depended on how well the change was scoped, tested, and reversible. A good MSP has a specific change management process with defined roles, approval gates, scheduled windows, pre-change snapshots or backups, and a rollback plan for every change that might affect a production workload.

Ask to see an example change ticket from the MSP's current operations. You want to see a change description, a risk assessment, an approval chain, a scheduled window, a test plan, and a rollback plan. If the ticket is a one-liner that says "apply patches" with no further detail, the change management is informal and the risk of self-inflicted outages is high. If the ticket is detailed and structured, you are looking at a real operations practice and you can be confident that changes to your environment will be handled the same way.

Pay particular attention to how the MSP handles emergency changes — patches for zero-day vulnerabilities, fixes for active incidents, configuration changes to stop ongoing attacks. The process should be different from routine changes (faster, with streamlined approvals) but still traceable and reversible. An MSP that handles emergency changes identically to routine changes will be too slow when speed matters. An MSP that has no process at all for emergency changes will be too reckless.

4. What SLA metrics can you show me from your current book of business?

This is where most MSP evaluations fall apart. The proposal will list an SLA — response time, resolution time, availability, whatever. What the proposal usually will not tell you is whether the MSP is currently meeting those SLAs for their existing customers. That number is the single best predictor of whether they will meet them for you.

Ask for current metrics. Not marketing numbers. Not averages computed in ways you do not understand. Actual monthly SLA compliance across the MSP's book of business, preferably for the last 12 months, with a breakdown by severity or SLA tier. A confident MSP will share this with a non-disclosure agreement in place. A nervous MSP will give you reasons why they cannot share it. The reasons are always plausible. They are never the real answer, which is that the numbers do not look good.

While you are at it, ask about customer retention. An MSP with a healthy book of business has low churn, long-tenured customers, and references you can actually call. An MSP with high churn has a constant stream of new customers who discovered the problems and left, usually within 18 months. Ask for three references from customers who have been on service for at least three years. If the MSP cannot provide them, it is because the three-year customers do not exist.

5. What will you not do?

This is the question that tells you whether you are talking to an honest vendor or a sales motion. A good MSP has a specific scope of service and a specific list of things that fall outside it. They will tell you what those things are without being pressed, because they know that scope clarity is what makes the relationship work over time.

An MSP that will not name its limits is either lying about the scope or is about to hit you with out-of-scope charges that do not appear in the proposal. The classic pattern: "full managed cloud services" turns out not to include application-level support, or database tuning, or custom integrations, or anything the MSP did not anticipate. When those things come up — and they always do — you either pay a time-and-materials rate or you do the work yourself. Either way, the fixed monthly fee you budgeted for is not what you end up paying.

Ask explicitly: what is included, what is out of scope, what requires a change order, and how out-of-scope work is priced. Write the answers down and compare them to the proposal. Where the proposal is vague, ask for specifics in writing. The best MSPs find this conversation easy because they have it with every customer. The worst MSPs find it threatening and will resist the detail, which is exactly the signal you need.

The short version

Pick an MSP the same way you would pick a long-term business partner: with specific, uncomfortable questions about how they actually operate. The marketing is not the product. The runbooks, the change process, the on-call coverage, the SLA history, and the scope discipline are the product. Vendors that have those things will answer the questions above clearly. Vendors that do not will dodge, reframe, or try to move the conversation back to the slide deck. Both responses are telling you exactly what you need to know. Trust what the answers reveal, not what the brochure promises, and your managed cloud relationship will be one of the better decisions you make this year.