A marketplace metering migration is moving the software that reports usage to a cloud marketplace — not moving the usage records themselves, which are the marketplace’s to keep. The risk is entirely in the seam between the old reporter and the new one: an hour reported twice double-bills a buyer, and an hour reported by neither under-bills you. The whole job is to run both reporters in parallel across one reconciliation window so that seam never opens.
Every part of a billing-platform switch is reversible except one, and usage-based sellers know exactly which one it is. You can re-point a CRM sync, re-create a workflow and re-issue an API key on a Tuesday and undo all of it on Wednesday. But the moment a metering record reaches AWS or Microsoft, it becomes an invoice line a buyer will pay — and there is no “undo” on a number you already sent. That is why teams on consumption pricing stall on migrations that seat- and contract-based sellers wave through.
The fear is rational but the scope is smaller than it feels. The records you have already reported are not in play; they sit with the cloud provider, done. What you are actually moving is a single code path — where your product posts new usage — and the entire art of doing it safely is sequencing that handoff so no hour of usage is claimed twice or claimed by nobody. This is the cutover plan for exactly that.
It is the metering-specific companion to what moves when you switch marketplace platforms, which sorts every migration artifact into “stays with the provider” or “moves with you.” Metering lives in both columns at once — the reported records stay, the reporter moves — which is why it earns its own post and its own place at the very end of the cutover.
What actually breaks during a marketplace metering migration?
Nothing in the marketplace’s ledger breaks — only the reporting seam can. The usage records you already submitted are the marketplace’s records, kept by AWS, Microsoft or Google Cloud and already turned into invoice data. A migration cannot reach back and corrupt them. The only thing at risk is the boundary in time where the old reporter stops and the new one starts.
Two failure modes sit in that seam, and they are mirror images:
- Double-reporting. Both the old system and the new one report the same hour of usage to the same marketplace. Depending on the provider’s de-duplication, you either get a hard rejection or a doubled quantity — and a doubled quantity is a buyer overcharge.
- Gap-reporting. The old system stopped and the new one had not started, so an hour of real usage was reported by neither. Nobody rejects anything; the meter is simply light, and you under-bill silently.
Both are invisible until an invoice lands. Neither shows up in a staging environment, because the thing you are testing is a handoff between two live systems against a live marketplace endpoint. So the defense is not more testing — it is a cutover shape that makes both modes structurally impossible, which is what the rest of this post builds.
Why the providers’ own rules make parallel reporting safe
Both AWS and Microsoft de-duplicate usage per dimension per hour, so reporting the same hour from two systems does not silently double a bill — it collides in a way you can detect. This is the fact that makes a parallel cutover safe rather than reckless, and it comes straight from each provider’s metering API.
On AWS Marketplace, SaaS usage is reported with BatchMeterUsage, and AWS states that “identical requests are idempotent and can be retried with the same records or a subset of records.” Usage is metered against a named dimension defined when you published the product — send a dimension that does not match and AWS returns InvalidUsageDimensionException rather than inventing a charge. A batch carries up to 25 usage records, and records “aren’t accepted 24 hours or more after an event.”
On Microsoft Marketplace, the usage-event API is blunter still: “Only one usage event can be emitted for each hour of a calendar day per resource and dimension.” Send a second event for the same resource, date and hour and Microsoft returns 409 Conflict with a status of Duplicate — it does not add a second charge. Events can only be dated to the past 24 hours; older ones expire.
The practical reading for a migration is this: if both your systems report the same hour, the provider’s per-hour, per-dimension uniqueness catches the collision instead of billing it twice. That turns “run both at once” from a dangerous idea into a verification technique — you can watch the two systems agree before you trust either one alone. What you must never do is have the two systems report different quantities for the same hour and dimension, which is the one case that resolves to an argument rather than a clean duplicate.
The reconciliation window is a real deadline, not a vibe
“Reconciliation window” is not a soft phrase here — each provider gives you a concrete, dated cutoff after which a billing period’s usage can no longer be corrected, and your migration has to finish inside it. This is the single hardest constraint on when you cut over, and it is easy to miss because it only bites at a month boundary.
AWS is explicit: after the 24-hour per-event limit, “at the end of each billing cycle, a 6-hour grace period applies. We accept usage records for the previous billing month until 06:00 UTC on the first day of the next month” — after which you get a TimestampOutOfBoundsException. So March usage must reach AWS before 06:00 UTC on April 1, full stop. Microsoft gives you the retrieval side of the same idea: pull your usage events back and each carries a reconStatus — Submitted, Accepted, Rejected, or Mismatch — which is precisely the signal you reconcile your own totals against before the period closes.
The consequence for scheduling is concrete. Do not cut over metering across a billing-period boundary. Run the parallel window entirely inside a single billing cycle, well clear of the month-end grace cutoff, so that if a discrepancy appears you still have room to resubmit a corrected record before the marketplace freezes the period. A cutover timed for the last day of the month has no margin left for the one thing a cutover exists to catch.
What to preserve during a metering migration
Before any code moves, inventory the things that must survive the switch byte-for-byte. Get any row in this table wrong and the new reporter posts technically valid usage that bills the wrong buyer, the wrong dimension, or the wrong amount — the worst kind of error, because nothing rejects it.
| What to preserve | Where it lives | Why it must not drift |
|---|---|---|
| Usage dimensions | Defined on the marketplace offer at publish (AWS UsageDimension, Azure custom dimension) | The new reporter must send the exact dimension names the offer was published with. AWS rejects an unknown dimension; a merely mislabeled one bills the wrong meter. Dimensions are immutable after publish — you cannot rename them to match new code. |
| Usage records already reported | The marketplace’s ledger (AWS / Microsoft), already invoice data | These stay with the provider and are never migrated. Re-sending them from the new system is the classic double-bill. Read them back to reconcile; never replay them. |
| The meter of record | One system, for any given hour and dimension | For every hour, exactly one system is authoritative. Parallel reporting is fine because the provider de-duplicates; parallel authority — two systems each believing they own the number — is what produces mismatches. |
| In-flight private offers | The marketplace, as agreements between you and the buyer | An active usage-based offer keeps its dimensions and pricing across the switch. The new platform reports against the same agreement; it does not re-create the offer, and re-creating it would fork the meter. |
| The reconciliation window | The provider’s billing calendar (AWS 06:00 UTC on the 1st; Azure per-period reconStatus) | The dated cutoff by which a period’s usage must be final. The entire parallel run must sit inside one cycle, with margin before this deadline to resubmit a corrected record. |
The single sentence to carry out of this table: preserve the dimension names and the meter-of-record boundary, read the old records rather than replay them, and finish inside the window. Everything else in a metering migration is ordinary tooling work.
The cutover plan, in order
Sequence the switch so the new reporter is proven correct against a live marketplace before the old one is silenced, and so the only irreversible act — cutting the old path — comes last. The steps below are the parallel run made concrete.
- Map dimensions one-to-one. List every usage dimension on every offer and confirm the new platform is configured to send the identical name. This is where you catch a dimension that was renamed in code but is frozen on the offer. Map Suger’s usage-metering configuration against the dimensions the marketplace already knows before a single record is sent.
- Report from the new path in shadow, alongside the old. Point the new reporter at the same marketplace and let it post the same hours the old system posts. Because the provider de-duplicates per dimension per hour, the second identical record collides cleanly instead of double-billing — this is your live proof the new path speaks the API correctly.
- Reconcile the two systems, hour by hour, against the provider. Read the marketplace’s own view back — AWS’s honored records, Microsoft’s
reconStatus— and confirm the new system’s quantities match the old system’s and the provider’s for every dimension. Watch this across enough of a cycle to trust it. Marketplace reporting is where you reconcile the two views rather than eyeballing two dashboards. - Move the meter of record to the new system. Once the numbers agree, declare the new platform authoritative for new hours and stop the old system from reporting. This is the actual cutover, and you do it mid-cycle, never at a month boundary.
- Hold the old path readable through the reconciliation window. Do not decommission the old system the moment it stops reporting. Keep it able to resubmit a corrected record until the provider’s period deadline passes clean — 06:00 UTC on the first for AWS, the closed period for Azure. Only then sunset it. This is the sole irreversible step, and the window is why it waits.
Every step before the last is reversible, because the marketplace records were never yours to move. The migration is “safe” not because you were careful in the moment, but because the parallel run turned the one irreversible number — the meter you send — into something you verified against the provider before you trusted it.
Frequently asked questions
Will migrating billing platforms drop my usage records? No — the records you already reported are the marketplace’s, kept by AWS or Microsoft, and a migration cannot reach them. Only the reporting path moves. The single risk is an hour of new usage reported by neither system, which a parallel cutover prevents.
How do I avoid double-billing when two systems report the same usage? Both AWS and Microsoft de-duplicate per dimension per hour: an identical record is idempotent on AWS, and Microsoft returns a 409 Duplicate. So the same hour from two systems collides cleanly rather than double-charging — as long as both send the same quantity for that hour.
What is the reconciliation window in a metering migration?
The dated cutoff after which a billing period’s usage can no longer be corrected. AWS accepts the previous month’s records until 06:00 UTC on the first of the next month; Azure marks each event’s reconStatus per period. Finish the cutover inside one cycle, before that deadline.
Do my usage dimensions change when I switch metering platforms? They must not. Dimensions are defined on the offer at publish and are immutable, so the new reporter has to send the exact same dimension names. AWS rejects an unknown dimension; a mislabeled one silently bills the wrong meter, which is worse.
When in the billing cycle should I cut over metering? Mid-cycle, never at a month boundary. Run the old and new reporters in parallel inside a single billing period with margin to spare, so if a discrepancy appears you can resubmit a corrected record before the provider’s reconciliation deadline freezes the period.
Do in-flight usage-based private offers survive a metering migration? Yes. An active usage-based offer is an agreement between you and the buyer, held by the marketplace, and it keeps its dimensions and pricing. The new platform reports against the same agreement — do not re-create the offer, which would fork the meter.
Takeaways
- Migrating metering does not move your usage records — they are the marketplace’s, already invoice data. It moves one code path: where your product reports new usage. The only risk lives in the seam between the old reporter and the new one.
- Report from both systems in parallel before trusting either. AWS treats identical records as idempotent and Microsoft returns a 409 Duplicate, so the same hour from two systems collides cleanly instead of double-billing — which makes the parallel run a verification technique, not a hazard.
- The reconciliation window is a dated deadline: AWS accepts a month’s records until 06:00 UTC on the first of the next month. Run the whole cutover inside one billing cycle, with margin, and never cross a month boundary.
- Preserve the dimension names exactly — they are immutable on the offer, AWS rejects an unknown one, and a mislabeled one bills the wrong meter silently. Read the old records to reconcile; never replay them.
- Cut the old path last and keep it able to resubmit through the window. That is the sole irreversible step, and everything before it is reversible because the marketplace records were never yours to move.
Suger reports usage-based metering to every marketplace it supports — AWS, Microsoft, Google Cloud, Snowflake, Alibaba Cloud, and Oracle — from one place, against the dimensions each offer was published with. Adopting it follows exactly this pattern: run the new reporter alongside your current one and reconcile before you cut over. See how metering fits the wider billing flow on the billing and metering platform, how the numbers reconcile on marketplace reporting, or read how Suger reports usage in the Suger metering documentation.
Sources
Primary sources for the platform rules cited above. Last verified August 20, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- AWS Marketplace Metering: BatchMeterUsage API reference — That BatchMeterUsage reports SaaS usage, is idempotent on identical requests, accepts up to 25 UsageRecords per call, rejects records 24 hours or more after an event, and — the reconciliation-window fact — accepts the previous billing month's records only until 06:00 UTC on the first day of the next month. Also that a usage dimension must match a UsageDimension defined at publish (InvalidUsageDimensionException).
- Microsoft Marketplace: metering service APIs (usage event API) — That only one usage event may be emitted per hour of a calendar day per resource and dimension; that events can only be emitted for the past 24 hours (effectiveStartTime more than 24 hours back expires); that a second event for the same resource/date/hour returns 409 Conflict as a duplicate; that a batch holds at most 25 events; and that retrieved events carry a reconStatus (Submitted, Accepted, Rejected, Mismatch).
- Suger docs: Azure Marketplace metering (usage-based dimensions) — Suger product behaviour: the flat-rate model is the one that supports optional usage-based metering, dimensions are defined on the offer, and the pricing model is immutable after publish — so metering dimensions cannot be renamed on the far side of a migration.
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.