When operators decide to switch charge point management systems (CPMS), the platform choice is only half the decision. The other half is how to make the move. A cutover shifts the whole network on one planned date. A phased migration moves it in batches over weeks or months, with both platforms running in parallel throughout.
Most teams make this call once, which is why it tends to get debated longer than it needs to be. It is a narrower decision than it looks, settled less by preference than by what your hardware, your integrations, and your team can support. Operators who have already concluded their platform no longer fits the network they are running usually arrive here with the question half-formed.
The Cutover: Everything Moves at Once
In a cutover, the whole network moves on one planned date. One day your charge points, drivers, tariffs, and integrations run on the old platform. The next day they run on the new one, and the old platform is switched off.
The work is front-loaded. The preparation phase is intense: you reconfigure charge points to point at the new platform, migrate driver accounts, and validate data. The transition itself is concentrated into one defined moment. Teams do not hold two operational realities at once, and there is no ambiguity about which platform is authoritative.
Reconfiguring charge points remotely is the ideal case, and reality is more varied. Most modern chargers update over the air. However, some older models might need a maintenance window or a site visit. Both are manageable, but the split has to be counted before a date is set.
What transfers with your drivers is a condition to verify rather than a given. Account and session portability is limited in some jurisdictions and dependent on your new payment solutions stack. Additionally, users might have to register again or set new passwords, depending on different scenarios. Confirm this for your markets early; it is the part your drivers actually notice.
The Phased Migration: Groups Move Over Time
A phased migration, sometimes called iterative, moves your network in stages. Groups of charge points and drivers shift over several weeks while both the old and the new platform stay operational.
The trade is learning and improving as you move business cases. At any point you can pause, adjust, or move a batch back without having touched the rest of the network. Small, verifiable batches matter most when your sites are spread across regions, or when mixed hardware makes remote reconfiguration unpredictable: you might have a configuration failure on ten charge points instead of a thousand.
The cost shows up in parallel operation. All your teams manage two operational realities at once, from sales to accounting. OCPI connections are often an issue as an operator cannot have the same IDs running into different systems. Edge cases emerge: a charging session that straddles the migration boundary, a driver whose account exists in one platform but not yet the other, a roaming agreement that applies differently depending on which platform is serving a given site. These are among the questions operators hesitate to raise, and each one needs a named owner for the full transition window.
The financial and reporting dimension is easy to underestimate. A parallel period usually means two platform bills, two support runbooks, and reconciliation across both, with roaming settlement, fiscalization records, and regulatory reporting all split for its duration.
The longer the transition runs, the more of this accumulates. Scoping the parallel period up front, and holding to it, keeps a phased migration from stretching past what the team planned around.
How Charge Points Reconnect to a New Platform
Whichever approach you choose, the hardware migration is identical. Every charge point is configured to talk to one specific backend, the platform that runs it, over OCPP (the Open Charge Point Protocol). Moving it means changing that configuration without interrupting charging sessions or leaving the charge point unreachable.
AMPECO’s migration proxy takes that work off the critical path. Instead of pointing charge points at the new platform on day one, you reconfigure them to connect to the proxy, which routes their OCPP traffic transparently to the platform they run on today. While the migration is prepared, operations continue unchanged: charging and monitoring carry on as before, and neither your team nor your drivers see a difference.
As the migration date approaches (or as each batch is ready, in a phased move), you shift the proxy’s routing to the new platform, site by site or all at once. The per-charge-point work happens over weeks, in daylight, with verification, and the switchover becomes a routing change rather than a fleet-wide reconfiguration.
The proxy is one part of what surrounds this decision either way. A permanent migration team, the data-mapping and migration handbooks, a hardware testing matrix, and a structured scoping process apply to both approaches.
What Decides It for Your Network
Neither approach is safer in the abstract. Start with the constraints that remove an option rather than the preferences that weigh one, because those settle it fastest.
If a material share of your fleet cannot be reconfigured remotely, or if continuous availability is required through the transition, a single switchover is not on the table. If keeping OCPI ids intact during migration is a must, then an iterative approach is much harder to accomplish and would need high level of support from your legacy system.or if the one team that would run both platforms is already at capacity, the phased path is not on the table either. Whether you control the outgoing platform changes which of these apply: migrating off an in-house build carries no vendor-cooperation risk and no dual licensing, but the same engineers usually have to run both platforms, which is expensive in its own way.
Where both options remain open, five factors decide it.
| Factor | Points toward a cutover | Points toward phasing |
| Hardware reachability | Charge points can be reconfigured remotely and reliably A meaningful share need a maintenance window, a site visit, or are effectively offline | Charge points can be reconfigured remotely and reliably A meaningful share need a maintenance window, a site visit, or are effectively offline |
| Network size | The estate is uniform enough to verify as one unit, at any size | Large estates with natural batch boundaries by market os business cases specificities, or hardware generation |
| Geographic distribution | Field visits are concentrated and scheduable in one window | Sites spread across markets with different field teams, access rules, and reporting regimes |
| Internal bandwidth | Your team can commit a concentrated block of attention to a fixed date | Your team can sustain operations in two parallel systems and it is ready to undertake the extra work |
| Risk tolerance | You would rather manage one rehearsed event with a rehearsed rollback | You would rather manage a longer window with batch-level rollback |
Both approaches go further in The EV Charging Platform Migration Playbook: what preparation each one demands, where the OCPP proxy fits into either path, and how operators scoped the work internally. Download the playbook here.
Already know which constraints are yours? You can map your network against both approaches or book a 30-minute migration consultation and we will work through them with you.
