The CloudHealth Transition Playbook: How Enterprises and MSPs Can Thrive After Moving On

The CloudHealth Ownership Chain, Updated

If you have been following CloudHealth through its ownership transitions, here is the complete picture as of April 2026:

CloudHealth Ownership and Branding Timeline
──────────────────────────────────────────────────────────────
2012    CloudHealth Technologies founded
2018    Acquired by VMware → CloudHealth by VMware
        (also: VMware Aria Cost powered by CloudHealth)
2023    Broadcom acquires VMware → VMware Tanzu CloudHealth
Feb     Broadcom Advantage Partner Programme launches
2024    — $500K/year VMware revenue minimum for MSPs
May     Arrow Electronics becomes sole global CloudHealth
2024    provider via ArrowSphere Cloud marketplace
Jun     New CloudHealth experience at FinOps X:
2025    Intelligent Assist (AI co-pilot) + Smart Summary
2026    Platform continues under Broadcom/Arrow structure
        — pricing, distribution, eligibility unchanged
──────────────────────────────────────────────────────────────
Result: 4 rebrands, 3 ownership structures, 1 distributor,
        and an MSP eligibility cliff in 8 years

The June 2025 launch of the “new CloudHealth experience” at FinOps X was the most significant CloudHealth product investment since the Broadcom acquisition. Intelligent Assist — a large language model-enabled co-pilot that allows users to query CloudHealth data in natural language — and Smart Summary — an AI-powered explanation of cloud cost changes — represent genuine product development. Broadcom has made clear its commitment to continued CloudHealth innovation.

What has not changed: the ~3% of cloud spend pricing model, the Arrow Electronics exclusive distribution arrangement, the $500,000/year VMware revenue threshold for MSP programme eligibility, and the structural positioning of CloudHealth as a product within a semiconductor company’s software portfolio rather than a dedicated FinOps company’s core mission.

This briefing covers both dimensions: what CloudHealth has improved, and what the structural risks are for enterprises and MSPs evaluating a longer-term FinOps platform decision.

---

What Changed for Enterprises

1 — The Pricing Model That Scales With Your Problem

CloudHealth’s published pricing is approximately 3% of tracked cloud spend — a model that charges enterprises proportionally for the cloud estate they manage, not for the value delivered.

For an enterprise with $500,000/month in cloud spend:

CloudHealth annual cost at 3% of spend:
$500,000/month × 3% × 12 = $180,000/year in platform fees

If cloud spend grows 40% (driven by AI workloads):
$700,000/month × 3% × 12 = $252,000/year
— a $72,000/year platform fee increase from AI adoption alone

The problem is structural: a percentage-of-spend model creates a platform fee that grows as the cloud cost problem grows. The fastest-growing category of enterprise cloud spend is AI workloads — GPU clusters, LLM inference, agentic AI deployments. The enterprises that most need FinOps governance for AI cost growth pay the highest fees for a platform that was architected for cloud infrastructure governance, not AI workload governance.

The alternative model: flat enterprise licensing (or flat per-account pricing) that bounds the platform cost regardless of cloud spend growth — so FinOps governance can scale as aggressively as AI adoption without creating a platform cost spiral.

---

2 — The Sole-Distributor Layer

Arrow Electronics became the exclusive global provider of CloudHealth in May 2024. This arrangement was designed to expand CloudHealth’s market reach and provide enterprises with specialised support.

The practical consequence for enterprise buyers: commercial relationships, support escalation paths, and contract negotiations now involve a distribution layer that did not exist before. Arrow will provide sales, marketing, and technical support for CloudHealth — which creates value in terms of support breadth but adds an intermediary to every commercial conversation with the platform vendor.

For enterprises with existing direct CloudHealth relationships, this transition changed the account management structure. For new enterprise buyers, Arrow is the commercial entry point.

---

3 — The Roadmap Question

Broadcom’s June 2025 product announcement demonstrated meaningful investment in CloudHealth’s FinOps capabilities. The new experience is genuinely improved — cleaner UX, generative AI co-pilot, faster insight delivery.

