Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Cloud TCO calculator

Calculates a full total cost of ownership comparison between on-premises infrastructure and cloud, covering compute, storage, networking, licensing, labor, facilities, and migration costs, with 3-year and 5-year…

download .md

Purpose

Produce a defensible, line-item TCO comparison between running workloads on existing on-premises infrastructure and migrating to cloud — capturing the hidden costs both models tend to obscure (labor, facilities, refresh cycles, migration, egress) — so finance and infrastructure leaders can make and justify a multi-year decision. Delivers 3-year and 5-year totals with low/base/high sensitivity ranges rather than a single misleading number.

When to Use

Invoke this skill when the user asks to:

  • Build a cloud migration business case or cost justification
  • Compare the cost of staying on-prem versus moving to AWS, Azure, or GCP
  • Calculate total cost of ownership for infrastructure over 3 or 5 years
  • Justify an infrastructure decision to a CFO, board, or finance team
  • Evaluate whether a hardware refresh is worth it versus migrating
  • Model the break-even point of a cloud transition

Inputs Required

Before starting, collect:

  • On-prem compute inventory: Server count, CPU cores, RAM, and approximate utilization (e.g., 40 servers, 640 cores, avg 25% utilization)
  • Storage footprint: Total capacity in TB, storage type (SAN/NAS/local), and annual growth rate
  • Workload profile: Steady-state vs. bursty, dev/test vs. production, uptime requirement, data egress volume per month
  • Software licensing: Key licenses (OS, database, virtualization, middleware) and current annual cost or licensing model (per-core, per-socket, subscription)
  • Labor and staffing: FTE count supporting infrastructure and fully loaded annual cost per FTE
  • Facilities and hardware costs: Data center/colocation spend, power/cooling, and hardware refresh cycle (typically 4–5 years) with replacement cost
  • Target cloud provider and region: AWS/Azure/GCP and primary region, plus any committed-use discount appetite (on-demand, 1yr, 3yr reserved/savings plan)

If cloud provider, utilization, or growth rate are unknown, use these defaults and state them: AWS us-east-1, 30% on-prem utilization, 15% annual storage growth, 5-year hardware refresh, 3-year reserved instance pricing for steady-state workloads.

Instructions

Step 1: Establish the On-Prem Baseline (Annual Run Rate)

Calculate the fully loaded annual cost of the current environment across seven cost categories:

  • Hardware/amortization: Total hardware acquisition cost ÷ refresh cycle years. Include servers, storage arrays, and networking gear. If mid-cycle, note the impending refresh event.
  • Facilities: Colocation or data center space, plus power and cooling. Estimate at $150–$400/kW/month if not provided, sized to rack/power draw.
  • Software licensing: Annualized cost of OS, hypervisor, database, and middleware. Flag per-core licenses that inflate with cloud vCPU counts.
  • Labor: FTE count × fully loaded cost, allocated to the portion of infrastructure being modeled. Default to 40% of a senior sysadmin's time per ~20 physical servers if not provided.
  • Networking/bandwidth: ISP/transit, load balancers, firewalls.
  • Backup/DR: Secondary site, backup storage, DR software and testing.
  • Maintenance/support: Vendor support contracts, warranties, spare parts.

Sum to an on-prem annual run rate. Note any one-time refresh CapEx events that fall inside the 3- and 5-year windows.

Step 2: Right-Size the Cloud Equivalent

Do not lift-and-shift core-for-core. Adjust for cloud realities:

  • Compute mapping: Map on-prem cores to cloud instance families accounting for utilization. Over-provisioned on-prem (25–30% utilization) typically maps to 40–60% fewer cloud vCPUs when right-sized.
  • Commitment model: Apply reserved instance / savings plan discounts (typically 30–55% off on-demand for 1–3yr commitments) to steady-state workloads; keep bursty/dev-test on on-demand or spot.
  • Storage tiering: Map to hot/cool/archive tiers. Do not price all storage at premium SSD rates.
  • Managed services offset: Note where cloud managed databases or services reduce labor and licensing (e.g., managed DB removes DBA hours and some licensing).

Step 3: Build the Cloud Annual Run Rate

