How to Migrate Your Charging Network to a New CMS

Phase 1: parallel deployment. Both platforms live, chargers still pointing at the old CMS. New CMS receives driver data, RFID lists and historical transactions via export/import. Test drivers can charge through both platforms to verify parity.

Phase 2: cohort cutover. Move chargers in waves (10%, 30%, 100%) by re-pointing the OCPP endpoint. Watch session-success rates on each cohort before advancing.

Phase 3: retirement. Old CMS decommissioned after final data export. Historical records preserved either in the new CMS or as a read-only archive.

Some chargers hard-code their OCPP URL and can only be re-pointed via a physical service visit. If you have these, plan them out of the migration path first, a fleet audit up front saves surprises later.

Others accept OCPP URL changes over-the-air but require a firmware update to a compatible version first. Coordinate the migration with an OTA campaign; both are less risky in sequence than in parallel.

Export and import driver accounts, wallet balances, RFID lists and active subscriptions. Reconcile totals both directions.

Export and import transaction history for reporting continuity. This is not for billing (already settled) but for driver session history and finance reports.

Test at least ten real charging sessions on the new CMS with real chargers before cutover day. Nothing catches bugs like a real session.

Cutover during a low-demand window with the migration team on standby, and a documented rollback path if a cohort fails its health check.

• Charger inventory with vendor, model, firmware, and OCPP URL
• Driver accounts, credentials, and wallet balances
• RFID tokens and their user linkages
• Tariff definitions and their assignment to sites/partners
• Historical sessions and CDRs for reporting continuity
• Active subscriptions and Autopay mandates
• Outstanding invoices and refund state

• Keep the old CMS active in read-only mode during migration
• Migrate chargers in cohorts (10 percent, 30 percent, then full)
• Preserve old driver credentials so users are not forced to re-register
• Monitor session-success rate per cohort before advancing
• Define explicit rollback triggers (session-success below X, error spike, billing failure)

• Remote start flow (dashboard-initiated session)
• RFID authorization and session start
• QR/UPI payment and remote start
• Stop transaction (normal and vehicle-initiated)
• MeterValues capture and billing calculation
• Refund flow end to end
• Driver receipts and invoices
• Fault alerts and ticket auto-creation