What enterprise architects are also asking: what is the strategic positioning of CloudHealth in a portfolio that includes VMware, Broadcom networking, and semiconductor products? The platform’s roadmap is determined by a division within a company whose primary business is not cloud financial management. Integration emphasis appears to be increasing toward VMware/Broadcom ecosystem rather than cloud-agnostic capabilities.

For enterprises with deep VMware and Broadcom ecosystem dependency, this alignment has value. For enterprises seeking platform-agnostic FinOps governance across AWS, Azure, GCP, Databricks, and AI platforms, the alignment risk is different.

---

4 — The AI Governance Gap

98% of FinOps teams now manage AI spend. This is the most important fact about the 2026 FinOps platform landscape for any enterprise evaluating a CloudHealth transition.

CloudHealth’s June 2025 Intelligent Assist is an AI co-pilot for navigating CloudHealth’s own data — a chatbot interface for existing platform capabilities. It is not AI workload cost governance: not GPU cluster attribution, not LLM inference cost per team, not token budget enforcement, not agentic workflow kill-switches.

For enterprises running Azure OpenAI, AWS Bedrock, Vertex AI, and GPU Kubernetes clusters alongside their cloud infrastructure, a FinOps platform evaluated in 2026 must govern AI workloads as a primary capability — not as a roadmap item.

---

What Changed for MSPs

The Eligibility Cliff

The Broadcom Advantage Partner Programme’s $500,000/year VMware revenue minimum is the single largest structural change for MSPs evaluating CloudHealth.

The minimum threshold was designed to prioritise partners aligned with Broadcom’s large-enterprise commercial strategy. It reflects Broadcom’s decision to focus CloudHealth on a narrower, higher-value partner segment.

For the majority of MSPs serving SMB and mid-market customers — where managed cloud services are delivered at $10,000–$100,000/month per client rather than enterprise-scale spend — this threshold is either unachievable or commercially irrelevant to their actual business model. CloudHealth was historically valuable precisely to these MSPs because of its multi-tenant management, Partner Generated Billing for AWS, and FinOps service delivery capabilities.

“Since the acquisition of VMware by Broadcom, there’s just been a great deal of confusion and concern in the market. Companies are asking all sorts of questions like, ‘How much are costs increasing from VMware? What’s this 27 SKUs down to three options that people are talking about? Do we have options to move to other providers?’” — Allen Skipper, SVP at Expedient

MSPs that built their FinOps service delivery around CloudHealth now face three paths: qualify for the Broadcom programme (requiring substantial VMware product sales), remain on the Arrow distribution model without full programme status, or evaluate alternatives built specifically for MSP economics.

The Multi-Cloud Data Delay Problem

Broadcom’s status page documented delays in processing GCP and Azure asset updates. For MSPs managing multi-cloud client estates — where real-time accuracy across all providers is a service delivery requirement, not an optional feature — processing delays in secondary-cloud providers create:

• Inaccurate client cost reporting during delay windows
• Extended troubleshooting time when delayed data creates anomalous-appearing cost patterns
• Strategic planning gaps when forecasting is based on incomplete multi-cloud data
• Client trust erosion when billing conversations are based on data that doesn’t reflect current consumption

The multi-cloud MSP needs equal accuracy and equal timeliness across AWS, Azure, and GCP. A platform historically architected for AWS-depth with secondary cloud support does not provide this symmetry.

---

Five Migration Triggers: When It Is Time to Evaluate Alternatives

Not every enterprise or MSP should migrate away from CloudHealth. The right answer depends on the specific business context. But five signals indicate that a structured evaluation is warranted:

Trigger 1 — Cloud Spend Growth Is Making the Platform Fee Untenable

If the combination of cloud spend growth and AI adoption is causing the CloudHealth fee to become material relative to the savings the platform generates, the percentage-of-spend pricing model has inverted the FinOps value equation. When the platform for governing cloud spend costs more to operate than the waste it eliminates, evaluation is appropriate.

Trigger 2 — AI Workloads Are Your Fastest-Growing Cost Category

If GPU clusters, LLM inference, Databricks DBUs, and AI API consumption are now significant portions of the cloud estate, the FinOps platform must govern them with the same attribution depth as cloud infrastructure. If AI costs are appearing in the cloud bill as undifferentiated spend with no workload-level attribution, the current platform has a governance gap that is growing faster than the estate it governs.

