Kubecost is a cost visibility tool: it allocates Kubernetes spend to namespaces, labels and teams and shows where the money goes. It does not change what the cluster provisions. Teams migrate when reporting has done its job and the number has not moved – when everyone can see that requests are far above usage and nothing acts on it. The migration is less a replacement than a change of category: keep the label taxonomy and the allocation model you built, and add a layer that acts on what the reporting has been showing.
Key takeaways #
- Your Kubernetes label taxonomy carries over intact. Those labels live in your manifests, not in Kubecost.
- Historical cost data does not transfer automatically. Export 90 days before decommissioning.
- Cast AI runs read-only by default. Running both systems in parallel for 30-90 days is safe and recommended.
- Technical setup takes 2-4 weeks. Validation before decommissioning takes 30-90 days.
- Kubecost reports provisioning problems. Automation tools fix them. The migration moves you from the first to the second.
Kubecost gives you a precise map of where your Kubernetes spend is going. It does not move anything on the map. If your clusters are running at 8% average CPU utilization with 69% CPU overprovisioned, reading that dashboard is not the same as fixing the underlying problem. This guide covers the kubecost migration process: what to keep from your current setup, how to handle historical cost data, and how to move to automated optimization without losing the allocation model your team built.
What Kubecost does well #
Kubecost excels at a specific job: allocating Kubernetes cost to the teams, namespaces, and workloads responsible for it. Built on OpenCost, a CNCF incubating project, it integrates Kubernetes resource data with cloud billing APIs to produce chargeback and showback reports. If your engineering organization needs to answer “which team spent the most on compute this month,” Kubecost answers that question accurately.
In September 2024, IBM acquired Kubecost through Apptio, adding it to the IBM Turbonomic product suite. Development has continued on both Kubecost 3.0, released in September 2025, and the OpenCost open-source project. Kubecost 3.0 added GPU cost tracking, made Prometheus optional, and improved CSV export capabilities. For teams inside IBM’s enterprise toolchain, this integration matters for consolidated financial reporting across multiple clusters.
The allocation engine is genuinely strong. It supports cost allocation by namespace, pod, deployment, label, and annotation. Both requests-based and usage-based cost models are available. If your team has invested in labeling discipline, adding team=, env=, product=, and cost-center= labels consistently across workloads, Kubecost surfaces that investment clearly in its reports.
For setup details and architecture context, see the guide on Kubecost Kubernetes configuration.
Why teams move on: visibility without action #
Teams move on from Kubecost when they recognize that identifying a cost problem and resolving it are two separate operations, and their current tooling only handles the first. According to the Cast AI 2026 State of Kubernetes Optimization Report, covering 23,000+ clusters, average CPU utilization sits at 8%, with 69% of provisioned CPU overprovisioned across those workloads.
That 69% figure is worth examining carefully. Cast AI cluster data from the prior year put the overprovisioning rate at 40%. Tool adoption increased over that period. Yet overprovisioning got worse, not better. The monitoring was there. The gap widened anyway.
The structural reason is clear. Kubecost reports what resources are allocated and what they cost. It does not change what the cluster provisions. Rightsizing recommendations exist inside Kubecost, but they output suggestions for engineers to act on manually. Someone still opens a PR to update resource requests. Someone else reviews and merges it. Then a third person validates that the change did not cause OOMKills in production. At any meaningful scale, this workflow does not keep pace with the rate at which new workloads get deployed and resource patterns shift.
A cluster running at 8% utilization with 69% overprovisioning is not a measurement problem. It is a provisioning problem that measurement alone cannot close. Visibility was always step one.
What to keep from your Kubecost setup (labels, allocation model, cost centres) #
The most important thing to keep from your Kubecost setup is your label taxonomy, and it is also the thing most teams initially misunderstand: those labels are Kubernetes labels, not Kubecost labels. They live in your deployment manifests, Helm values, and CI/CD pipelines. Kubecost reads them. It does not own them. When you decommission Kubecost, those labels remain in your cluster exactly as they were.
Here is a breakdown of what carries over and what requires active rebuild:
| Element | Keep? | Action required |
|---|---|---|
| Kubernetes labels (team=, env=, cost-center=) | Yes | None. Labels already exist in the cluster. |
| Allocation model logic (requests vs usage-based) | Yes | Recreate the same model in Cast AI Allocation Groups. |
| Cost center structure | Yes | Recreate as Allocation Groups using the same label selectors. |
| Budget threshold values | Yes | Translate to Cast AI anomaly alert rules. |
| Showback cadence and recipients | Yes | Rebuild as scheduled Cast AI reports. |
| Prometheus metric history | No | Export to CSV before decommissioning Kubecost. |
| Kubecost-specific dashboard configs | No | Rebuild using Cast AI reporting and Allocation Groups. |
| Drill-down time-series workload history | No | Does not transfer. Export what you need before shutdown. |
For a deeper look at building a Kubernetes cost allocation model, see Kubernetes cost allocation.
These org assets are independent of any vendor: keeping them in manifests and documentation rather than locked inside tool configs means your cost model survives any tooling change intact.
The allocation model decision, requests-based versus usage-based, is worth revisiting during migration. Both Cast AI and Kubecost support both models. Requests-based allocation is more predictable for showback because it reflects what was scheduled, not what was consumed. Usage-based allocation better reflects actual compute consumed. Document your current choice explicitly before starting the migration, so you recreate it intentionally rather than by accident.
What to migrate: reporting, alerts, dashboards #
The practical migration work involves recreating your reporting infrastructure inside Cast AI. Three categories need direct attention.
Dashboards and Allocation Groups
Cast AI provides namespace, label, and team-based Allocation Groups with a 60-second data refresh. Map each Kubecost cost center view to a corresponding Allocation Group definition before you begin decommissioning. The label selectors you used in Kubecost translate directly. For API reference and console setup guidance, see the Cast AI cost management documentation.
Alert thresholds
Kubecost budget alerts translate to Cast AI anomaly detection rules. Pull your current Kubecost threshold values and configure equivalent rules in Cast AI before disabling Kubecost alerting. To create rules, navigate to Settings → Alerts → Anomaly Detection in the Cast AI console, or configure rules via the Cast AI API. Running both alert systems in parallel during the transition prevents gaps in coverage. A spike that fires in Kubecost should also fire in Cast AI. Verify this with a test before decommissioning.
Scheduled reports
If your finance or FinOps team receives weekly or monthly Kubecost exports, rebuild those schedules in Cast AI before switching off Kubecost. Cast AI supports showback and chargeback exports with custom schedules and recipient lists. One significant difference to flag: Cast AI cost data starts from the day you connect your cluster. There is no backfill from Kubecost records. For reports requiring historical continuity, plan a period where both systems contribute data to the same reporting view.
Historical data: what transfers and what does not #
Historical Kubecost data does not transfer to Cast AI. Cast AI starts fresh from the cluster connection date and does not ingest Kubecost’s historical records. This is the most operationally significant constraint to plan around before you start.
Kubecost stores cost data in Prometheus metrics. Kubecost’s default configuration uses Prometheus with 15-day retention, which is Prometheus’s own default rather than a Kubecost-imposed limit. You can extend retention by configuring Prometheus directly, but Kubecost’s UI may not surface older data beyond its own query window. Business and Enterprise deployments may extend retention further through Thanos or Cortex, but the data stays in your Prometheus infrastructure regardless of tier. Cast AI never touches it.
Before decommissioning, take the following steps:
- Export 90 days of allocation data using a full curl command against the Kubecost Allocation API:
curl \
"http://<KUBECOST_HOST>/model/allocation?window=90d&aggregate=namespace&accumulate=true" \
> kubecost-90d-export.json
Store the output somewhere your FinOps and finance teams can access for at least 12 months.
- If you run Thanos or Cortex, preserve the Prometheus snapshot separately. This gives you queryable historical data if an audit requires it later.
- Document your label structure and cost model settings in writing. These belong to your organization, not to any specific tool.
One financial governance consideration: Cast AI starts with no historical data. This means you will have a data gap in year-over-year cost center comparisons for the next fiscal cycle. Before decommissioning Kubecost, inform your finance stakeholders about the migration date as an accounting event, and use your 90-day export as the reference baseline for any annual trend comparisons. This gap is temporary and manageable, but it needs to be communicated proactively.
For context on the OpenCost foundation underlying Kubecost and what that means architecturally, see OpenCost vs Kubecost.
Plan for roughly one quarter before Cast AI accumulates enough history for meaningful trend analysis. After 90 days, you will have a clean baseline tied to the period after automation was enabled, which is often more useful than historical data from a purely reporting-based setup.
Running both during transition #
Running Kubecost and Cast AI simultaneously is safe and practical. The Cast AI agent is read-only by default: it collects cluster data and surfaces rightsizing recommendations but does not change anything in your cluster until you explicitly enable automation features. There is no conflict between the two agents. For chargeback and showback invoices during the parallel period, Kubecost remains the authoritative system until you complete the explicit sign-off step at the end of Phase 4.
A 30-90 day parallel operation period is the recommended approach. During that window:
- Use Kubecost for historical reporting and any reports that require pre-migration data continuity.
- Use Cast AI for current-period cost allocation and to start building confidence in rightsizing recommendations.
- Validate that Cast AI Allocation Groups match your Kubecost cost center breakdown before enabling any automation.
The validation step is critical. Run both systems side by side for at least two full billing cycles. Compare namespace-level cost allocation between Kubecost and Cast AI for the same period. Divergence above 5% typically points to label coverage gaps. Missing labels on certain workloads mean those workloads fall into an unallocated bucket in Cast AI but were previously caught by Kubecost’s namespace fallback allocation.
Fix label coverage gaps in your deployment manifests or Helm values and propagate those changes through your CI/CD pipeline. Once the allocation views match across two billing cycles and you have enabled rightsizing automation, decommissioning Kubecost becomes a straightforward, evidence-backed decision.
Step-by-step migration #
A complete kubecost migration guide spans 2-4 weeks of technical setup followed by a 30-90 day validation period. Below is the full sequence.
Phase 1: Audit and prepare (Week 1)
- Audit your Kubernetes label coverage. Run the following to see which workloads carry your cost attribution labels:
kubectl get pods --all-namespaces -o json \
| jq '[.items[] | {name: .metadata.name, ns: .metadata.namespace, labels: .metadata.labels}]'
Document which namespaces or deployments are missing team=, env=, or cost-center= labels. Missing labels produce allocation gaps after the switch.
- Document your Kubecost allocation model settings. Note whether you use requests-based or usage-based cost allocation. Record your cost center definitions, label selectors, and showback cadence. If your FinOps team relies on specific aggregation logic, capture it now.
- Export historical cost data. Run the full curl command against the Kubecost Allocation API:
curl \
"http://<KUBECOST_HOST>/model/allocation?window=90d&aggregate=namespace&accumulate=true" \
> kubecost-90d-export.json
Alternatively, use Kubecost’s scheduled report export feature in the UI. Store the output in a location accessible to both finance and FinOps for at least 12 months.
- List all active Kubecost alerts and their threshold values. Pull budget alert configurations from the Kubecost UI or API. You will recreate these as Cast AI anomaly detection rules in Phase 2.
Phase 2: Install and configure Cast AI (Weeks 2-4)
- Deploy the Cast AI agent in read-only mode. Add the Helm repository and install the agent with a single command:
helm repo add castai-helm https://castai.github.io/helm-charts && \
helm install castai-agent castai-helm/castai-agent \
-n castai-agent --create-namespace \
--set provider=gke
Replace gke with eks for Amazon EKS or aks for Azure AKS. Full provider-specific instructions are at Cast AI Kubernetes cost monitoring. Installation typically takes under 30 minutes for a single cluster.
- Create Allocation Groups in Cast AI. Recreate your Kubecost cost center structure using Cast AI’s Allocation Groups feature. Use the same label selectors your Kubecost allocation model used. If Kubecost grouped by
team=platformandenv=production, your Allocation Group uses the same label filters. See theCast AI cost management documentation for API and console configuration details. - Configure the allocation cost model. Set requests-based or usage-based cost allocation in Cast AI to match your Kubecost setting. This ensures the two systems produce comparable numbers during the parallel validation period.
- Recreate budget alert thresholds. Set up Cast AI anomaly detection rules using the threshold values you documented in step 4. Navigate to Settings → Alerts → Anomaly Detection in the Cast AI console, or configure rules via the Cast AI API. Run both Cast AI and Kubecost alerting simultaneously until validation is complete.
- Rebuild scheduled cost reports. Configure Cast AI scheduled exports for any recurring reports your finance or FinOps team depends on. Get confirmation from report recipients that the Cast AI output meets their format requirements before proceeding.
Phase 3: Weeks 3–12: Validate and automate
This phase is less mechanical than Phase 2. The goal is evidence, not velocity. Run both systems and compare namespace-level allocation output for the same time period. Divergence above 5% between Cast AI Allocation Group results and Kubecost cost center reports needs investigation before you proceed.
When discrepancies appear, the usual cause is label coverage rather than a model mismatch. Check label propagation in your deployment manifests, apply missing labels, push through CI/CD, and re-run the comparison. Two consecutive billing cycles with matching output give you the confidence to move forward.
Once allocation matches, pull up the Cast AI rightsizing recommendations. At 8% average CPU utilization with 69% overprovisioning, the initial suggestions will be significant. Start with non-production workloads to build confidence before touching production.
Cast AI needs 7-14 days of telemetry before recommendations stabilize. Enabling automation during the first week of installation means acting on recommendations derived from incomplete data. For most clusters, wait at least one full week — two for workloads with weekly traffic cycles — before enabling autonomous rightsizing.
Enable rightsizing automation incrementally for a scoped subset of non-production workloads and monitor OOMKill rates and pod restart counts for two weeks. If you observe rising OOMKill rates or CPU throttling after enabling automation, disable autonomous mode via the Cast AI console (Settings > Optimization Policies > automation) and review the recommendations before re-enabling. A stable non-production outcome gives you the evidence base to expand to production.
Phase 4: Enable full automation and decommission Kubecost (Day 60-90)
- Expand rightsizing automation to production workloads. Set guardrails: minimum and maximum resource bounds per workload, disruption budgets for critical services, and exclusion lists for any stateful workloads that require manual review.
- Enable bin-packing and node consolidation. If your cluster carries significant idle node capacity, node consolidation reduces the base infrastructure cost beyond what rightsizing alone achieves. Navigate to Optimization → Node Consolidation in the Cast AI console and enable it for eligible node groups.
- Confirm Cast AI reporting meets FinOps requirements. Get explicit sign-off from your finance and FinOps team before decommissioning Kubecost. They are the primary stakeholders for reporting continuity.
- Decommission Kubecost. Remove the Kubecost Helm release from your cluster:
helm uninstall kubecost -n kubecost
Retain your Prometheus data snapshot and JSON exports per your organization’s data retention policy. Kubecost namespace and associated PVCs can be deleted once you confirm the exports are stored securely.
What changes operationally after the switch #
After completing the kubecost migration, the most significant operational change is the shift from scheduled reporting to continuous automated action. The old workflow looked like this: Kubecost surfaces a rightsizing recommendation, an engineer opens a PR to update resource requests, the team reviews and merges, and then someone validates that the change did not cause instability in production. This cycle repeated for every workload, every time utilization patterns shifted.
After the switch, Cast AI handles that cycle automatically. Resource requests adjust continuously based on actual utilization. Node consolidation runs when cluster capacity allows it. Your team still controls the guardrails: minimum and maximum resource bounds, disruption budgets, and which workloads are eligible for automation. The execution is no longer manual.
One area that requires coordination before you enable automation: compute commitments. If your cluster is covered by Reserved Instances or Savings Plans, talk to your FinOps team before turning on autonomous rightsizing. A significant CPU reduction changes your commitment utilization rate and may require reservation adjustments to avoid paying for reserved capacity you no longer need. As a practical threshold from Cast AI fleet data: if Reserved Instance or Savings Plan coverage exceeds 60% of your current node costs, model the commitment impact before enabling rightsizing automation. If coverage is below that threshold, enable rightsizing first and adjust commitments at your next renewal window.
Three specific operational changes stand out after teams complete this migration:
- OOMKill events drop sharply. In clusters with 50+ deployments running static resource requests, teams typically see 40-50 OOMKill events per week, tracked over 30 days. Automated rightsizing sets memory limits based on actual usage patterns rather than engineering estimates from deployment time. Post-migration OOMKill rates drop sharply.
- Manual resource request PRs disappear from engineering workflows. At scale, these PRs represent several hours of engineering time per week. That time returns to feature work.
- Node compute costs decrease, not just reporting accuracy. In comparable clusters running stateless workloads with static resource requests, Cast AI’s automated rightsizing has reduced Kubernetes node compute costs by approximately 50% (Cast AI 2026 State of Kubernetes Optimization Report). Results vary based on workload type, existing request calibration, and the degree of overprovisioning in your baseline.
The business case for the migration is straightforward: the effort typically involves 2-3 weeks of platform engineering time, and teams that see ~50% compute reduction on $100K/month clusters recover that investment within the first month.
The monitoring posture also changes. On a typical Tuesday after the migration, you check cost per namespace in the Cast AI console rather than pulling a weekly Kubecost report. Anomaly alerts surface unexpected spend spikes in real time, replacing the weekly dashboard review meeting. You shift from periodic inspection to event-driven response.
For a detailed comparison of functional differences before committing to the migration, Cast AI vs Kubecost covers the tooling distinction in depth.
Conclusion #
The kubecost migration is not primarily a tool replacement exercise. It is a transition from a reporting workflow to an execution workflow. Kubecost solved the attribution problem: it proved which teams owned which spend and gave FinOps teams something concrete to act on. That was genuinely useful work.
After the transition, your team’s Kubernetes cost model becomes a live control surface rather than a historical ledger. The label discipline and cost center structure Kubecost made visible now drives automated decisions instead of manual tickets.
The technical setup is straightforward. The organizational shift, from reviewing dashboards weekly to trusting continuous automation, takes slightly longer. Start with the label audit. Export your history. Run both systems in parallel long enough to validate the allocation match. Then enable automation incrementally. The goal is not to discard what Kubecost built. The goal is to make that investment produce results on the infrastructure bill.
For additional context on the broader cost management tooling landscape, see Kubecost options for Kubernetes cost management.
Frequently Asked Questions #
How do I migrate from Kubecost?
Export 90 days of Kubecost allocation data before you touch anything else — you cannot recover that history later. Then install Cast AI in read-only mode alongside Kubecost, rebuild your Allocation Groups using the same label selectors, and run both systems for 30-90 days until namespace-level allocation numbers match within 5%. Enable automation incrementally on non-production workloads first, get FinOps sign-off, then decommission. Technical setup runs 2-4 weeks; validation takes another 30-90 days depending on your label coverage and workload complexity.
Is Kubecost being replaced by OpenCost?
They are related but not the same thing. OpenCost is the open-source cost allocation layer; Kubecost is a commercial product built on top of it, adding multi-cluster UI, alerts, and integrations. In September 2024, IBM acquired Kubecost through Apptio, folding it into the IBM Turbonomic product suite. OpenCost continues as an independent CNCF incubating project. Neither is replacing the other, they serve different audiences with different requirements.
Can I keep my Kubecost historical data?
You can preserve Kubecost historical data by exporting it before decommissioning, but it will not transfer into Cast AI automatically. Use the Kubecost Allocation API with a full curl command to export 90 days of cost data to JSON before you shut down the tool. If you run Thanos or Cortex, you can also preserve the Prometheus time-series snapshot for queryable historical data. Cast AI starts recording cost data from the cluster connection date and provides unlimited retention going forward.
What is the difference between Kubecost and Cast AI?
Kubecost is a cost visibility and allocation tool: it reports where Kubernetes spend is going and surfaces rightsizing recommendations for engineers to implement manually. Cast AI is an automated optimization platform: it continuously adjusts resource requests, consolidates nodes, and reduces cluster costs without manual intervention. The two tools solve adjacent problems. Kubecost answers “where is the money going?” Cast AI changes what the cluster provisions. For a detailed feature comparison, see the Cast AI vs Kubecost breakdown.
Do I need both cost visibility and automation?
Cast AI includes built-in cost allocation through Allocation Groups, so you do not need a separate visibility tool alongside it. Allocation Groups provide namespace, label, and team-based cost breakdowns with a 60-second refresh, forecasting, anomaly detection, and showback reports. During the migration transition period, running both tools in parallel is useful for validating allocation accuracy. After validation, Cast AI covers both the visibility and optimization functions.
How long does a Kubecost migration take?
A Kubecost migration typically takes 6-14 weeks end to end. Technical setup, including installing Cast AI, recreating Allocation Groups, and configuring alerts and reports, takes 2-4 weeks. The parallel validation period, where both systems run simultaneously and allocation accuracy is confirmed, takes an additional 30-90 days before Kubecost can be safely decommissioned. Teams with thorough label coverage and a clear cost center structure move through validation faster than those with gaps in label propagation.