The problem is not only the old backend
The hard part of a CSMS migration is not picking the replacement platform. It is controlling transition risk while live chargers, field teams, roaming partners, and billing keep running through every wave.
Most CPOs do not replace a legacy CSMS because they enjoy running migration projects. They do it because the current platform has become a constraint:
- adding new charger models is painful
- roaming or billing integrations require vendor services
- operational data is hard to export
- pricing or contract terms no longer match the business
The mistake is assuming the project is mainly about selecting the new vendor. It is not. A brownfield fleet does not pause for a cutover. Chargers stay energized, drivers keep starting sessions, and CDRs keep flowing to roaming partners. Treat the migration as a connectivity, routing, and data problem first, and the vendor choice becomes the smaller decision. The backend you are leaving is rarely the only thing that needs to change; the integrations wrapped around it usually carry more hidden risk than the platform itself.
Why does big-bang CSMS migration fail?
A single all-at-once cutover fails because it removes every rollback option at the exact moment you need one most. When a firmware quirk or a misrouted OCPI request surfaces, there is no clean fallback, so a routine integration bug becomes a fleet-wide outage.
The failure pattern is consistent across mixed-fleet rollouts. A charger model that behaved in the lab sends a slightly non-standard BootNotification or StatusNotification (both defined in the Open Charge Point Protocol), the new CSMS rejects it, and that site goes dark with no path back to the old platform. Multiply that across hundreds of heterogeneous chargers and the project stalls under live incidents. Big-bang also concentrates blast radius: billing, support tooling, and roaming authorization all flip on the same day, so you cannot tell which subsystem caused a regression. Phasing exists precisely to keep that blast radius small and diagnosable, one charger group at a time.
Why start with a migration map instead of a vendor demo?
Start with a migration map because it turns a vague platform swap into a sequenced plan with known dependencies and clean cut lines before you ever sit through a demo. Inventory the estate you actually run, not the idealized one in your asset register.
Map the estate across five dimensions:
- charger groups by model, firmware, and site criticality
- backend integrations such as billing, CRM, support, or monitoring
- roaming and OCPI dependencies
- data exports and reporting flows
- operational processes that rely on the current platform
That map tells you whether the migration can happen in clean waves or whether you need an intermediate architecture first. In practice, the OCPP side is the part teams underestimate: two chargers with the same model number can run different firmware and present different quirks in heartbeat intervals, meter values, or reset behavior. The map is where those exceptions get named before they become production surprises. If the dependency graph is dense, with billing, support, and roaming all wired straight into the legacy backend, that is a signal you need a routing layer before any platform swap rather than after it.
What are the four phases of a safe migration?
A safe migration moves through four phases: isolate connectivity, pilot a low-risk group, migrate in waves, then decommission with evidence. Each phase ends with a sign-off and a rollback path, so no single step can take the fleet down.
The phases below are ordered to shrink risk before it compounds. You build a stable control point first, prove the full business flow on a small group, then scale the proven pattern across the estate in segments you can reason about.
Phase 1: isolate connectivity and routing
If the existing platform is tightly coupled to chargers, the first goal is to create a cleaner control point between field hardware and backend logic. An OCPP gateway or routing layer gives you that seam. It lets you:
- normalize charger behavior across firmware versions
- split fleets across backends during the transition
- capture events in a stable schema you control
- test new workflows without moving everything at once
This seam is what makes everything after it reversible. With routing in place, moving a charger group between backends is a configuration change, not a site visit to recable every unit.
Phase 2: migrate a low-risk pilot group
Do not start with the hardest chargers or the most politically sensitive sites. Start with a pilot group that is operationally important enough to be real, small enough to control closely, and diverse enough to expose integration issues.
The pilot has to validate more than connectivity. It should exercise the full business flow: session start and stop, status events, billing, support tooling, and reporting. A pilot that only proves chargers connect will hide the failures that actually hurt, like CDRs that reconcile incorrectly or roaming authorization that times out under real traffic.
Phase 3: move in waves
Once the pilot is stable, define migration waves by fleet segment. Common segments are charger brand, geography, customer account, site criticality, and existing backend dependency. Segmenting this way keeps each wave homogeneous enough that one rollback decision applies cleanly to the whole group.
Every wave should ship with:
- clear success criteria
- a named rollback path
- a communications plan for support and field ops
- a sign-off owner
Waves grouped by charger brand are often the most forgiving, because chargers from one manufacturer tend to share firmware behavior, so a quirk you fix once applies across the wave.
Phase 4: decommission with evidence
The old platform should only be retired after you can prove the team no longer depends on it. Decommissioning on a calendar date instead of on evidence is how teams rediscover legacy workflows after the contract has already ended.
Require proof on four fronts before shutdown:
- historical data is exported or preserved
- reconciliation between old and new records is complete
- operational alerts fire correctly in the new stack
- no hidden legacy workflow still runs on the old platform
If you skip this proof step, the export you assumed was simple often turns out to be gated behind a vendor services request you can no longer file.
Routing layer first or full platform swap?
A routing layer first is the lower-risk path when your fleet is heterogeneous or your integrations are tightly coupled to the legacy backend. A direct platform swap can work for small, uniform fleets with clean data exports, but it concentrates risk into a single event. The table below contrasts the two approaches.
| Factor | Routing layer first | Direct platform swap |
|---|---|---|
| Rollback granularity | Per charger group | Whole fleet at cutover |
| Fleet diversity tolerance | Handles mixed firmware well | Best for uniform fleets |
| Parallel run | Old and new backends run side by side | Limited or none |
| Time to first value | Faster, fewer chargers touched | Slower, all-or-nothing |
| Upfront architecture cost | Higher (added OCPP layer) | Lower initially |
| Risk profile | Spread across waves | Concentrated at cutover |
For most brownfield CPOs the routing-first path wins because it converts an irreversible event into a sequence of reversible ones. The added OCPP layer is an insurance cost, and it pays off the first time a wave needs to roll back without a site visit.
Questions to force into the buying process
Vendor answers here predict your migration risk better than any feature list. If responses are vague, the risk is quietly being transferred onto your operations team, where it surfaces as incidents instead of contract terms.
Get every serious vendor to answer these in writing:
- Can we run your platform in parallel with our current CSMS?
- Can charger groups be migrated independently?
- How do we roll back if a site fails after cutover?
- How do we export historical sessions, CDRs, and status data?
- Which migration tasks require your services team?
- How do you handle chargers with partial or inconsistent OCPP behavior?
Question six is the tell. A vendor who treats non-standard OCPP behavior as your problem rather than theirs will hand you the integration debt mid-migration. The RFP checklist turns these into procurement criteria you can score.
What should you watch in the first 30 days after a wave?
The first 30 days after a wave decide whether the migration is healthy or quietly degrading. Watch operational signals from the chargers and roaming flow, not a vendor dashboard screenshot, because regressions show up in reconnects and CDRs long before they show up in a summary tile.
Track these after each migration wave:
- charger availability and reconnect rates
- session start and stop reliability
- roaming authorization success
- CDR and tariff consistency on the OCPI side
- support ticket volume by charger group
- time to investigate incidents
A rising reconnect rate concentrated in one charger group is an early warning that a firmware quirk slipped past the pilot. Catch it inside the wave, while rollback is still cheap, rather than after the next wave has already moved.
Where EV Cloud fits
EV Cloud is a strong fit when the challenge is not only "replace vendor A with vendor B" but "modernize the architecture without losing control of the fleet." That usually means:
- inserting a dedicated OCPP layer before a full CPMS swap
- routing different charger groups to different backends during migration
- keeping data access stable while the commercial stack changes
- preserving a rollback option during rollout waves
If you are still deciding whether an intermediate architecture is necessary, read When to add an OCPP gateway before replacing your CPMS. If you are already scoping the work, get in touch or compare approaches on the comparison hub.