Trigger 3 — MSP Programme Status Is Uncertain or Ineligible

If the Broadcom Advantage Partner Programme eligibility threshold is not met — or if meeting it would require changing the MSP’s commercial strategy rather than its FinOps service delivery — the partner relationship with CloudHealth has fundamentally changed. A platform that is commercially inaccessible to the MSP’s market position is not a viable long-term service delivery foundation.

Trigger 4 — Regulated Industry Deployment Requirements Conflict With SaaS-Only Architecture

If the enterprise operates in banking, insurance, healthcare, or government, and data sovereignty or security requirements restrict sending financial data to SaaS vendor infrastructure, CloudHealth’s SaaS-only deployment model creates a structural compliance risk. BYOC deployment capability is not a feature preference in these environments — it is a compliance requirement.

Trigger 5 — Multi-Cloud Parity Is Required Across AWS, Azure, GCP, and Databricks

If the cloud estate includes Databricks workloads, Kubernetes GPU clusters, OCI, or Alibaba Cloud alongside the three major hyperscalers — and if equal attribution depth, equal timeliness, and equal optimisation capability is required across all of them — a platform with an AWS-heritage governance depth and secondary multi-cloud support may not satisfy the full estate requirements.

---

What a Modern FinOps OS Offers That a Legacy Cost Reporting Tool Cannot

The FinOps platform landscape has more than 115 tools in 2026. The distinction that matters for enterprises evaluating a CloudHealth transition is not between FinOps tools — it is between legacy cloud cost reporting platforms and modern FinOps Operating Systems.

Legacy cloud cost reporting tools — many first-generation platforms including those that have been through multiple acquisitions — were built for the cloud estate of 2015: AWS-centric, infrastructure-focused, designed around tagging schemas and cost allocation views. They have been extended to address multi-cloud, Kubernetes, and increasingly AI — but the extensions are built onto a legacy architecture.

Modern FinOps Operating Systems are architected for the full-stack technology cost surface of 2026: cloud, AI, SaaS, marketplace transactions, data platforms, Kubernetes, and on-premises — in a unified FOCUS 1.x cost model with real-time enforcement, AI workload governance, and business-outcome attribution as first-class capabilities.

The capability gap between the two architectures is significant across six dimensions:

Capability	Legacy Reporting Tool	Modern FinOps OS
Cost schema	Proprietary, cloud-provider-aligned	FOCUS 1.x native
AI governance	Dashboard visibility at best	Native token attribution + automated enforcement
Pricing model	% of cloud spend	Flat enterprise licensing
Deployment	SaaS-only	SaaS + BYOC
Agentic AI	Not addressed	Per-chain attribution + kill-switch infrastructure
Attribution scope	Cloud infrastructure	Cloud + AI + SaaS + Marketplace + Databricks

---

DigiUsher’s FinOps OS: Built for the Transition

DigiUsher’s FinOps Operating System is purpose-built for enterprises and MSPs that need what CloudHealth’s architecture was not designed to deliver — and what the 2026 AI-era cloud estate requires.

For Enterprises

Transparent, flat enterprise licensing — including Enterprise Unlimited self-hosted through BYOC (Secure Relay Proxy). Your platform fee does not grow when your cloud spend grows. AI adoption does not create a fee spiral.

AI workload cost governance — Azure OpenAI, AWS Bedrock, Google Vertex AI, GPU Kubernetes clusters (EKS, AKS, GKE, OKE), Databricks, and direct API providers governed natively with FOCUS 1.x attribution. Cost per inference, cost per AI feature, cost per model training run — produced continuously, not as a chatbot interface to existing infrastructure billing.

FOCUS 1.x native architecture — not a compatibility layer. Cross-cloud, cross-AI-provider attribution that produces accurate unit economics, marketplace governance, and business-outcome mapping from a genuine unified cost model.

BYOC for regulated industries — Secure Relay Proxy deployment for banking, insurance, healthcare, and government. ICICI Bank is a DigiUsher customer in exactly this context. SOC 2® Type II certified and GDPR compliant.

