A cloud assessment that starts with a logo wall — “these are the clouds,” “pick three names,” “who is in the catalog this quarter” — usually fails at the first unowned workload, not at the first brand. A logo wall is a screening collage. It is not a cloud assessment.
An assessment writes which workloads move, which stay, which region and placement model you will accept, how you leave, and which identities, keys, logs, and incident decisions remain yours. A wall proves that Cloud-shaped offerings exist. It does not prove placement, path, exit, or ownership. Hundreds of names can sit on a slide and still leave a restore test, a privileged account, and a degraded network hop unowned.
The usual shortcut treats the collage as the homework. Someone circles a familiar brand, asks for a landing-zone tour, and calls that “the cloud assessment.” The next meeting is a SKU walk-through. You still do not know which application is in scope, whether the path survives a failed on-ramp, or who accepts residual risk after an alert. Naming another operator does not create an assessment. It creates another slide.
That is why the live cloud provider evaluation starts with workloads, placement, path, and exit rather than a brand wall. This note does not replace that page. It is the assessment reminder that sits in front of it. If the next argument is “the provider secures the cloud,” stop and use the cloud security responsibility matrix before anyone treats a shared-responsibility cartoon as the assessment.
What the assessment must hold
- Decision identity: new landing zone, SaaS expansion, renewal, exit from a current stack, or a stay-or-move review — plus who approves.
- Workloads in and out: named applications, data classes, and what is explicitly staying where it is. A three-layer IaaS / PaaS / SaaS cartoon is not that inventory.
- Placement and path: per-workload model, region constraints, the network path, and the degraded state users will actually feel.
- Exit: portability you will accept, who owns the extraction, and what a later reviewer would treat as proof you can leave.
- Buyer-owned controls: identity, keys, configuration, reviewed logs, restore tests, and incident decisions. “The provider secures the cloud” is not an operating instruction.
Questions that belong in the first meeting
Ask the incumbent or a challenger to show, not describe:
- Which workloads they treated as in scope, and which they excluded from the collage.
- How each in-scope workload is placed, and what the user sees if the path degrades.
- What identities, keys, and restore tests remain the customer’s job on day one.
- What evidence a later reviewer would receive — a log, a ticket, a restore test — not a brand wall or a certificate pack.
If those answers are a logo wall and a promised monthly cloud total, you do not have a cloud assessment. You have a collage.
What this page is not
This is not a provider ranking, not a landing-zone product sheet, and not a claim that The Data Partner already moved anyone’s workloads after a catalog view. It is not a reprint of the live provider evaluation or the live responsibility matrix. Skip incentive talk, skip brand walls as a substitute for a written inventory, and skip any suggestion that a logo replaces an assessment. Write the workloads and the owners. Then use the live companions, or contact The Data Partner on that packet. Broader buying questions sit on the FAQs page.