FOCUS 1.2 Migration: What Breaks When You Move Off CUR

Every few years, the cloud cost world goes through a foundational shift. The AWS Cost and Usage Report became the de facto standard a decade ago, and an entire ecosystem of tools, dashboards, and pipelines grew on top of it. That ecosystem is now being asked to migrate. The FinOps Foundation's FOCUS specification has reached version 1.2, all three hyperscalers are publishing FOCUS exports, and AWS has signalled that CUR will eventually be deprecated for new use cases. The window to migrate cleanly is closing through Q2 2026.

We have been running FOCUS migrations for customers since the 1.0 release and we want to share what we have learned. This is not a marketing piece. It is the engineering brief we wish we had at the start. The migration is doable, but it has more sharp edges than the official documentation suggests, and the teams that move first will avoid a painful crunch later.

Why FOCUS 1.2 Matters and What It Changes

FOCUS exists to solve a real problem. Anyone who has tried to compare AWS, Azure, and GCP costs in a single dashboard knows that the three billing schemas barely speak the same language. Different column names. Different units. Different ways of representing discounts. Different concepts of resources. FOCUS standardises all of that into a single, vendor-neutral schema, so a query that works against AWS data also works against Azure and GCP data with no rewriting.

Version 1.2 of the spec, ratified in late 2025, tightened the parts of 1.0 and 1.1 that vendors had implemented inconsistently. It added formal definitions for amortised cost, capacity reservations, and shared discounts. It also clarified the handling of credits, refunds, and tax, which were ambiguous in earlier versions. The result is a spec that is finally robust enough to replace CUR for production workloads. That is also why the migration is no longer optional.

The Schema Differences That Actually Break Things

If you skim the FOCUS documentation, the differences from CUR look cosmetic. New column names, slightly different conventions, a few additional fields. The reality is more disruptive. Here are the changes we have seen break real pipelines.

Cost columns are reorganised, not renamed. CUR has lineItem/UnblendedCost, lineItem/BlendedCost, and lineItem/NetUnblendedCost. FOCUS has BilledCost, EffectiveCost, and ListCost. The mapping is not one-to-one. EffectiveCost includes amortised commitment discounts in a way that NetUnblendedCost does not, and dashboards that report monthly spend will produce different numbers depending on which column they use. We have seen migration cutover meetings derailed because the new dashboard showed a 4 percent variance from the old one and nobody could explain why for two days.

Resource identifiers change. CUR uses lineItem/ResourceId, which is usually an ARN. FOCUS uses ResourceId and ResourceName as separate columns, with ResourceId defined as the canonical provider-native identifier. For most AWS resources, this matches the CUR ARN, but for some (notably S3 buckets, IAM resources, and some networking constructs) it does not. Joins that worked against CUR will silently miss rows.

Discount amortization is different. CUR amortizes Reserved Instances and Savings Plans into specific line items per resource. FOCUS handles amortization through EffectiveCost and a separate CommitmentDiscountCategory column. The total is the same, but the per-resource attribution differs at the edges, and any dashboard that breaks down RI utilization by service will need to be rebuilt against the new schema.

Tax and credits are handled separately. In CUR, tax appears as its own line items, and credits appear as negative cost lines. FOCUS isolates tax in dedicated columns and treats credits as adjustments rather than negative costs. Reports that filter out negative line items as a sanity check will incorrectly drop credits in the new world.

Tags are still tags, but with a twist. Both schemas surface tags, but FOCUS uses a normalised Tags column with a JSON-encoded map rather than CUR's flattened resourceTags/user_* columns. Athena queries will need to be rewritten to extract specific tags, and any UI that auto-discovers tag columns will need to switch to JSON parsing.

The Migration Sequence We Recommend

After running this migration multiple times, we have settled on a sequence that keeps disruption manageable. We treat it as a parallel-run process rather than a cutover.

The first phase is dual-publishing. Enable the FOCUS 1.2 export alongside your existing CUR export. Both will run in parallel for the duration of the migration. The cost of running both is small, and having both available is the only way to validate the new pipeline without risk.

The second phase is schema mapping and validation. Build a translation layer that produces the same dashboard outputs from FOCUS data as your CUR pipeline does today. Compare the outputs side by side every day for at least one full billing cycle. Investigate every variance over 1 percent. Most variances trace back to one of the schema differences described above, and resolving them is straightforward once you know what to look for.

The third phase is dashboard migration. Once the FOCUS pipeline matches the CUR pipeline within tolerance, migrate dashboards one at a time. Start with the lowest-stakes reports and work up to the executive-facing ones. Keep both versions live during this phase so you can roll back if anything surprises you.

The fourth phase is decommission. Only once every consumer of the CUR data has been migrated and validated do you turn off the CUR export. We recommend keeping the historical CUR data archived in S3 Glacier or equivalent, because some long-running analyses will want it. This sequence typically takes a quarter for a mid-sized organisation. Larger organisations with extensive custom tooling often take two quarters. Our broader cloud cost data pipeline architecture guide details the supporting infrastructure each phase requires.

CUR vs FOCUS 1.2: What Changes for Your Team

The bottom line is that FOCUS 1.2 is a strictly better data foundation than CUR, but the migration is not free. Teams that pretend otherwise end up with broken dashboards in front of executives, which is the worst possible time to discover that EffectiveCost is not the same as NetUnblendedCost.

The Traps That Catch Everyone

A few traps are worth highlighting because they have caught almost every team we have worked with.

Reservation and Savings Plan attribution at the boundary. When an RI or SP applies to multiple linked accounts, FOCUS handles the attribution slightly differently than CUR. Spot-check the boundary cases.

Refunds that span billing periods. Refunds issued in month N for charges in month N-1 are placed differently in FOCUS than in CUR. Year-over-year comparisons can be off by a small but non-zero amount until you account for this.

Marketplace charges. Third-party software purchased through the AWS Marketplace appears in both schemas but with different metadata structure. Reports that filter out marketplace spend will need new filters.

Custom tags with special characters. CUR sanitises tag column names. FOCUS preserves them in the JSON map. Tags with hyphens, dots, or unicode characters may have been silently renamed in your old reports and now show up with their original keys. Worth a sweep before cutover. For teams new to FOCUS, our overview of the FOCUS specification provides the conceptual grounding before you dive into the migration mechanics. We also recommend reviewing our cloud cost allocation strategies guide and our companion piece on FinOps tooling stack reference architecture before designing the post-migration data flow. For the engineering side, our notes on cost-aware engineering culture explain how to keep teams engaged through a long migration.

Conclusion

The CUR-to-FOCUS migration is one of those rare changes that is genuinely worth doing well. The new schema is cleaner, the cross-cloud story is real, and the long-term reduction in custom tooling is significant. The migration is also more invasive than it looks, and the teams that treat it as a checkbox exercise will discover the sharp edges in production. We recommend starting now, running the migration in parallel, validating against your existing reports for a full billing cycle, and decommissioning CUR only when every downstream consumer has been verified. Done well, the migration takes a quarter. Done badly, it takes a year and produces three months of dashboard incidents along the way. The choice is yours, and the window is short.