Goal of the analysis:
Quantify how much infrastructure/application run and build spend is in public cloud versus on-premises, understand the drivers of shifts over time, and assess whether the mix aligns with strategy, cost efficiency, and risk. Cloud vs On-Prem Spend Mix helps executives validate cloud transformation progress, detect duplication (paying for cloud while data centers remain), and optimize commercial and technical posture. The objective is a deliberate, value-anchored mix: use cloud where elasticity, speed, and services add value; keep or exit on-prem intentionally; avoid stranded costs and unmanaged growth.
Data required:
- Financial foundations:
- ERP/GL actuals: OpEx by TBM tower (Infrastructure/Cloud, Applications, End-User, Security), CapEx, and D&A for on-prem assets.
- Data center costs: power, space, cooling, facilities, network, managed services.
- Chargebacks/showbacks, intercompany allocations, extraordinary items (migrations, write-offs).
- Cloud billing and usage:
- Public cloud invoices and detailed usage (AWS/Azure/GCP): services (IaaS, PaaS, managed DB, storage, network), discounts (RIs/SPs/CUDs), credits, tags (app/env/owner).
- SaaS spend (optional separate lens): subscription and usage if included in “cloud” scope.
- On-prem asset and run data:
- Hardware inventories and depreciation schedules; support/maintenance contracts; storage/network platform costs.
- Virtualization platform metrics (allocation/consumption) for allocation drivers.
- Allocation and scope metadata:
- TBM taxonomy, environment (prod/non-prod), application mapping (CMDB), business unit/product attribution.
- Scope rules: what counts as “cloud” (IaaS/PaaS/SaaS?) and “on-prem” (colocation included, private cloud, mainframe).
- Contracts and commitments:
- Cloud commitments (RIs, Savings Plans, CUDs), enterprise discounts, egress terms; data center leases and exit clauses.
- Renewal dates for major vendors to interpret spend inflections.
- Transformation context:
- Migrations in flight, decommission plans and milestones, application hosting model targets (to/from cloud), wave plans and dates.
- Systems and sources:
- ERP/GL, ITFM/TBM (Apptio/ServiceNow), cloud billing tools (CUR/Cost Management/BigQuery), CMDB, DC facilities systems, contract repositories, BI/warehouse.
Detailed step-by-step instruction on how to conduct the analysis:
- Define scope and views:
- Primary metric: Cloud % = Cloud spend ÷ (Cloud + On-prem infra spend) × 100%.
- Report both cash view (OpEx + CapEx) and P&L view (OpEx + D&A). State whether SaaS is included or shown separately.
- Focus base case on infrastructure run (compute, storage, network, platform). Provide variants: including Change spend; including SaaS.
- Extract and normalize:
- Pull monthly actuals from ERP/ITFM mapped to TBM; extract cloud detailed billing and credits; gather DC facility costs and on-prem support.
- Align fiscal periods, currencies, and remove pass-throughs/double counts; flag one-time migration costs.
- Classify spend to Cloud vs On-prem:
- Cloud: IaaS/PaaS/managed services usage net of credits; optional SaaS lens reported separately.
- On-prem: HW depreciation, support, facilities (power/space/cooling), network backbones, storage arrays, virtualization licenses, managed services.
- Hybrid/ambiguous (e.g., colocation, private cloud): treat as on-prem unless policy states otherwise; document exceptions.
- Allocate shared and mixed costs:
- Split shared contracts (security/observability) by consumption tags or proportional to direct infra spend.
- Allocate DC facilities to on-prem pools using kW/rack/TB drivers; allocate network transit by traffic shares.
- Compute core metrics:
- Monthly/quarterly Cloud %, On-prem %, and TTM trend for both cash and P&L views.
- Breakouts: compute vs storage vs network; prod vs non-prod; region; BU/product.
- Companion efficiency: commitment coverage, idle/underutilized cloud percent, DC occupancy/utilization.
- Driver analysis (bridge):
- Bridge change vs prior period into: volume/consumption shifts, price/rate changes, mix (service/tier/region), decommissions, stranded DC costs, one-time items, FX.
- Quantify “double run” (cloud growth without corresponding DC decline).
- Segment and benchmark:
- By BU/product, region, application tier (customer-facing vs internal), risk/regulatory class, lifecycle (legacy vs modern).
- Compare to peer bands where available; create internal quartiles by archetype.
- Migration correlation:
- Overlay mix trend with migration milestones; verify DC exits or platform retirements occur within 0–6 months of cloud cutover.
- Quantify stranded cost tail (e.g., DC lease commitment through date) and plan reductions.
- Scenario analysis:
- Project Cloud % under planned migrations and DC exits; include savings/one-time costs.
- Test sensitivity to cloud rate changes (+/−10%), egress changes, or commitment coverage shifts.
- Validate and institutionalize:
- Review classification and bridges with Finance, TBM, platform owners; reconcile to GL and cloud bills.
- Publish a quarterly dashboard; maintain policy notes (scope, SaaS treatment) and an assumptions log.
Format of the output of analysis:
- Executive summary: current Cloud % (cash and P&L), 8–12 quarter trend, double-run estimate, and top drivers.
- 100% stacked bars or area charts: Cloud vs On-prem over time with TTM smoothing.
- Bridge/Waterfall: YoY Cloud % change decomposed (volume, price, mix, decommissioning, stranded DC, one-time).
- Mix by category: compute, storage, network; prod vs non-prod; region/BU heat map.
- Efficiency panel: cloud commitment coverage, idle/underutilized cloud, DC occupancy/utilization, egress spend share.
- Migration alignment: timeline of cutovers vs DC exits and decommissions; projected mix under roadmap.
- Methodology appendix: scope rules, SaaS treatment, allocation methods, reconciliations.
How to interpret results:
- Rising Cloud % is healthy when paired with DC cost reduction (decommissioning) and improved agility/performance; concerning if cloud grows while on-prem remains flat (duplication/stranded cost).
- Stable or high On-prem % may be appropriate for latency/regulatory/mainframe workloads; reassess if modernization cases exist and DC leases allow exits.
- Cash vs P&L: expect timing differences—heavy CapEx years depress P&L Cloud % less until D&A rolls off; disclose to avoid false conclusions.
- Efficiency context matters: low commitment coverage, high idle cloud, or high egress share suggest optimization before further migration.
- Segment differences: customer-facing digital products often run higher Cloud %; plant/OT and regulated cores trend lower.
- Trend credibility increases when bridges show corresponding decommissions; lack of decommission evidence is a red flag.
Steps a company can take to improve on this measure:
- Strategy and portfolio:
- Define workload placement principles (cost, latency, data residency, service dependency); refresh target hosting models per application.
- Sequence migrations with explicit DC exit dates; fund decommissioning as part of business cases.
- Cost and efficiency levers:
- Cloud: increase commitment coverage, rightsize, schedule non-prod to zero, optimize storage tiers and egress, adopt serverless/managed services where TCO wins.
- On-prem: consolidate and retire legacy, increase virtualization density, rationalize storage tiers, reduce support scope with platform standardization.
- Decommission and stranded-cost reduction:
- Tie each migration to specific asset shutdowns (racks, circuits, arrays); renegotiate/exit DC leases and maintenance.
- Eliminate shadow/parallel run windows beyond defined stabilization periods.
- Commercial and architectural safeguards:
- Negotiate cloud enterprise discounts with flexibility (convertible commitments); manage egress via architecture (CDN, regional co-location).
- Adopt open standards and portability patterns to reduce lock-in and maintain leverage.
- Governance and data:
- Enforce tagging (app/env/owner) and TBM mapping; automate reconciliations; publish monthly FinOps KPIs.
- Require decommission evidence for release of migration benefits; track “double-run days.”
- Targeted actions by signal:
- If Cloud % rises without DC decline: launch a “turn off and take out” program focused on racks/circuits tied to migrated apps.
- If On-prem % high due to mainframe/storage: run a targeted modernization/business case (replatform/refactor vs retain) with risk and TCO.
- If cloud egress is high: redesign data flows (edge/CDN, same-region processing) and compress/partition data.
Benchmark comparisons:
General benchmarks:
- Infrastructure run spend Cloud % varies widely; many mid-to-large enterprises fall in the 20–50% range during transition, moving to 40–70% for digitally mature portfolios.
- Including SaaS materially increases “cloud” share; report both “infra-only” and “cloud+SaaS” lenses for comparability.
- Healthy transition signals: declining DC occupancy/OpEx within 6–12 months of major migrations; commitment coverage 60–80% on steady cloud workloads.
Segment- or industry-specific benchmarks:
- Digital-native/tech, media: 70–90%+ cloud (infra) with minimal on-prem footprint.
- Financial services/insurance: 20–50% and rising; regulatory/data residency shape pace and patterns.
- Manufacturing/industrial with OT: 10–30% cloud on infra; higher when plant systems modernize.
- Retail/eCommerce: 40–70% cloud, higher for customer-facing stacks.
- Public sector/healthcare: 15–40% cloud, constrained by regulation and funding cycles.
If external benchmarks are not directly comparable (scope/accounting differences), construct internal benchmarks: track Cloud % (cash and P&L) by BU/product over 8–12 quarters with consistent rules, set targets by archetype (digital product vs core operations), and monitor guardrails (commitment coverage, DC occupancy reduction, egress share) to ensure mix shifts represent genuine efficiency and capability gains—not accounting artifacts or duplication.
