Charger backend migration for UK operators: plan for 10% site visits
Migrate charger back ends incrementally, using capability-based slices rather than a single cutover: this is the Strangler Fig pattern, and it is the safest route for live charging networks. The immediate next step is a full asset audit: every charger model, firmware version, connectivity method and critical service such as payments or roaming. That audit tells you which regulatory protections, including secure update capability and live status reporting, you must preserve throughout.
TL;DR:
About 10% of chargers typically require a physical site visit during migration, mainly due to firmware limitations or hard-coded SIM parameters.
Using layered slices and shadow testing reduces risks like payment failures and roaming outages compared to a big-bang approach.
Proper pre-migration audits of models, firmware, connectivity, and support for remote configuration key into compliance with UK regulations.
OCPP 2.0.1 enables more remote configuration and certificate workflows, but legacy units may still need manual support.
A staged, audit-first migration with clear rollback metrics is crucial to minimize downtime and restore capability if issues arise.
Table of Contents
How to sequence an incremental backend migration for chargers
Concrete technical checklist: OCPP, firmware, certificates and network
How to migrate EVSE metadata, driver accounts and roaming interfaces safely
A practical rollout recipe: shadowing, differential tests and rollback
Co-ordinating with charger OEMs and procurement to avoid blockers
How to sequence an incremental backend migration for chargers
The Strangler Fig pattern wraps new backend capability around the old system piece by piece, so the legacy platform shrinks gradually rather than switching off in one event. Large system migrations usually succeed when framed this way, using explicit routing and shadow testing to validate each slice before traffic moves across, which reduces risk compared with a single cutover.
Choosing the first slice matters more than any other decision in the programme. We favour this order:
Monitoring and telemetry, since it carries no transactional risk and lets you validate data flow early.
Non-payment back-office features such as session logs, reporting and driver notifications.
Payments and roaming, once the new platform has proven stable under lower-stakes load.
Firmware-controlled features, which depend on network and certificate work covered later.
A big-bang cutover concentrates every risk (payment failures, roaming outages, charger disconnections) into a single weekend, with no graceful way back.
Pro Tip: Run your first slice on a small, geographically clustered site group so field support can respond quickly if something breaks.
Concrete technical checklist: OCPP, firmware, certificates and network
Before writing a single line of migration code, build an inventory that answers four questions for every charger: model, firmware version, OCPP version, and which remote configuration commands it actually supports.
Document which chargers support ChangeConfiguration or SetNetworkProfile, since these allow remote reconfiguration without a site visit.
Generate client certificates and install CA roots ahead of time where security profile upgrades are planned.
Transfer SIM accounts or move to eSIM provisioning, and plan VPN and APN settings alongside cellular fallback routes.
Treat firmware updates as a last resort: stage them in small batches and check cellular bandwidth beforehand.
OCPP 2.x introduces structured network configuration messages including SetNetworkProfile, materially changing how migrations run compared with OCPP 1.6’s vendor-specific configuration keys, and our OCPP protocol guide covers the practical differences in more depth.
Guidance from large network migrations shows that about 10% of units typically require a physical site visit, usually because firmware cannot be pushed remotely or SIM parameters are hard-coded into the device. Budget field resource for that share rather than assuming full remote coverage.
Certificate rollout also ties into how chargers authenticate drivers; our note on Plug and Charge and ISO 15118 explains how automated authentication depends on the same certificate chain you are provisioning here.
How to migrate EVSE metadata, driver accounts and roaming interfaces safely
Data migration fails quietly: a missing config key or a mismatched EVSE identifier shows up weeks later as a support ticket, not a migration error. Export and validate every dataset before cutting traffic:
EVSE IDs, physical location data and connector mappings, checked against the live charger inventory.
Configuration keys and firmware versions for each unit, matched to the technical checklist above.
Driver account records, reconciled against transaction history to catch duplicates or gaps.
For driver accounts, you generally have three options: a straight import, a full re-provisioning that forces re-registration, or federation that keeps accounts on the old identity system while the new platform reads through an interface. Import is fastest but inherits any data quality problems; re-provisioning is cleanest but risks driver drop-off; federation buys time but adds operational complexity.
Roaming needs particular care: external EVSE identifiers used by roaming partners must be updated and tested with those partners before cutover, not after, since a mismatch silently breaks a driver’s ability to charge on your network through a third-party app.
A practical rollout recipe: shadowing, differential tests and rollback
Shadow testing is the backbone of a safe rollout. Run the new backend alongside the old one on live traffic, but use recording adapters so that payment captures, emails and other external side effects are logged for comparison rather than actually executed twice.
Route a small, deterministic slice of sessions (by site or charger ID, never randomly per request) to the new path.
Compare outcomes against the old system: transaction success rate, session start latency and uptime, using the same metrics you already track for charger availability.
Set explicit metric gates before promoting further traffic, rather than relying on a general sense that things look fine.
Define rollback boundaries in advance: which metric breach triggers an immediate revert, and which compensating action undoes any external side effect already triggered.
Pro Tip: Agree your rollback trigger thresholds with the team before the first cohort goes live, not during an incident.
Fleet operators managing scheduled downtime windows will recognise the same discipline used in planning reduced downtime for commercial vehicle fleets: small cohorts, clear go/no-go metrics, and a defined point at which you stop and reassess rather than push on regardless.
UK regulatory checkpoints to preserve during migration
Two statutory frameworks shape what your migration must protect. The Electric Vehicles (Smart Charge Points) Regulations 2021 require that charge points remain securely updatable and keep their minimum smart functionality even when ownership or supplier changes, which your migration plan needs to demonstrate rather than assume.
The Public Charge Point Regulations 2023 guidance adds operational obligations relevant to any backend swap:
Publish machine-readable availability data free of charge, continuously, through the transition.
Maintain EVSE status updates within 30 seconds, which your new telemetry slice must match before older monitoring is retired.
Follow the cybersecurity expectations referenced through ETSI EN 303 645.
Public charge points must keep EVSE status updates within 30 seconds throughout the migration, so this is one of the first things to verify once your telemetry slice goes live, per the Public Charge Point Regulations 2023 guidance. Keep an updated technical file and logs showing secure update capability as evidence, and plan payment and roaming interface changes with these deadlines in view rather than as an afterthought; our note on public charge point regulations sets out the fuller compliance picture.
Co-ordinating with charger OEMs and procurement to avoid blockers
Your contracts, not just your engineering, determine how smoothly a migration runs. Build these requirements into tenders and change orders:
Remote configuration support as standard, so ChangeConfiguration or SetNetworkProfile can be used instead of a site visit.
No hard-coded SIM or modem parameters (IMSI, APN) baked into firmware.
Remote firmware update capability, with the ability to read current firmware versions remotely for audit purposes.
Large-scale migrations typically use a mix of remote configuration, firmware pushes, custom scripts and manual work, and vendor cooperation is consistently cited as the deciding factor in whether a migration stays on schedule. Sequence SIM transfers and OEM support windows together, rather than leaving SIM logistics until firmware work is already under way, to avoid stations sitting offline for longer than necessary.
Operator checklist and proof points from the field
A workable one-page checklist covers four areas: the full asset audit, a written test and rollback plan with named metric gates, a RACI table naming who owns each slice, and a sign-off step confirming regulatory evidence has been captured.
Audit: charger model, firmware, OCPP version, connectivity method.
Test plan: shadow period length, promotion gates, rollback triggers.
RACI: named owner for engineering, compliance and field operations.
Evidence: technical file updates and status-reporting logs ready for review.
Checklist area | What to capture |
Asset audit | Model, firmware, OCPP version, config support |
Test plan | Shadow metrics, promotion gates, rollback triggers |
Compliance evidence | Technical file, status logs, update capability |
We bring this structure to our own migration and maintenance work, including manufacturer grant support and post-migration maintenance planning, where the same audit-first discipline keeps sites compliant and online during transition.
Where migrations actually go wrong
The most common mistake we see is treating migration as a single weekend event rather than a sequence of slices, which concentrates every risk, payment failures, roaming breaks and offline chargers, into one window with no safe way back. A close second is underestimating SIM and APN logistics, and a third is under-testing roaming and payment flows because they feel like someone else’s problem until cutover day.
The fix is unglamorous: audit first, slice the work, test every external side effect before it goes live, and treat a slower, staged rollout as the safer bet. If your risk tolerance is low, a scoped migration audit before you commit to a platform change is worth the time it takes.
— Swift Charging
How we support a charger backend migration
We approach a migration the same way we approach a new installation: site survey first, then a staged plan rather than a single switch. Our work typically covers firmware and SIM orchestration, staged slice-by-slice migration, managed ongoing support once the new platform is live, and grant assistance where a migration coincides with hardware upgrades.
A typical engagement starts with the asset audit covered above, moves through a shadow-testing phase on a small site cluster, and ends with a documented handover and a maintenance plan, whether that is our Basic, Standard or Fully Managed tier. If you are weighing a commercial EV charging platform move, or managing a fleet-specific transition through fleet EV charging, get in touch and we will scope the slices with you before anything goes live.
FAQ
What is the Strangler Fig pattern in backend migration?
It is an incremental migration approach where new backend capability is built around the old system piece by piece, so the legacy platform is gradually replaced rather than switched off all at once. This reduces the risk of a single large failure compared with a big-bang cutover.
How does OCPP 2.0.1 change a backend migration compared with OCPP 1.6?
OCPP 2.0.1 adds structured network configuration messages, including SetNetworkProfile, and formal certificate workflows that are not present in OCPP 1.6’s vendor-specific configuration keys. This generally allows more of the migration to be done remotely, though certificates need provisioning in advance.
Do chargers need a site visit during migration?
Some do: case studies from large network migrations show around 10% of units typically require a physical visit, usually because firmware cannot be reconfigured remotely. Budgeting field time for that minority avoids delays later in the programme.
What UK regulations affect a charger backend migration?
The Electric Vehicles (Smart Charge Points) Regulations 2021 require secure, authenticated update capability and retained smart functionality through any change, while the Public Charge Point Regulations 2023 guidance require machine-readable availability data and EVSE status updates within 30 seconds. Both need to be demonstrably preserved during and after the transition.
Can Swift Charging help migrate an existing charger network to a new platform?
Yes, we support staged migrations covering firmware and SIM coordination, platform transition and ongoing maintenance once the new system is live. Pricing depends on the scope of the site estate, so it is quoted after an initial survey rather than published as a fixed figure.
Sources
Recommended