Multi-CPMS Orchestration for OCPP Networks

Why might you need more than one CPMS?

You need more than one CPMS when a single backend can no longer serve every stakeholder that depends on the same charger fleet. The assumption built into most EV charging deployments is one network, one CPMS. In practice, it rarely stays that way.

Fleet operators often inherit chargers from acquisitions, each tied to a different vendor backend. Parking operators want one CPMS for billing and another for grid services. Enterprise campuses run a corporate CPMS alongside a public roaming network. Utilities layer their demand response platform on top of an existing operator backend.

Each of these situations creates the same problem: how do you send the same OCPP stream to two different systems that weren't designed to share it? The charger only speaks one protocol session at a time, so the coordination has to happen above it, not inside the hardware.

Why does duplicating WebSocket traffic fail?

Duplicating WebSocket traffic fails because OCPP is a request/response protocol, not a one-way feed. The obvious approach is a TCP-level proxy that copies WebSocket frames to multiple backends. This works at the connection layer but breaks immediately at the application layer.

When a charger sends a StatusNotification, it expects exactly one response with a matching message ID. If you fan out to two backends, you get two responses, and the charger rejects the second as an unsolicited message. That can trigger error handling, a CALLERROR reply, or disconnect logic depending on the firmware.

It gets worse with commands that change state. Imagine both backends independently issue a RemoteStartTransaction or a SetChargingProfile. The charger now receives conflicting instructions on the same connector, applies the last one it parsed, and your two systems disagree about what the charger is actually doing.

You can't proxy OCPP at the TCP level. You have to understand the protocol and arbitrate at the message layer.

A worked failure scenario

Here is how the naive setup unravels in a real mixed-fleet rollout. An operator inherits a site running on a legacy CPMS and wants a new analytics platform to see the same traffic. They drop in a frame-duplicating proxy and point both upstreams at the live chargers.

For a few minutes everything looks fine. Then a vehicle plugs in. The charger sends Authorize, and both backends answer. The legacy CPMS returns Accepted; the analytics platform, which has no driver in its allow-list, returns Rejected. The charger sees two responses to one message ID, treats the second as a protocol violation, and tears down the WebSocket. The session never starts, the driver walks away, and the support team sees an intermittent "charger keeps dropping offline" ticket with no obvious cause.

The fix is not a better proxy. It is a broker that owns the single response path and demotes the analytics platform to a read-only observer, which is exactly the architecture below.

The right multi-CPMS architecture

The right architecture puts an application-layer broker between the charger and every backend, so the charger only ever sees one OCPP endpoint. The broker terminates the charger session, then arbitrates which upstream owns the response path and which upstreams merely observe.

A proper multi-CPMS setup requires an application-layer broker that:

1. Maintains one connection per charger — the charger sees a single OCPP endpoint
2. Fans out at the message level — each upstream gets a copy with its own message ID sequence
3. Aggregates responses — the broker waits for a response from the primary upstream and returns it to the charger; secondary upstreams process asynchronously
4. Handles upstream failures gracefully — if a secondary CPMS is down, the primary path isn't affected

This is exactly what EV Cloud's multi-CPMS routing mode implements.

The table below contrasts the three ways teams try to send one charger fleet to several backends.

Most OCPP firmware exposes a single management connection, so the broker approach is the only one that scales across a mixed fleet without touching hardware.

Configuring multiple upstreams

You configure multi-CPMS routing by declaring an ordered list of upstreams per charger or per network, then assigning each one a role. Roles decide who answers the charger and who only listens. The configuration lives in the broker, so chargers in the field stay untouched.

In EV Cloud, you define upstreams per charger or per network:

{
  "charger_id": "CP-001",
  "upstreams": [
    { "url": "wss://primary.cpms.io/ocpp", "role": "primary" },
    { "url": "wss://analytics.internal/ocpp", "role": "observer" }
  ]
}

primary upstreams participate in the request/response cycle. observer upstreams receive a copy of every message but their responses are discarded. This is ideal for analytics pipelines, billing systems, or grid services that need visibility but don't control the charger.

Operational rules that keep this architecture safe

The rule that matters most is a single, explicit control boundary: exactly one upstream is authoritative for charger control, and everyone else observes. Multi-backend routing is only useful if that boundary stays clear under load and during incidents.

In production, that usually means:

1. one upstream is explicitly authoritative for charger control
2. observer systems are prevented from participating in the live request/response path
3. response timing and retry behavior are measured on the primary path
4. downstream consumers are prepared for eventual consistency, not perfect simultaneity
5. rollback is done by changing routing policy, not improvising charger-side changes

If those rules are not explicit, multi-CPMS architecture creates ambiguity instead of resilience.

Why is multi-CPMS the cleanest way to migrate?

Multi-CPMS is the cleanest migration path because it lets you validate a new backend against live traffic before it ever controls a charger. You route the legacy system as primary and the target system as observer, then watch the target handle real sessions with zero blast radius.

Once the target backend proves it parses every message, settles transactions correctly, and reconciles meter values, you promote it to primary and demote the legacy system. The final cutover is a routing change, not a field operation. Remove the old upstream from configuration, and you are done. No downtime, no charger reconfiguration, no truck rolls.

For the right fleet segment, this compresses migration work materially because you change upstream routing policy instead of touching every charger in the field. If your migration also crosses protocol boundaries, the same broker pattern pairs naturally with an OCPI layer for roaming and billing handoff. Teams weighing this against a hard cutover usually find the parallel-run window is what makes the move defensible to operations.

What should you check before running two backends?

Before running two backends, confirm that the control boundary, audit trail, and rollback plan are all explicit and documented. Most multi-CPMS incidents trace back to an unclear authoritative path or an unrecoverable rollback, not to the routing technology itself.

Before you adopt multi-CPMS orchestration, verify:

• the primary backend role is clearly defined
• observer systems cannot send live charger control responses
• charger event IDs and upstream message tracking are auditable
• timeout and retry behavior on the primary path is measured
• support teams know which system is authoritative during incidents
• rollback is documented per charger group or site wave

If you're evaluating whether this architecture belongs in your vendor shortlist, read How to Evaluate an OCPP Platform. If you're moving toward procurement, pair it with the EV charging software RFP checklist, or talk to our team about a parallel-run migration.