Moving your data from v1

Only for existing v1 customers from before August 2026

This page is for organizations already running CloudMonitor v1 that are moving to v2. If you came to CloudMonitor after August 2026, or you’re installing it for the first time, none of this applies to you — there is nothing to move. Start with the setup instructions your onboarding contact sends.

You keep your cost history, your cost groups, your allocation rules and everything your team has written. This page covers how each of those moves and what you need to check.

Your cost history

Your history is rebuilt, not copied. We ask Azure for your cost data again and process it into v2, so the whole timeline comes from one engine rather than being stitched together at the changeover point.

We match the period your current system covers. If anything comes back shorter than that, we tell you which data and which months, during the trial rather than leaving you to find it later.

Why we ask Azure again instead of copying

Both versions read the same source: scheduled cost exports from Azure Cost Management, in the FOCUS format. FOCUS is the FinOps Foundation’s open standard for describing cloud spend, and Microsoft publishes it in versions.

v1 requested those exports as FOCUS 1.0. v2 requests them as FOCUS 1.2-preview. A newer version can’t be produced from an older export, because the older file simply doesn’t contain the columns — so copying your v1 files across would lock your history to the older shape forever. Asking Azure to regenerate the same months at 1.2-preview is what gives you one consistent timeline.

Microsoft’s FOCUS cost and usage details file schema lists every column in both versions side by side. The standard itself is at focus.finops.org.

What changes between the two versions

Both versions are generated from the same underlying billing records, so this is a change of shape, not of amount. Practically, 1.2-preview gives you:

• Finer service classification. A ServiceSubcategory column sits under the existing ServiceCategory, so a broad category splits into something you can actually group by.
• Clearer commitment and reservation handling. New columns separate the purchase of a commitment from the charges it covers, and mark reserved capacity that went unused.
• Standard names in place of Microsoft-specific ones. Fields v1 saw only under a vendor prefix — the invoice identifier, the pricing currency, the meter name — are promoted to standard columns. Anything still vendor-specific keeps its x_ prefix, so it’s obvious which is which.

Your totals should match

The four cost columns — BilledCost, EffectiveCost, ListCost and ContractedCost — carry the same definitions in 1.0 and 1.2-preview. Nothing about how a charge is valued changes between them.

You don’t have to take that on trust. Both platforms run at the same time during the trial, so your team can compare them month by month on figures you already know. Anything that doesn’t line up, we fix before you sign off.

Cost groups and allocation rules

Your cost groups come across as they are: name, code, cost centre, owners, members, budget, and whether they’re active or archived.

Your allocation rules are rebuilt in the new engine, which works differently from the one you use today. Rules are evaluated in order and the first match wins. A catch-all at the bottom sends anything unmatched to Unallocated, so every charge lands in exactly one group and your groups always add up to your bill.

Order carries meaning. A broad rule above a narrow one stops the narrow one firing, and nothing errors — the numbers just change. We’ll bring you a proposed rule list and order to review before it goes live.

A rule can also route by naming convention, reading a cost group code out of a resource name and sending the charge to whichever group carries that code. Where you have a naming scheme, several of your current rules often collapse into one.

To check the translation we run the rules across your whole history and compare spend per group per month against v1. The unallocated percentage is the scoreboard. It should be no higher than it is today.

For how the rules work once you’re using them, see The Cost Allocation report.

Comments and audit history

What your team has typed is the part that can’t be regenerated, so it moves as its own step: comments on cost groups, decisions to snooze or dismiss anomalies and recommendations with the reasons given, budget changes, and membership changes. Original author and date are kept.

Two things to decide with us:

• Entries in the Audit trail are permanent and cannot be edited or removed. Where someone has left, we archive them rather than delete them, so their entries stay attributable. Tell us if anyone’s records shouldn’t carry a name.
• Anomalies and recommendations are recalculated in v2, so they’re new records. We match your decisions back to them. Anything we can’t match confidently is kept as a note on the cost group rather than attached to the wrong thing.

Tell us whether your team actually uses snoozing and dismissals. It changes how much this step matters.

Users and access

We map your users across with their roles and cost group membership, then check each person can sign in before the trial opens. Send us the full list and mark who should be an administrator.

Access follows membership. An administrator sees everything; everyone else sees the cost groups they belong to, in the Audit trail as much as anywhere else. The list you send decides who can read what — see Roles and access.

Your data sits in a workspace of your own, hosted by us rather than in your own Azure environment. The only piece that stays with you is the storage account your cost exports land in. Your security team can start with Security and data isolation, and we’ll answer anything that page doesn’t.

Alerts

Budget and anomaly alerts can go to Teams, Slack, email or a webhook. You don’t have this in v1, so there’s nothing to carry over and we set it up with you during configuration.

How the move runs

1. Discovery — we inventory your cost groups, rules, budgets, users and settings, and confirm the history you hold today.
2. Access — you grant the consent and roles from the setup instructions. We run a health check and send you the result.
3. Provisioning — your workspace is built and your users mapped in.
4. History — we request your historical data from Azure and process it.
5. Configuration — cost groups, rules, budgets and alerts rebuilt.
6. Comments and audit history — a sample for you to check, then the full load.
7. Trial — both platforms live, your team compares them.
8. Sign-off — anything raised during the trial resolved and re-checked.
9. Changeover — your v1 exports stop and the old application is removed, on a date you set.

What we need from you

The Azure consent and roles are set out in the setup instructions your onboarding contact sends, so they aren’t repeated here. Alongside those, we need:

• A migration owner.
• The user list, with administrators marked.

Nothing switches off until you say so

v1 keeps running exactly as it does now, right through the trial. If the comparison doesn’t satisfy you, you stay on v1 while we sort it out. The only step that can’t be undone is the last one, and it happens on a date you set, after you’ve signed off.

Next steps

Once you’ve installed v2, contact us and we’ll start the move.

Checking it works takes about three to four business days, which is where we confirm your history, cost groups and allocation rules have come through the way they should. After that we run v1 and v2 side by side so your team can compare them.