Are an OCPP gateway and a CPMS replacement the same decision?
No. An OCPP gateway and a full CPMS replacement solve different problems, even when they surface in the same RFP. A gateway changes how charger traffic is connected, normalized, and routed. A replacement changes the operating platform your team works inside every day.
The confusion is understandable. Both arrive when a CPO is unhappy with an incumbent stack, so they get shortlisted together as if one is a smaller version of the other.
An OCPP gateway is mostly about the wire:
- charger connectivity and session control
- protocol normalization across firmware versions
- routing flexibility to one or more backends
- migration control during transitions
A full CPMS replacement is mostly about the workflow:
- day-to-day operating processes
- admin and support tooling
- packaged product surface area for operators and drivers
- vendor standardization across the estate
When you collapse those two into one question, the shortlist gets noisy fast. Vendors answer different briefs, and the scoring stops being comparable. Separate the connectivity decision from the platform decision, and the evaluation gets honest again.
When is a gateway-first approach the safer bet?
A gateway-first approach is usually safer when your biggest pain lives below the UI: charger connectivity, mixed firmware, and migration sequencing. It gives you a stable OCPP boundary before you commit to broader platform change, so you are not betting the estate on a single cutover.
That pattern fits estates with:
- mixed charger vendors and inconsistent OCPP behavior
- firmware that interprets the spec differently per model
- phased migration requirements across sites or regions
- a need to run old and new backends in parallel
- poor raw-event access from the current stack
In our experience, the failure mode in mixed fleets rarely shows up in the demo. It shows up three weeks in, when a specific hardware revision drops MeterValues differently, or refuses a RemoteStartTransaction your test bench accepted. A gateway gives you one place to absorb that, instead of patching the core platform per vendor.
The gateway-first path buys you sequencing. You stabilize the protocol layer first, then decide, with real traffic data, how fast the rest of the stack should move.
When should you replace the CPMS directly?
Replace the CPMS directly when the real bottleneck is workflow, not connectivity. If chargers connect reliably but your team fights weak admin tooling, broken tariff logic, or missing driver features, a gateway will not fix that. It sits below the layer where the pain actually lives.
Direct replacement is the better move when the dominant problems are:
- weak admin and support tooling for daily operations
- poor pricing, tariff, or OCPI billing workflows
- missing customer-facing or roaming features
- operations fragmented across disconnected modules
In those cases, adding a gateway first can be a detour. It adds a layer, a deployment, and an integration to maintain, without touching the workflow gap that triggered the project. The exception is when the gateway meaningfully de-risks the migration itself, for example by letting you cut sites over in waves instead of all at once.
A useful test: if your operators would notice the change but your chargers would not, the work is a platform problem, and replacement deserves the weight.
Gateway-first vs full replacement: which fits your problem?
The honest answer is that it depends on where the risk concentrates, infrastructure or workflow. The table below maps the common decision factors against each path so you can score your own estate rather than the vendor's pitch.
| Decision factor | Gateway-first | Full CPMS replacement |
|---|---|---|
| Mixed charger vendors and firmware | Strong fit, normalizes at the protocol layer | Weaker, each quirk hits the core platform |
| Migration sequencing | Wave-by-wave, run old and new in parallel | Tends toward a hard cutover |
| Raw event and data ownership | First-class, you keep the OCPP boundary | Depends on the new vendor's export model |
| Admin and operations tooling | Unchanged, still your incumbent's | New packaged workflow layer |
| Tariff, billing, and OCPI workflow | Unchanged unless paired with new backend | Addressed directly |
| Time to new operator features | Slower, gateway is plumbing not product | Faster, that is the point of replacing |
| Vendor lock-in exposure | Lower, chargers decoupled from any one backend | Higher, one vendor owns more of the stack |
| Rollout blast radius | Contained per wave | Estate-wide on the cutover date |
Read the table as a weighting exercise, not a tie-breaker. If most of your pain sits in the top half, connectivity and migration, gateway-first usually wins. If it sits in the middle rows, workflow and features, replacement earns its place.
What should happen first: gateway or replacement?
Sequence is often the real decision, not the binary. Most buyers frame this as gateway or replacement, but the higher-leverage question is what should happen first. Getting the order right usually matters more than the long-term end state, because order is what controls rollout risk.
Three sequence patterns cover most real estates.
Pattern 1: Gateway first, CPMS later
Best when:
- migration risk is high
- the fleet is inconsistent
- you need a stable OCPP boundary before broader change
Pattern 2: CPMS first, no gateway
Best when:
- the fleet is simpler
- there are few backend dependencies
- workflow problems dominate the business case
Pattern 3: Gateway plus selective replacement
Best when:
- you want an open infrastructure layer
- you still need packaged tooling in some workflow areas
- you do not want every charger coupled directly to a single platform vendor
A worked example: a mixed AC and DC fleet
Here is how the decision plays out on a realistic estate, the kind that makes the choice concrete rather than theoretical. Picture a CPO running three charger generations from two AC vendors and one DC vendor, all pointed at an incumbent backend the team has outgrown.
The estate
The fleet looks like this in practice:
- older AC units on OCPP 1.6J, with one vendor that sends
MeterValuesonly on a fixed clock and another that sends them on energy delta - newer DC units on OCPP 2.0.1, using the device model and richer transaction events
- a handful of sites behind flaky cellular, where reconnect storms after an outage matter more than steady-state throughput
The incumbent platform connects all of them, but the team can't get clean raw events, and tariff changes take a support ticket. So both problems are real at once: connectivity normalization and workflow.
How the two paths behave here
A big-bang full replacement asks every charger to re-register against the new backend on cutover. With three firmware behaviors and unreliable links, that is exactly when the long tail bites: a hardware revision that won't accept the new BootNotification interval, or DC units that expect 2.0.1 semantics the new platform half-implements. The blast radius is the whole estate on one date.
A gateway-first path lets the gateway hold the OCPP boundary while the team migrates site by site. The 1.6J quirks get normalized in one place, the 2.0.1 device-model data is captured before it reaches any backend, and reconnect storms are absorbed at the edge. Once connectivity is boring, the workflow problem can be solved on its own timeline, by replacing the backend behind a stable boundary or consolidating tariff logic without touching a single charger.
What we'd actually recommend
For this profile, sequence wins: gateway first, then a deliberate backend decision. The point isn't that replacement is wrong, it's that doing it before the protocol layer is stable converts a manageable project into a field-work problem. When connectivity is messy, we've found that ordering, not vendor choice, is what decides whether the rollout stays calm.
Cost and commercial implications
Direct replacement can look cheaper because it appears to remove one layer. That framing holds only if the cutover is clean. The headline quote rarely prices the field work, and that is where mixed-fleet budgets quietly blow up.
A lower quote may hide a more expensive rollout when it creates:
- a hard, estate-wide cutover
- charger-by-charger field visits for stubborn firmware
- more rollback exposure if a wave fails
- new lock-in once chargers are coupled to one backend
Gateway-first can look more complex on paper, with an extra layer to fund and operate. But it tends to reduce the costs that don't show up in a quote:
- migration disruption during the switch
- integration rework when one assumption changes
- switching risk later, because chargers stay decoupled
- operational brittleness across a mixed fleet
This is why architecture and commercial review belong in the same conversation. A cheaper architecture with an expensive rollout is not actually cheaper.
What questions decide the architecture?
Five questions usually settle it. The first four test whether your risk lives in connectivity and migration; the last tests whether it lives in workflow. Score them honestly against your own estate, not the vendor's demo.
- Is charger connectivity itself unstable or hard to control?
- Do we need phased migration rather than a big-bang change?
- Do we need multiple backends during transition?
- Is data ownership or raw event access part of the business case?
- Is the main problem really operations tooling instead of infrastructure?
If the first four are mostly yes, gateway-first deserves serious weight.
If question five is the dominant yes, a full CPMS replacement may be the cleaner answer.
Where EV Cloud fits
EV Cloud is built for CPOs who want a gateway-first or hybrid architecture: support for both OCPP versions maintained by the Open Charge Alliance (1.6 and 2.0.1), multi-backend routing, migration-friendly control over charger traffic, and stronger data ownership at the protocol boundary. It is most useful when the goal is to reduce platform risk before committing to a broader operating model.
The deeper point is the one this whole comparison turns on. Decide where your risk actually lives before you let a quote decide your architecture. If connectivity and migration dominate, hold the OCPP boundary first and replace behind it on your own schedule. If workflow dominates, move on the platform directly. And when both are true, sequence almost always beats a single big-bang cutover.
When you are ready to pressure-test the order for your own estate, the CPO migration checklist frames the sequencing, the pricing guide lines up commercial models against the architecture, and the comparison hub helps once you are in vendor shortlist mode. You can also talk through your fleet with us directly.
