Switching CSMS providers is different from launching one for the first time - there are live chargers, active sessions, real customer accounts and revenue already flowing through the system you're moving away from. Get it wrong and drivers see it immediately: a charger that won't start, a balance that's missing, an app that suddenly stops working. Here's a structured approach to moving off a legacy CSMS without any of that.
Why operators switch
Most migrations aren't about dissatisfaction with any single feature - they're about consolidation. An operator that started with a bare-bones CSMS ends up bolting on a separate payment processor, a separate billing tool and a separate app vendor as the business grows, and each one adds its own reconciliation, support relationship and point of failure. Migrating to a full-suite platform - CSMS, tariffs, billing and the driver app under one system - is usually a move to stop stitching four vendors together, not a reaction to any one of them failing.
Five stages of a controlled migration
1. Assess
Inventory every charger, its manufacturer, model and current firmware; every integration the existing CSMS touches (payments, ERP, CRM); and every piece of business data that has to survive the move - customer accounts, wallet balances, tariff structures, transaction history. This stage is discovery only - nothing moves yet.
2. Map
Define exactly how charger, customer, tariff and business data in the old system map to the new one. Tariff structures rarely translate 1:1 - a flat per-kWh rate in the old system might need to become a per-station override in the new one to preserve the same pricing. Getting this mapping wrong is the single biggest source of billing disputes after a migration, so it gets validated before any data moves.
3. Validate
Test hardware connectivity, integrations and business workflows against the new platform before touching production traffic. Because OCPP-compliant chargers speak a standard protocol, reconnecting them to a new CSMS is typically a remote configuration change - pointing the charger at a new backend URL - not a truck roll to replace hardware. Confirm that on a handful of non-critical chargers first.
4. Migrate
Move the agreed workloads in a controlled sequence rather than all at once - typically a batch of chargers and their associated customer/tariff data, verified, before the next batch. Running the old and new systems in parallel during this window (a “dual-run”) means a problem with one migrated station doesn't take down the rest of the live network, and gives you a fallback if something doesn't reconcile.
5. Cut over
Transition production traffic fully to the new platform and validate the new environment under real load - live sessions, live payments, live reporting - before decommissioning the old system. Keep the legacy system reachable (read-only) for a defined period afterward in case historical data or disputed transactions need to be checked against it.
What actually moves, and how
- Chargers - reconnected via OCPP configuration, not replaced, as long as they're already OCPP 1.6J/2.0.1-compliant.
- Customer accounts and wallet balances - exported and imported as data; drivers keep their balance and history, they don't start over.
- Tariffs and pricing - re-created and validated against the mapping from stage 2, then tested against live session data before going live.
- The driver-facing app - either the existing branded app is updated in place (drivers see no change beyond an update prompt) or, if switching to a new white-label vendor entirely, a new app release with a clear migration notice to existing users.
Minimizing what drivers notice
The realistic goal isn't zero visible change - it's zero disruption to charging itself. A brief, planned maintenance window communicated in advance is normal and expected; an unannounced outage or a driver discovering their balance is gone is not. Migrating in batches with a dual-run period, rather than a single cutover night for the whole network, is what makes that difference achievable on a live business.
For a comparison of what a consolidated platform looks like versus the stitched-together setup most migrations are leaving behind, see build vs. buy vs. white-label. If the network also needs to move to different infrastructure as part of the switch, see choosing a deployment model first - it affects how the migration itself gets sequenced.
Frequently asked questions
Do drivers need to re-register or download a new app?
Not if the existing branded app is being kept and updated in place - accounts and balances carry over. A new app is only needed if the brand or app identity itself is changing, in which case a migration notice inside the old app is standard practice.
Do we need to replace our chargers to migrate?
No, as long as they're already OCPP 1.6J or 2.0.1-compliant - reconnecting them to a new CSMS is a remote configuration change. Chargers that aren't OCPP-compliant need a firmware update first, which is a separate workstream from the CSMS migration itself.
How long does a typical migration take?
It depends on network size and how much custom integration exists, but the five-stage structure above - run in batches with a dual-run period - typically adds a few weeks on top of a standard greenfield launch timeline, rather than doubling it.