Recurly holds your recurring billing and recovery state. Azotte mirrors your accounts, subscriptions, and lifecycle first, runs alongside Recurly, then cuts over cohort by cohort. Recovery state and billing history are carried forward, not dropped.
A Recurly migration must protect access, renewal timing, cancellation state, coupon logic, recovery and grace-period state, and payment references. Azotte uses those invariants to shape the import and cutover order, so customers keep their subscription exactly as it was.
Mirror first. Cut over second.Pull Recurly accounts, plans, subscriptions, invoices, and recovery state through the API. Mirror them in Azotte while Recurly keeps billing, then move customers in controlled cohorts.
A big-bang switch breaks subscriptions at the worst moment, usually at renewal. Group customers by risk and validate each cohort before the next one moves.
It depends on subscription complexity and channel count. A mirror-first migration lets you run in parallel within weeks, then move customers in cohorts at their own pace rather than one risky cutover.
No, when entitlement migration is separated from payment migration. Azotte becomes the access and lifecycle source of truth first, while Recurly keeps billing, so access never depends on the payment cutover being finished.
Accounts, plans and add-ons, subscriptions and status, renewal and billing-cycle anchors, coupons, and the IDs that map back to Recurly. Invoice history and recovery state stay preserved and are carried forward.
Recovery state is treated as first-class. Grace periods are preserved, no duplicate retries are sent, and mid-recovery customers move on a dedicated path into Azotte recovery once their cohort is ready.
No. Azotte runs alongside Recurly. New subscriptions can start on Azotte while existing ones migrate cohort by cohort. Billing execution can stay on Recurly until you choose to move it.
