Enel X Way Shutdown: The Migration Checklist for CPO Fleets

Start here, because the instinct is to overestimate the damage. A CMS shutdown is not a power cut. The hardware keeps its electrical function: contactors still close, the meter still counts, and a unit in offline mode may still start a session if its firmware allows it.

What you lose is the brain above the hardware.

What stops working when the backend goes dark:

What usually keeps working:

The takeaway: this is state loss, not electrical loss. Before you plan anything, split every model you run into those two columns on paper. That split tells you which sites are urgent and which can wait.

• Remote start and stop
• Authorization decisions (who is allowed to charge)
• Session and meter records that billing depends on
• Firmware delivery and remote diagnostics
• The health feed that tells you a unit is online
• The physical charge (contactor, meter, connector)
• Any behaviour hardcoded into the charger itself
• Offline session start, if the firmware is configured for it

Treat the window before cutover as evidence-gathering, not a scramble. A migration plan built on stale data finds its gaps at the worst possible moment. Work through these five items in order.

Step 1: Hardware inventory. Every charger by model, firmware version, connector type, and current online status. This is the foundation; everything below depends on it being accurate.

Step 2: SIM ownership. Many networked chargers connect over a cellular SIM. Confirm who owns it. If it belongs to the retiring platform, connectivity itself can lapse, and no backend change fixes a dead data link.

Step 3: Certificate audit. Note which chargers use certificates to trust a backend, and which will need new trust material to talk to a different CMS.

Step 4: Driver-data export. Pull account records, RFID token lists, and access groups while the portal is still up. Data you did not export before the lights went out is data you may not get back.

Step 5: Payment-token snapshot. Capture stored payment references and their mappings before the source system is gone.

Think of steps 4 and 5 as the point of no return. Everything else can be redone; exported data cannot be re-pulled from a dead platform.

Feature-count marketing is the wrong lens. Four technical questions decide whether a platform is a good home for your hardware.

OCPP support. Not just “supports 1.6,” but whether the specific messages and behaviours your chargers use are handled the way your firmware expects. That is a per-model question, covered in depth in the OCPP profile-drift guide.

Roaming (OCPI). If your drivers use other networks, confirm sessions and settlement continue across the move.

Payment stack. Check that tariffs, tax lines, receipts, and settlement work in the jurisdictions you operate in. A working “start session” does not prove the money path works.

Migration-friendliness. How does the platform onboard existing hardware, import driver and token data, and can it run alongside your current setup during a phased cutover? A CMS that is excellent to run but painful to migrate onto can cost you more in the move than it saves later.

A migration without a rollback plan is a bet that nothing goes wrong. Before a single charger cuts over, these six questions should have written answers.

If any of these lacks a concrete answer, the plan is not ready to run.

• What signals failure? For example, heartbeats missing past a set threshold, or session failures above a defined rate.
• Who can call it? One named person with the authority to decide, without waiting for a committee.
• How long does a revert take, per charger? And does it need physical access, or can it be done remotely?
• Is the old CMS still reachable during your cutover window? Or does the retirement date close that door before you are done?
• What happens to in-flight sessions at the moment of switch? Recorded on the old system, the new one, or lost between them?
• How do you prove a rollback fully restored function rather than a partial one?

Drivers experience a migration through the app they use and the charger they pull up to. Plan communication across every surface they touch, timed around the cutover.

On timing: send a heads-up before the change, a reminder close to the window, and a confirmation once the fleet is stable. The goal is simple. No driver’s first sign of a migration should be a charger that will not deliver electrons.

• In-app: what is changing, whether they need to reinstall or re-register, what to do if a session will not start.
• Email: the same message, because not every driver opens the app between charges.
• On-site signage: a short notice at the unit with a support number, for the moment a driver stands in front of a charger behaving differently than yesterday.

Everything above can be run in-house. A formal readiness assessment turns it into a single evaluated picture before any cutover date is set. It:

The output is a migration plan sized to your actual fleet, with the risky units named and sequenced. If you want that assessment run against your installed base, that is what our EV charger CMS migration readiness assessment is built to cover.

• Inventories the fleet by model and firmware
• Flags units whose SIM or certificate status blocks a clean move
• Confirms which chargers need field attention versus remote handling
• Maps current tariffs, tokens, and driver data to the target CMS
• Pressure-tests the rollback plan against the six questions above
• Validates OCPP behaviour per model against the target platform, rather than trusting a compatibility label