Ask an operator who has been through a platform migration what the hardest part was, and they rarely point to the technical handover. The data transfers, the OCPP proxy redirects the charge points, the new system comes up. That part, with the right preparation, takes hours. What takes months is everything else.
Five workstreams, running simultaneously
The instinct when planning a migration is to start with the technology: OCPP versions, data schemas, hardware compatibility, API integrations. These are necessary questions. But a migration that only asks them misses most of what determines success.
A platform switch runs across five workstreams at once, and none of them pause while the others catch up.
Business mapping determines what moves and what gets redesigned: which use cases transfer, which processes should be rebuilt rather than replicated, and whether the new platform’s data model can actually represent how the business runs. Alongside that sits technical compatibility — hardware OCPP versions, data quality, app store ownership, SIM card control. Neither workstream depends on the other, but both need to resolve before go-live.
Operational readiness is its own parallel track: roaming partners tested individually, field technicians briefed before switch day, support teams trained on the new interface from day one. Internal resourcing is a fourth workstream: who owns the project within the operator’s organization, and whether those people are genuinely available across the full migration window, not just the week before launch. And driver communications — usually the last thing planned — need to go out early enough that charge point users are not caught off guard by an interface change or a new app.
Each workstream has its own stakeholders, its own timeline, and its own consequences if it slips. A migration team that treats them as sequential — resolved one after the other — tends to arrive at switch day with open dependencies.
The business mapping problem
Every operator who has been running a charging network for more than a few years has accumulated use cases, exceptions, and workarounds that reflect how their specific business actually operates. Subscription plans structured around a billing system’s quirks. Tariff configurations that exist because the old platform couldn’t do something more obvious. RFID assignment flows that made sense when the network was smaller. When a migration team encounters these, the question is not just “how do we move this data” but “do we move this process as-is, or do we take the opportunity to fix it?”
That decision requires people with deep knowledge of the current system, the business teams who depend on it, and a migration partner who understands the new platform’s data model well enough to say what maps cleanly and what needs redesign. It takes time. It is also where migrations create real value beyond the platform switch itself, by forcing operational improvements that would otherwise never happen.
When evaluating migration partners, operators often find that business mapping depth weighs more heavily than they expected at the outset. “Migrating our pan-European network was a significant challenge that required thorough planning and preparation.” said Lukas Gläsel from E.ON Drive Infrastructure, “AMPECO’s extensive support and expertise helped us to set up and test everything before the migration, ensuring a smooth transition with minimal service disruptions.”
Coordination across the ecosystem
A migration also requires coordinating parties who have no formal relationship with each other: roaming hubs, payment processors, hardware vendors, external resellers, and the EV drivers who use the network every day.
Roaming connections need to be migrated and tested with each partner individually. Payment processors need to be reconfigured and validated before go-live. If the operator manages charge points on behalf of third-party CPOs, those operators need to be briefed, trained, and ready. Driver communications need to go out early enough that users are not surprised, with clear guidance on what to expect.
None of this is technically complex. All of it requires sustained coordination across organizations, timelines, and people who have other priorities.
When Swisscharge migrated 20,000 charge points to AMPECO in 2025, the execution involved three organizations working in parallel for months: Swisscharge coordinating internally across multiple operators in their ecosystem and managing early driver awareness campaigns; AMPECO’s migration team working through business process mapping, partner coordination, and dry run testing. The cutover itself was completed in a few hours. Swisscharge saw no drop in operational metrics and went on to record a 20% year-over-year increase in charging sessions and active drivers in 2025.
What good preparation looks like
A well-structured migration moves through six phases: discovery and scoping (business model, regulatory constraints, feature-to-architecture mapping, third-party dependencies); data mapping and insertion; switch planning (cutover vs. iterative rollout, OCPP proxy requirements, roaming migration strategy); testing and dry runs; sign-offs and final validations; and the transition itself.
The first four phases are where the outcome is determined. Switch day is the result of the work that preceded it.
Operators who start migration planning under pressure, after an outage or a lost deal, compress these phases. That compression shows up in post-go-live issues that could have been caught in a dry run. The best time to evaluate a migration is before the current platform becomes a serious operational constraint.
A migration that lands cleanly is built in the months before go-live. The five workstreams above don’t resolve on their own: they need owners, timelines, and a structured methodology that makes the project manageable from the first scoping conversation through the post-cutover stabilization window.
Interested to learn more? AMPECO’s ebook The EV Charging Platform Migration Playbook covers each phase in detail, including the questions to ask before committing to a timeline, the dependencies that need early resolution, and the internal framework for making the migration decision with both sides of the ledger on paper.
