CPMS Migration: How to Switch EV Charging Software Safely

CPMS migration means moving charging stations and their operating workflows from one charging management platform to another. For a charge point operator, the challenge is bigger than changing a backend URL. Drivers still need to authenticate, charging sessions must remain traceable, payments must reconcile, and operations teams need a clear recovery path if the new connection fails.

A carefully staged transition can give an operator more control over integrations, deployment and customer experience. An untested cutover can leave connected chargers unavailable or commercial records split between systems. This guide explains how to plan a switch without assuming that open protocols make every charger, credential and payment integration automatically portable.

If you are still comparing platforms, start with our practical charging point management system guide. The next step is turning your preferred platform into a verified migration plan.

What does CPMS migration actually include?

A platform transition has three related parts: connecting the physical stations, moving the information that can be transferred, and rebuilding the operational processes around them. These parts do not necessarily move at the same time. A charger can successfully connect to the new backend while its customers, tariffs or accounting records still require work.

Charger connectivity and configuration

Stations must reach the destination system using an agreed protocol, station identity and authentication method. Network routing, certificates, firmware and configuration access all matter. Some devices allow remote endpoint changes; others require manufacturer assistance or a controlled on-site intervention. Establish the available method for each model before promising a network-wide remote switch.

Business data and external services

Inventory, customer accounts, credentials, tariffs, historic sessions and partner structures need separate treatment. Payment processors, roaming partners and mobile applications may hold information outside the current CPMS. Exporting a spreadsheet from the backend does not transfer those third-party relationships or recreate every integration.

When should a charging operator consider switching platforms?

Common triggers include limited reporting, inflexible payment workflows, difficult hardware integration, deployment requirements or a business model that has outgrown the existing software. Identify the specific operating constraint and establish a measurable baseline. “A better dashboard” is less useful than “finance can reconcile each completed session to its payment outcome without manual matching.”

Separate platform problems from site problems. Poor mobile coverage, damaged cables or insufficient electrical capacity will not disappear after a software migration. Review repeated incidents with the charger manufacturer and site team so that the transition does not inherit an unresolved physical fault.

Also compare the cost of moving with the cost of staying. Include integration work, site visits, support effort, temporary parallel operation and contract exit terms. Migration should address a documented need, not simply replace one feature list with another.

Step 1: Build a reliable charger and access inventory

Begin with one agreed inventory shared by the current provider, destination provider and hardware partners. Record each station’s unique identity, location, model, firmware, connector configuration and communication version. Include the ownership and access permissions needed to change settings. An operator may own the hardware while a manufacturer or previous service partner controls its administrative access.

Map stations to their commercial context: public charging, private depot, residential community or workplace. Note time zones, currencies, customer groups and the party responsible for customer support. These details influence testing and the choice of a suitable cutover window.

• Station and connector identifiers, with duplicate records resolved.
• Manufacturer, model, firmware version and supported OCPP implementation.
• Connectivity method, endpoint configuration access and certificate responsibilities.
• Applicable tariffs, user groups, roaming relationships and payment services.
• Site contact, maintenance partner and approved intervention window.

Keep secrets out of ordinary planning spreadsheets. Record who manages credentials and how authorized staff will provision them through secure channels. Do not copy production passwords into a migration checklist or a support ticket that several external organizations can access.

Step 2: Validate OCPP compatibility instead of assuming it

OCPP defines communication between charging stations and management systems. It improves interoperability, but matching a protocol label is only the starting point. Confirm the exact charger firmware, implemented functions and destination platform behavior. Test the functions your operation uses, including authorization, transaction recording, meter updates and remote commands.

The Open Charge Alliance explains that OCPP 2.0.1 is not backward compatible with OCPP 1.6. Moving a charger to a new CPMS does not automatically upgrade its communication implementation. If your network uses both versions, the destination must support the relevant connections or you need a separately validated upgrade path.

Distinguish certification from site acceptance

Check the scope and identity of any certification claimed for the products involved. Certification is useful evidence, but it does not prove that your complete combination of firmware, payment flow and site controls has already been tested. A successful boot notification is not a complete acceptance result.

For a mixed hardware network, group devices by model and firmware rather than testing one convenient charger and extrapolating to every station. Prioritize unusual configurations, older firmware and devices using manufacturer-specific extensions. Document which requirements remain dependent on proprietary functionality.

Step 3: Decide what data moves and what stays accessible

Create a data mapping document before importing records. Define which field in the old system corresponds to which field in the new one, how identifiers are preserved and how exceptions are handled. Time zones, units, account hierarchies and tariff effective dates deserve particular attention because small differences can change the interpretation of a session.

Historical sessions and financial records

Preserve an accessible record of the original transaction identifiers and relevant commercial documents. Decide whether old sessions will be imported into the new operational interface, retained in an archive or accessed through the previous provider during an agreed period. Maintain a clear distinction between historic records and sessions processed by the new platform.

Validate exports with sample records before the final extraction. Reconcile counts and totals by an agreed period and site. Investigate missing or duplicated records instead of assuming that a completed import means the history is accurate. Retention and access arrangements should reflect your contractual and jurisdiction-specific obligations.

