Migration playbook: Recharge to SubZwallet

This guide is for teams moving from Recharge to SubZwallet and trying to avoid the two common failure modes: rushed cutovers and unclear ownership. The goal is not just technical migration; it is operational continuity with better retention execution after launch.

Why this migration strategy works

High-performing teams treat migration as an operations project, not a one-time data import. They define business outcomes first (save rate, churn trend, support load), then map technical work to those outcomes. This keeps teams from over-optimizing low-impact details while missing core renewal and customer-experience risks.

Phase 1: Planning and ownership

Name a single migration owner with authority across support and lifecycle operations.
Define success metrics for the first 30 days: billing success rate, cancellation rate, support ticket volume, and retention-save actions.
Create a decision log for cutover rules, fallback triggers, and escalation contacts.
Set customer-facing communication windows and response templates before any launch date is announced.

Phase 2: Parity mapping (before import)

Map every active selling plan, cadence, discount behavior, and subscription state to a SubZwallet equivalent. For each mapping, document expected customer-visible behavior at renewal, skip, pause, and cancellation moments. If any behavior cannot be mapped exactly, write the accepted difference and customer message in advance.

Parity checklist for ops teams

Plan frequency and billing schedule parity
Discount and reward behavior parity
Customer portal actions parity (pause, skip, swap, cancel)
Email and notification parity for billing and lifecycle events
Dunning retry policy parity for failed payments

Phase 3: Staged validation

Run a controlled test cohort first. Use subscribers that represent your edge cases: multi-item subscriptions, discount-heavy cohorts, and high-support segments. Compare outcomes against your expected behavior matrix, then resolve gaps before broad rollout.

Validation scenarios to test

Successful renewal with standard cadence and discount.
Failed payment flow with retries and final action.
Customer-initiated pause and resume from portal.
Cancellation flow with save alternatives (skip, delay, swap).
Support-agent override actions and audit trail checks.

Phase 4: Launch-day runbook

A stable launch has a short command chain and explicit checkpoints. Keep one channel for active incidents, one for customer comms approvals, and one for reporting. During launch, prioritize customer-impacting issues first: failed renewals, portal access, and high-value subscriber tickets.

Post-launch week one priorities

Monitor billing success and failed-payment cohorts daily.
Review cancellation reasons and save-action acceptance rates.
Tighten support macros based on real ticket patterns.
Schedule a 7-day retro with lifecycle, support, and ops owners.

Common mistakes and better alternatives

Mistake: launching without a parity matrix. Better: approved behavior matrix with owner sign-off. Mistake: support informed too late. Better: ticket playbooks and escalation paths ready before cutover. Mistake: declaring success based only on migration completion. Better: measure first-30-day retention and support outcomes.

See Manage Subscriptions, Dunning, and Flows to operationalize retention after migration.