sea of clouds, nature, mountain, natural, landscape, cloud, japan, light, mountain climbing
Photo by yamabon on Pixabay

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

StatusWhat it establishesBuyer check
Roadmap or target dateThe supplier has stated an intentionWhat works if delivery changes?
Preview or restricted accessEligible customers may evaluate the feature under limited termsAre access, data use, support and SLA terms acceptable?
Generally availableThe provider describes the feature as released for production, subject to its termsIs it offered in the required region and plan?
Available in your setupThe proposed account and configuration can use itDoes 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

  1. ClassifyMark the feature required now, useful later or optional.
  2. Required nowHold approval until availability and suitability are evidenced, or design on an available alternative.
  3. Useful laterLeave its expected benefit out of the current business case until it is delivered. Give the item an owner, review date and fallback.

More from Cloud Planning