Customers, RFID credentials and payment tokens

User accounts and RFID identifiers may be transferable, but credential formats, consent records and access permissions need validation. Test a real permitted credential and a revoked credential in the destination system. Where accounts cannot move directly, design a clear re-enrollment process and support path.

Payment tokens are especially important to discuss with the payment provider. They may be tied to a merchant account or processor environment and may require a dedicated migration process. Never assume a CPMS customer export includes reusable payment credentials. Do not handle raw card data as a workaround.

Step 4: Rebuild tariffs, payments and partner settlement

Recreate pricing rules using representative examples from your actual business. Check energy, time, session or idle-fee components where applicable, including rounding and the points at which each component begins or ends. Compare independently calculated examples with destination results.

Follow each test through the commercial chain: session completed, charge calculated, payment outcome recorded, refund handled if needed, and settlement information available to the relevant partner. Those are separate events. An application displaying “charging complete” does not establish that money reached the intended merchant account.

Confirm how subscriptions, promotional balances and partner shares are treated during the transition. If a balance cannot move automatically, agree on the customer communication and reconciliation process before switching access. See our EV charging billing and payment solutions for the workflows to review with a platform provider.

Step 5: Run a representative pilot with rollback criteria

Select a small group that represents your hardware and operating conditions. Include the intended communication methods, a realistic payment route and the customer groups you expect to serve. Avoid choosing only the newest station at the best-connected site.

Set acceptance criteria before testing begins. Assign an owner to each result and identify who can authorize a rollback. Agree on how the team will communicate during the intervention so that a field engineer, support agent and backend specialist act on the same information.

1. Connect: verify identity, connector status and reconnect behavior.
2. Authorize: check allowed, denied and revoked credentials.
3. Charge: validate start, meter updates and normal termination.
4. Recover: test controlled communication interruptions and charger restarts.
5. Bill: verify representative tariffs, payment outcomes and refunds.
6. Report: export the evidence operations and finance require.
7. Restore: demonstrate the agreed recovery procedure if acceptance fails.

Include smart charging behavior where it is part of the service. Confirm the relationship between backend schedules and local control, and keep electrical protection responsibilities with appropriately qualified teams. A remote software test should never depend on defeating site safety controls.

Step 6: Cut over in waves and reconcile each wave

Use a staged rollout organized around your tested device groups and support capacity. Avoid interrupting active sessions unless you have a documented and communicated reason. Determine how the old backend will close or retain those transactions before any endpoint change.

After each wave, compare the planned station list with the stations actually connected and usable. Check a sample of end-to-end sessions and review payment exceptions. Keep the next wave on hold if the team has not explained the previous wave’s failures. Rollout speed should follow evidence and operational readiness.

Communicate practical changes to drivers and site partners. Explain whether an application update, account sign-in or new access method is required, when changes happen and where help is available. Clear instructions reduce avoidable support demand at the moment the technical team is busiest.

Step 7: Monitor the new platform after the switch

Define a post-migration observation period based on the size and complexity of the network. Track connection stability, authorization failures, session success, missing meter data, billing exceptions and customer support contacts. Compare the results with your baseline using the same definitions and exclusions.

Maintain a controlled process for configuration changes during this period. Multiple teams adjusting tariffs, credentials and firmware simultaneously can make a fault difficult to reproduce. Keep a change log, preserve relevant evidence and route incidents to an accountable owner.

Retire the previous service only after commercial records, support access and contractual obligations are resolved. Closing an old account too early can remove information needed to investigate a refund or a session that started before the migration.

Frequently asked questions about changing CPMS providers

Can existing EV chargers move to a different platform?

Often they can, provided you have the required configuration access and the destination supports the actual charger implementation. Confirm firmware, connectivity, security settings and contract restrictions. Validate a representative device before committing to the full network.

Can migration happen without downtime?

Downtime depends on the equipment, configuration method and operating process. A staged transition can reduce disruption, but a zero-downtime promise should be supported by a demonstrated procedure. Plan a realistic window and communicate any expected interruption.

Does switching CPMS require replacing the driver app?

Not always. It depends on whether your current application can integrate with the destination services and whether the relevant accounts and payment relationships can be preserved. Confirm app ownership, integration scope and support responsibilities early.

How long does a CPMS migration take?

There is no useful universal timetable. Network size is only one factor; firmware variations, data quality, payment arrangements and configuration access can dominate the schedule. Ask for a project plan based on inventory and pilot findings rather than an unqualified duration estimate.

Plan a migration around your real charging network

A successful transition moves more than chargers. It preserves a usable service for drivers, traceable records for finance and clear control for the operator. Inventory first, validate representative hardware, resolve data and payment dependencies, then expand only after the pilot meets its acceptance criteria.

TrendPower provides EV charging management software and white-label platform options. Discuss your CPMS migration with our team using your charger models, firmware versions, target markets and deployment requirements. Exact migration support and integration scope should be confirmed for the project.