Direct enterprise relationships — through AWS ISV Accelerate (listed on AWS Marketplace), Azure ISV Co-Sell Ready (listed on Azure Marketplace), and Google Cloud Partner status. No single-distributor intermediary dependency.

For MSPs

No VMware revenue eligibility threshold — DigiUsher’s partner programme serves resellers, MSPs, and System Integrators at every scale. SMB-focused MSPs are welcome, not structurally excluded.

Multi-tenant, multi-billing architecture — purpose-built for MSP service delivery: consolidated billing across client estates, partner margin support, white-labelling capability, and management across client tenants from a single console.

Equal multi-cloud depth — AWS, Azure, GCP, Kubernetes, Databricks, Alibaba Cloud, and AI platforms with equal attribution accuracy and equal timeliness across all providers. No secondary-cloud processing delays.

Delivered globally through Infosys, Wipro, and Hexaware — SI partner delivery for enterprises requiring implementation support and managed service delivery at scale.

---

The Migration Process: Five Phases

A well-executed CloudHealth migration preserves the governance continuity that enterprises and MSPs have built — while enabling the expanded capabilities that a modern FinOps OS provides.

Phase 1 — Pre-Migration Audit (Weeks 1–2)

Document everything in the current CloudHealth configuration before migration begins:

• All Perspectives and FlexOrg structures — the custom business context logic that took months to build
• Policy rules and governance thresholds
• Budget configurations and alert definitions
• MSP billing rules and partner margin structures
• Stakeholder dashboards and report schedules

This inventory is the migration specification. The most common migration failure mode is discovering undocumented configuration mid-migration.

Phase 2 — FOCUS Normalisation Mapping (Weeks 2–4)

Translate the CloudHealth cost schema — Perspectives, FlexOrgs, and tag-based allocation rules — to FOCUS 1.x attribute mappings. This translation is the technical foundation of the migration:

CloudHealth Perspective → FOCUS FinOps Dimension
FlexOrg structure      → FOCUS SubAccountName + Tags
Custom tag groups       → FOCUS ResourceTags
MSP billing markups     → FOCUS ChargeFrequency + Pricing adjustments

A FOCUS-native platform ingests this translated schema and produces attribution output that maintains continuity with the historical data patterns your finance and engineering teams recognise.

Phase 3 — Parallel Operation (30–60 Days)

Run both platforms simultaneously for 30–60 days. Validate:

• Attribution accuracy: do cost allocations match between platforms within acceptable variance?
• Dashboard parity: do stakeholder reports show consistent patterns?
• MSP billing equivalence: do client invoices reconcile between platforms?

This phase is the quality gate. Do not decommission CloudHealth until parallel operation validates that the new platform produces governance output at parity or above.

Phase 4 — Stakeholder Transition

Before decommissioning CloudHealth, validate that every stakeholder audience has an equivalent or improved experience in the new platform:

• Finance: budget tracking, commitment utilisation, forecast accuracy
• Engineering: namespace-level cost attribution, anomaly detection, rightsizing signals
• CxO: cost-per-product, cloud ROI, AI investment attribution
• MSP clients: white-labelled dashboards, billing accuracy, multi-cloud visibility

Phase 5 — Expanded Capability Deployment

The migration is the opportunity to deploy capabilities that CloudHealth’s architecture does not provide:

• AI workload governance: token budget enforcement, agentic workflow attribution, GPU idle detection
• Marketplace analytics: private offer ROI, committed spend tracking, AI vendor attribution
• FOCUS-native reporting: cross-provider unit economics, LCOAI analysis, business-outcome mapping

The migration is not a like-for-like replacement. It is the foundation for FinOps maturity that the legacy architecture could not support.

---

Frequently Asked Questions

What happened to CloudHealth after the Broadcom acquisition?

Broadcom acquired VMware in February 2024, bringing CloudHealth into its Tanzu portfolio. In May 2024, Arrow Electronics became the sole global CloudHealth provider through ArrowSphere. In June 2025, Broadcom launched the new CloudHealth experience with Intelligent Assist (AI co-pilot) and Smart Summary dashboards. The platform continues under Broadcom’s Tanzu division — pricing at ~3% of cloud spend, distributed exclusively through Arrow, with $500K/year VMware revenue required for MSP programme eligibility.

