The direct answer
Usage-based subscriptions require manual review because creating the destination subscription does not automatically move accumulated usage, meter events, aggregation windows, or application-side reporting state. Map the recurring price and billing configuration, choose a precise usage cutover boundary, route new events to the destination, and reconcile any source usage that still needs invoicing.
Reviewed July 24, 2026 by the MoveMRR product team.
Migration behavior: Metered and Usage-Based Stripe Billing
MoveMRR can inventory and map recurring subscription dependencies, but metered billing couples Stripe to an event pipeline and an accumulation window. The safe migration unit is therefore not only a subscription object: it includes the last accepted source event, first destination event, aggregation period, pending invoice items, and replay or deduplication behavior.
What the readiness review must verify
Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run.
- Source and destination metered price or billing-meter semantics match.
- A cutover timestamp and event-routing switch are defined.
- Pending source usage and invoice-item intervals have an explicit settlement plan.
- Event IDs and application retries cannot duplicate usage across accounts.
The primary failure mode to control
Routing the same usage to both accounts double-bills; routing it to neither loses revenue. Copying a subscription without transferring or settling accumulated usage creates a hidden reconciliation gap.
Metered and Usage-Based Stripe Billing: source-to-destination checks
| Check | Required evidence | If it fails |
|---|---|---|
| Meter definition | Aggregation and dimensions match | Redesign destination meter |
| Cutover boundary | Last source and first destination event recorded | Do not start live routing |
| Pending usage | Invoice or transfer policy approved | Keep source billing open |
| Idempotency | Replay cannot duplicate events | Add event-level deduplication |
A controlled workflow
- 1
Verify the first prerequisite
Source and destination metered price or billing-meter semantics match.
- 2
Verify the second prerequisite
A cutover timestamp and event-routing switch are defined.
- 3
Test representative examples
Use sandbox data that includes the difficult records, not only the happy path.
- 4
Control the primary failure mode
Routing the same usage to both accounts double-bills; routing it to neither loses revenue. Copying a subscription without transferring or settling accumulated usage creates a hidden reconciliation gap.
- 5
Reconcile after creation
Compare destination behavior with the approved source-state and monitor the next event.
Limits to verify before migration
- Accumulated meter events and usage are not assumed to move with subscription recreation.
- Custom event pipelines and data warehouses require customer engineering work.
- Mixed licensed and metered items require full subscription-level review.
- This shape should not be auto-approved solely from catalog mappings.
Frequently asked questions
Does subscription migration move accumulated usage?
Do not assume it does. Usage events, aggregation state, and pending source invoices require a separate cutover and reconciliation plan.
Can the metered subscription itself be recreated?
The recurring configuration can be mapped when the destination pricing model is ready, but the usage pipeline must be validated separately.
How do I prevent duplicate usage charges?
Define an exact event boundary, switch routing atomically, retain event IDs, and reconcile the last source and first destination periods.