
Cloud Planning
Part of Cloud vendor due diligence
Distinguishing a roadmap promise from an available cloud feature
Verify whether a promised cloud feature is released, supported and usable in the intended region, plan and account.
A roadmap statement is a supplier's intention, not proof that a feature can be bought, deployed or supported for your workload today. Before you depend on it, check the exact feature's release status, terms and availability in the intended service, region, plan and account.
Separate four questions
| Status | What it establishes | Buyer check |
|---|---|---|
| Roadmap or target date | The supplier has stated an intention | What works if delivery changes? |
| Preview or restricted access | Eligible customers may evaluate the feature under limited terms | Are access, data use, support and SLA terms acceptable? |
| Generally available | The provider describes the feature as released for production, subject to its terms | Is it offered in the required region and plan? |
| Available in your setup | The proposed account and configuration can use it | Does a representative acceptance check meet the requirement? |
General availability is stronger evidence than a roadmap slide, but it does not prove that the feature suits an application. An option shown in one account may be unavailable in another region or tier.
Release status vs buyer check
- Roadmap or target dateSupplier intention. Check what works if delivery changes.
- Preview or restricted accessEligible evaluation under limited terms. Check access, data use, support and SLA terms.
- Generally availableReleased for production, subject to terms. Check region and plan.
- Available in your setupProposed account and configuration can use it. Check representative acceptance test.
Read preview terms
Preview and pre-general-availability stages generally carry weaker commitments than general availability. Read the supplier's own terms for the specific offering, including whether an SLA applies, whether technical support covers it, and whether any restriction applies to personal data or other data subject to legal or regulatory requirements.
Microsoft describes Azure public preview as an evaluation stage with possible availability limits and typically no SLA. Its lifecycle guidance says public previews are not intended for production unless stated otherwise.
Azure's support-scope page says public previews are covered by support plans; that coverage does not create an SLA. Check the exact feature notice and purchase terms for the specific service.
Ask for configuration-specific evidence
Request a current product page or release note naming the feature and its status, supported regions and tiers, prerequisites, quotas, support route and applicable SLA. Record when it was checked.
If a sales presentation gives a future date, establish whether the proposed order makes that date binding and what happens if delivery slips. Do not treat a verbal estimate as a contractual commitment.
For an essential feature, define a proposed acceptance action before purchase. A data-export feature, for example, would need to produce the required records and metadata in a usable form under the intended permissions. That is a check to perform, not a reported result.
Evidence to request before approval
- Current product page or release note naming the feature and its status
- Supported regions and tiers
- Prerequisites, quotas and support route
- Applicable SLA and when it was checked
- Whether a future date is binding in the proposed order
- Acceptance action for essential features, such as data export producing the required records and metadata
Decide how much the roadmap matters
Mark the feature required now, useful later, or optional. If required now, hold approval until availability and suitability are evidenced, or use a design built on an available alternative.
If useful later, leave its expected benefit out of the current business case until it is delivered. Give the item an owner, review date and fallback.
Decide how much the roadmap matters
- ClassifyMark the feature required now, useful later or optional.
- Required nowHold approval until availability and suitability are evidenced, or design on an available alternative.
- Useful laterLeave its expected benefit out of the current business case until it is delivered. Give the item an owner, review date and fallback.