What are CloudHealth’s current pricing terms?

Published AWS Marketplace listings show CloudHealth pricing at approximately 3% of tracked cloud spend. 12-month plans range from $45,000/year (up to $150K monthly AWS spend) to $150,000/year (up to $500K). Overages are billed at $0.03 per dollar above contracted tiers. 12-month minimum contracts required; discounts available for 24 and 36-month commitments. For growing estates particularly with AI workloads, a percentage-of-spend model creates platform fees that scale with the cost growth FinOps is meant to govern.

What are the MSP partner programme requirements for CloudHealth?

Broadcom’s Advantage Partner Programme requires MSPs to demonstrate minimum $50,000/month or $500,000/year in VMware revenue to qualify. Partners are evaluated on performance metrics, technical capabilities, market reach, financial stability, and customer base. This threshold structurally excludes most SMB-focused MSPs.

When should enterprises consider migrating from CloudHealth?

Five triggers warrant structured evaluation: the platform fee is material relative to savings delivered (percentage-of-spend model); AI workloads are the fastest-growing cost category and lack workload-level attribution; MSP programme status is uncertain or ineligible; regulated industry requirements conflict with SaaS-only deployment; or multi-cloud parity is required across AWS, Azure, GCP, and Databricks simultaneously.

How does DigiUsher differ from CloudHealth?

Six structural differences: flat enterprise licensing versus ~3% of cloud spend; native AI workload governance (Bedrock, Azure OpenAI, Vertex AI, Databricks) versus cloud infrastructure heritage; FOCUS 1.x native versus proprietary schema; SaaS + BYOC versus SaaS-only; open MSP programme versus $500K VMware revenue threshold; dedicated FinOps OS company versus Broadcom portfolio product.

What does a CloudHealth migration look like?

Five phases: pre-migration audit (document all Perspectives, FlexOrgs, policies, MSP billing rules); FOCUS normalisation mapping (translate configuration to FOCUS 1.x attribute schema); parallel operation validation (30–60 days with both platforms running); stakeholder transition (validate finance, engineering, CxO, and MSP client dashboards); expanded capability deployment (AI governance, marketplace analytics, FOCUS-native reporting).

How does DigiUsher support regulated enterprises requiring BYOC deployment?

DigiUsher’s Secure Relay Proxy enables BYOC deployment where cloud cost data is processed within the enterprise’s own cloud infrastructure — AWS, Azure, or GCP — without billing data leaving the enterprise’s own environment. This deployment model satisfies data sovereignty requirements in banking, insurance, healthcare, and government. ICICI Bank operates DigiUsher in this context. The platform is SOC 2® Type II certified and GDPR compliant.

---

References

• Broadcom — Arrow Electronics Tapped as Sole Global CloudHealth Provider (May 2024)
• Broadcom — New CloudHealth Experience Announced at FinOps X (June 2025)
• Channel Futures — Broadcom VMware Partner Programme: $500K/year Qualification Threshold
• Holori — CloudHealth Pricing 2025: 3% of Cloud Spend Analysis
• Holori — 20 Best FinOps and Cloud Cost Management Tools in 2026
• Ternary — FinOps Tools for MSPs: The Top 6 Platforms (January 2026)
• Ternary — Best FinOps Tools Guide 2026
• Cloudaware — FinOps Tools 2026: Comprehensive Guide
• nOps — Top CloudHealth Alternatives and Competitors 2026
• FinOps Foundation — State of FinOps 2026
• FinOps Foundation — FOCUS Specification
• Broadcom Status — CloudHealth GCP and Azure Asset Processing Delays (documented)
• CRN — WWT CEO on Broadcom VMware Strategy

---

Begin Your FinOps Platform Evaluation Today

The CloudHealth transition is not about choosing the wrong platform — it is about ensuring your FinOps platform is matched to the cloud estate you are governing in 2026, not the one you governed in 2020.

DigiUsher’s FinOps OS provides a structured migration path for enterprises and MSPs evaluating a CloudHealth transition — with transparent pricing that does not scale with cloud spend, native AI workload governance, BYOC for regulated industries, and a partner programme built for MSPs at every scale.