Because OCPP is an open standard, the promise has always been there: if your charging platform stops serving you, point your chargers somewhere better. It's a real promise — we've written before that a vendor's exit answer is one of the most revealing procurement questions — but "repoint the chargers" compresses a genuine engineering project into three words.
Here's what actually happens when a live network changes backend, and how to do it without drivers noticing.
What "switching" technically means
Every OCPP charger holds a small set of connection settings: the backend WebSocket URL, its charge point identity, and its authentication material (passwords or certificates, depending on security profile). Migration is, at its core, changing those settings on every charger — plus everything around that moment: data, tariffs, access cards, driver apps and operations muscle memory.
The catch is that the settings change happens through the old connection. Send a charger a broken URL and it reconnects to nothing; you've traded a migration for a van roll. That asymmetry — mistakes cost site visits — shapes the whole playbook.
Phase 1 — Discovery (where migrations are won)
Before anything moves, build the honest inventory:
- Per model: firmware version, OCPP version, supported security profile, and — critically — how its connection settings can be changed: remotely via OCPP configuration keys, via vendor tooling, or only physically.
- Per charger: identity, site, SIM/connectivity ownership (whose APN? whose contract?), and any vendor-specific management lock-ins.
- Data: what history you can export from the incumbent — sessions, meter values, RFID lists, tariffs — in what format, and what it costs to get.
The connectivity question deserves special respect: if SIMs and APNs belong to the outgoing vendor, "migration" includes a connectivity migration, and that changes the timeline entirely.
Phase 2 — Parallel build
Stand the new platform up completely before any charger moves: sites modelled, tariffs configured, RFID/authorisation lists imported, team accounts and roles created, integrations (billing, roaming, reporting) connected in test. Import historical data early — reconciliation arguments are much easier before the switch than after.
Then rehearse. Take one bench charger — or one forgiving low-traffic site — through the full journey: reconfigure, connect, authenticate, charge, bill. Every surprise found here is a van roll avoided later.
Phase 3 — Cohort cutover
Move the fleet the same way you'd roll out risky firmware: in waves, smallest and safest first.
For each cohort, the moment itself is short: push the new connection configuration, instruct a reconnect, and watch. The watching is the discipline — a cutover checklist per charger:
- Connected and accepted on the new backend (BootNotification received)
- Heartbeating at expected cadence
- Status correct on every connector
- A real test session: authorise, charge, stop, meter values present
- Old backend shows it gone (no split-brain)
Chargers that fail get reverted to the old URL — which is why you keep the old platform alive through the whole migration, and why cohort one is small. Common cohort-one lessons: a firmware build that silently ignores remote URL changes, a security-profile mismatch, an authorisation list that didn't import cleanly. Better to learn each on ten chargers than a thousand.
Phase 4 — The long tail and the paperwork
Some chargers always resist: dead remote management, ancient firmware, vendor-locked settings. They become scheduled site visits, not blockers — the beauty of cohorts is that 95% of the estate is migrated and stable while the stragglers get their appointments.
Then the unglamorous essentials: driver communications (ideally none needed — if apps and cards keep working, the best migration is the one drivers never notice), regulatory data feeds repointed, the incumbent contract wound down after a retention period for late-arriving disputes, and a final data reconciliation you file somewhere findable.
What the receiving platform owes you
A serious destination platform doesn't just hand you a URL. It should bring: per-model connection guidance from previous migrations, bulk import tooling for sites, chargers, tariffs and RFID lists, a staging environment for the rehearsal phase, cohort tracking so cutover state is visible per charger, and people who have done this before on the phone during cohort one.
That's the shape of migration and onboarding at AmpNexus — treat it as a checklist for whoever you're moving to, including us.
The takeaway
Backend migration is the ultimate test of the industry's open-standards promise — and it genuinely works. But it works because of inventories, rehearsals and cohorts, not because OCPP makes it magic. Plan it like a firmware campaign with higher stakes, keep the old system warm until the last charger settles, and drivers will never know it happened. That's the goal: the most boring possible version of a big change.
Moving a network? Talk to our migration team — or read how we approach onboarding.