Choosing a cloud managed service provider

The response times written into proposals look alike. What differs is when the clock starts. Detection, the moment a customer phones, or registration in the provider's ticket system — the same thirty minutes becomes a different promise under each. If the only intake channel is email, a 3 a.m. incident starts its clock when someone reaches their desk.

Read response and recovery apart. Most commitments cover first response, and few promise recovery. Contracts exist where first response is met, recovery takes days, and nothing has been breached. Have the provider write into the same table what happens after the response, how often progress is reported, and who can raise the severity. Without that table, chasing status becomes your team's job while the incident runs.

Check what happens when the commitment is missed. It usually ends with a credit against part of the monthly fee. Set against the loss from an outage, that is a small number, so read the clause as a penalty the provider assesses on itself rather than as compensation.

Rewrite severity definitions around your own service. Standard severity tables are often written around whether a server is up, while a payment path failing on an otherwise healthy system is your top severity. Putting your own definition of a severity one into an annex means nobody argues about grading at 3 a.m.

Whether a commitment has substance shows in staffing. Ask whether night duty is a staffed shift or an on-call rota, how many customers one engineer covers at once, and how many people know your service. Twenty-four hours on paper with nobody awake at night is closer to a promise to answer the phone.

Handing over operations means handing over access. Give away the top-level administrator account and the provider can do anything in your estate; narrow the rights too far and every incident waits on an approval while recovery slips. Draw the boundary by role. Keep read access and restarts open, and put resource creation, deletion and permission changes behind an approval step. A break-glass role that opens only during an incident keeps everyday rights narrow without slowing recovery.

Account ownership matters more. Where your resources sit inside an account in the provider's name, ending the contract means moving them, and that move is the size of a new project. Opening accounts in your own name and delegating administrative rights is the safer structure for later. Domains, certificates and DNS follow the same principle — a domain registered under the provider's account becomes a bargaining chip when the relationship sours. If you choose the structure where billing is handled for you, take the original provider invoice every month.

Look at whether there is a record of who did what and when. If the audit log accumulates only in the provider's account, you become the party requesting records after an incident. Have logs stored in your own account and put the retention period in the contract.

Ask about credential handling in the same conversation. Where server keys and database passwords are kept, how many days it takes to revoke access when a provider engineer leaves the account, and whether any of the work is subcontracted. Where it is, the people actually inside your estate work for a company the contract does not name.

Changes are more frequent than incidents. Patches, configuration edits and capacity additions happen weekly, and a large share of incidents trace back to the most recent change. Settle when the standard change window is, who approves an emergency change after the fact, and how many approvers sit on your side. Dates that cannot move — a financial close, a settlement run — go on the calendar first, and no window opens inside them. With no approver in your organisation, the provider changes things and records the change to itself.

Fix the format of the record too. A change history living in one engineer's chat log disappears the moment that engineer moves on. What changed, when, why, and the steps to reverse it have to sit in one place for an investigation to find the last change.

Approvals need a clock as well. Unless delays caused by your approval and delays caused by the provider are recorded separately, responsibility for slippage blurs every time. Whether reversing a failed change is inside the fixed fee is settled here too.

The monthly review is where this record is read. Last month's incidents, changes and open items are reported in one document and next month's work is agreed. If the review is a meeting where a few charts are read out, the provider is selling maintenance rather than improvement.

A provider monitoring through its own tooling is convenient while the contract runs. The problem is the ending. Where dashboards, alert rules and thresholds live inside the provider's subscription, observability switches off the day the contract does. How your service has been watched turns out to have been another company's asset in its entirety. Years of metric history go with it.

Confirm before signing who owns the tooling account, whether alert rules and dashboard definitions can be exported, and whether metric history can be handed over. The same holds for runbooks. A document listing the checks and commands for each incident type is an operational asset, and even where the provider wrote it, it is better kept in your repository as well.

Alerts are not judged by count. More alerts do not make a service safer; they make alerts easier to ignore. Ask what share of last month's alerts led to an actual action, and it becomes clear whether the provider has been designing alerts or merely leaving them switched on. Where most alerts close with no action, the duty engineer has already stopped reading them.

Quotes come in two shapes. A fixed fee is easy to budget, but what sits inside the number differs by contract. Unless it states how many requests a month are included, whether night calls are covered, and how many people the price assumes, busy months arrive with an extra invoice.

A usage fee charges for what was actually used. It is cheap in a quiet month and expensive in a month full of incidents, which makes teams hesitate to call at the exact moment they need to. Whichever you choose, ask for the list of separately billed items. Migration, rebuilds, new builds, security incident response and attendance at review meetings commonly fall outside an operations fee. With the list in hand, the proposal with the higher fixed fee sometimes turns out cheaper in total.

Where the provider resells cloud consumption, ask for the margin. When consumption and operations arrive on one invoice, you cannot see which of the two went up. If cost reduction is part of the same engagement, note where interests diverge: with a margin on consumption, lower usage means lower revenue for the provider.

The commercial terms carry a price of their own. Whether onboarding is charged separately, the minimum term, an automatic renewal clause, and how many weeks of notice termination requires together set the price of your freedom to leave. A contract with a cheap first month and a three-month notice period is not a cheap contract.

A managed operations contract is harder to end than to start, which is why the exit clause is read before signing. It has to state the scope and length of handover, how many weeks of parallel running there are, in what format documents and scripts are delivered, and who transfers the permissions and when. Check at the same point whether handover is billed as a separate charge.

When the wrong contract ends, the environment stays and the explanation leaves. Nobody knows why a given resource exists, alerts are switched off, and the recovery procedure lived only in one engineer's memory. The next provider spends months just mapping that state. That time was part of what you paid. It is not what a bad provider does to you; it is what happens when nothing was written about what would be left behind.

So the criterion is closer to the assets that remain than to the report that arrives each month. Have proposals state what you receive in the first month and what you get back in the last, and two bids at similar prices turn out to have been different products.

There is also a way to start small. Hand over a single quarter's scope first and decide on expansion from the documents and response records it produces, and the judgement rests on real operations rather than on a proposal. A provider that writes down what a trial period will leave behind, rather than declining one, usually ends the contract cleanly too.