The criteria that actually decide it
Most criteria are table stakes. Cloud services differ less than their marketing suggests, and five criteria carry real weight. Each of the five can be verified rather than taken on trust.
The difference between a claim and a fact is the whole game here. Every cloud service provider says they are secure, reliable and good value. Ask for the artefact that proves it.
Compliance and data residency
Ask for the current certificate and read its scope statement. A logo on a web page tells you a company holds something. The scope statement tells you which services and which regions it covers, and the two are often not the same.
The artefacts worth requesting are an ISO/IEC 27001 certificate and a SOC 2 report. For the SOC 2, check the period it covers and read the exceptions section rather than the summary. An expired report or a scope that excludes the service you plan to use is a real finding, and it is the kind of thing that surfaces in ten minutes of reading.
Data residency is a yes or no question with a contractual answer. Get it in writing, including where backups and support access sit, not only the primary region.
Our post on cloud security best practices covers what you do with data security once you are running. At selection stage, the job is narrower: confirm what the provider is contractually responsible for, and what stays yours under the shared responsibility model. Data security at selection stage is a contract question, not a configuration question.
The service level agreement
Read what the uptime number excludes. Scheduled maintenance, regional events, anything the provider classes as outside its control, and any service you plan to use that is not covered by the headline figure.
Then check what a breach is worth. Service credits are usually a percentage of that month's bill for the affected service, capped, and claimable only if you notice and file within a window. A credit rarely covers what an outage costs you, so treat the service level agreement as a statement of intent rather than insurance.
One question settles a lot: has anyone actually claimed a credit, and what did that process look like?
Real cost, not calculator cost
The calculator covers compute and storage. The bill includes four things it usually does not.
Data egress, which is charged when you move data out and which turns a monthly saving into a migration bill. Support, which is often a percentage of spend and which the calculator assumes you do not need. Environments you forgot, because staging, testing and disaster recovery are real infrastructure. And the introductory discount that expires, which is why you should model year three rather than year one.
Run the numbers at three times your current volume. In cloud computing, scalability is a pricing property as much as a technical one. Some cloud services get cheaper per unit at scale, and others get sharply worse.
Support and escalation
Find out who you reach at two in the morning, and how long before a human answers.
Get the response commitment for your severity level in writing, at the tier you will actually buy rather than the top one. Then ask what the escalation path looks like when the first response does not solve it. A support tier with a fast acknowledgement and no route to an engineer is a ticket queue.
The skills you already have
No criteria list includes this one, and it predicts success better than most that do.
A platform your team already knows is faster to build on, cheaper to operate and much less likely to produce an expensive misconfiguration. A platform nobody knows costs you a training curve, a hiring problem, or a consultancy you did not budget for.
This does not mean never switch. It means put a real weight on it, because the alternative is discovering the cost after the cloud migration.