Calculate cloud recurring cost across categories:

  • Compute: Right-sized instances × commitment pricing × hours/year
  • Storage: Tiered capacity × per-GB rates, grown by annual growth rate
  • Networking/egress: Data egress volume × egress rates (this is frequently underestimated — call it out explicitly)
  • Licensing (cloud): BYOL vs. license-included; flag per-core licensing that scales with vCPU
  • Cloud labor: Reduced but not eliminated — estimate 60–75% of on-prem FTE hours for equivalent operations, plus any new FinOps/cloud engineering
  • Support plan: Provider support tier (e.g., Business/Enterprise support at 3–10% of spend)

Step 4: Model One-Time Migration Costs

Migration is a cost the on-prem case does not carry — include it in Year 0/Year 1:

  • Assessment and planning: Discovery, dependency mapping, architecture
  • Migration labor: Internal FTE time + external SI/partner fees, sized by workload count and complexity (rehost < replatform < refactor)
  • Dual-running overlap: Period where both environments run simultaneously (typically 2–6 months)
  • Data transfer: Ingress is usually free; account for physical transfer appliances for large datasets
  • Training and tooling: Team upskilling, new monitoring/FinOps tooling

Step 5: Assemble 3-Year and 5-Year TCO

Build a side-by-side table. On-prem cumulative = (annual run rate × years) + any refresh CapEx event inside the window. Cloud cumulative = (annual run rate × years) + one-time migration costs. Calculate:

  • 3-year total, on-prem vs. cloud, with dollar and % delta
  • 5-year total, on-prem vs. cloud, with dollar and % delta
  • Break-even point: The month/year at which cumulative cloud cost crosses below cumulative on-prem cost (or note if it never does within 5 years)

Step 6: Apply Sensitivity Ranges

Produce low / base / high scenarios by flexing the three variables that move the result most:

  • Cloud utilization/right-sizing efficiency (±20%)
  • Committed-use discount realization (assume full commitment vs. partial adoption)
  • Storage/egress growth rate (base growth vs. accelerated)

Present each scenario's 5-year cloud total so the reader sees the realistic band, not a false-precision single figure.

Step 7: Recommendation and Caveats

State a clear recommendation grounded in the numbers. Note the top 3 assumptions that, if wrong, would change the conclusion, and what to validate before committing budget.

Output Format

  • Structure: Narrative summary → on-prem baseline table → cloud run-rate table → migration cost table → 3yr/5yr comparison table → sensitivity scenario table → recommendation
  • Length: 900–1,300 words plus tables
  • Format: Structured document with markdown tables for all cost breakdowns; prose for diagnosis and recommendation
  • Sections: Executive Summary → On-Prem Baseline → Cloud Run Rate → Migration Costs → 3-Year & 5-Year TCO → Sensitivity Analysis (Low/Base/High) → Break-Even → Recommendation & Assumptions to Validate
  • Tone: FinOps analyst reporting to a CFO — precise, numeric, no hype; every figure traceable to an input or a stated assumption

Quality Checklist

Before delivering output, verify:

  • [ ] All seven on-prem cost categories are itemized (hardware, facilities, licensing, labor, networking, backup/DR, maintenance)
  • [ ] Cloud compute is right-sized against utilization — not a 1:1 core-for-core lift with no reduction
  • [ ] Migration one-time costs appear in the cloud case but not the on-prem case
  • [ ] Any hardware refresh CapEx event inside the 3yr/5yr window is included in the on-prem total
  • [ ] Egress costs are explicitly line-itemed, not folded silently into networking
  • [ ] Sensitivity table shows distinct low/base/high 5-year totals, not one number ± a percentage
  • [ ] Every assumption used in place of a missing input is stated explicitly

Notes

  • The two costs most often understated are on-prem labor/facilities (making cloud look worse) and cloud egress/right-sizing failure (making cloud look better) — model both honestly or the comparison is worthless.
  • Cloud rarely wins on pure infrastructure cost for steady, predictable, high-utilization workloads; it wins on elasticity, avoided refresh CapEx, labor reduction, and opportunity cost. Make sure the recommendation reflects which of these actually apply.
  • If the on-prem environment faces an imminent hardware refresh, that CapEx event is often the single largest swing factor — surface it prominently.
  • Encourage the user to validate compute right-sizing with 2–4 weeks of actual utilization telemetry before committing budget, since it is the highest-variance input in the model.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills