Start with the real job to be done
Most OCPP evaluations go wrong because teams ask the wrong first question.
They ask: "Which platform supports OCPP 1.6 and 2.0.1?"
Almost every serious vendor will say yes.
The harder and more useful question is:
What do we need this platform to let us change later without breaking operations?
For most CPOs, that means:
- Adding new charger brands
- Migrating away from a legacy backend
- Connecting to roaming or payment partners
- Keeping access to operational and billing data
- Running parts of the stack in parallel during transition
If a vendor makes those changes painful, the fact that it "supports OCPP" is not enough.
1. Check protocol support, but go deeper than the brochure
Start with the basics:
- Which OCPP versions are supported today?
- Is support production-grade or roadmap-only?
- Does the platform handle mixed fleets?
- What security options are supported in practice?
Then push further:
- How does the vendor normalize charger behavior across brands?
- How are firmware quirks handled?
- Can the platform expose raw protocol events when debugging matters?
- What happens when a charger only partially implements the standard?
If your team is still deciding how OCPP relates to roaming and partner integrations, read OCPI vs OCPP first. That distinction shapes architecture and budget decisions early.
2. Evaluate migration flexibility
This is where many buying processes stay too shallow.
You are rarely choosing software for a greenfield fleet. More often, you are inheriting:
- A legacy CPMS or CSMS
- A non-uniform charger fleet
- Existing roaming relationships
- Internal dashboards, billing, and field ops tools
Ask every vendor:
- Can we migrate charger groups incrementally?
- Can we run your platform alongside our current backend?
- Can we route some traffic to one backend and some to another?
- Can we roll back safely if a cutover fails?
If the answer is "we prefer a clean cutover," translate that as risk.
3. Look at routing and interoperability, not just charger connectivity
For many operators, the real platform value is not only talking to chargers. It is acting as the coordination layer between:
- Chargers
- Internal systems
- Roaming partners
- Payment partners
- Monitoring and analytics stacks
That is why routing architecture matters.
A strong platform should answer questions like:
- Can it connect one charger fleet to multiple backends?
- Can it support OCPI or other partner-facing workflows cleanly?
- Can it route different sites or charger groups differently?
- Can it preserve a live copy of operational data in your own systems?
If the answer is no, you may be buying a polished dashboard but not a durable infrastructure layer.
4. Inspect the data model and export story
Many EV charging teams underestimate how often they will need to reuse data outside the vendor's UI.
You will likely want your own access to:
- Sessions
- Meter values
- CDRs
- Location and status history
- Alarms and diagnostics
- Authorization and roaming events
Ask for details on:
- Export APIs
- Webhooks or streaming interfaces
- Historical retention
- Data ownership language in the contract
- Whether data is modeled consistently across charger vendors
If your data only becomes usable after it passes through a proprietary vendor UI, you are taking on future switching cost.
5. Review security and operational controls
A serious evaluation should cover:
- TLS and certificate handling
- Role-based access controls
- Audit trails
- Secrets management
- Charger identity and credential rotation
- Monitoring, alerting, and failure recovery
Also ask how the vendor supports:
- Staging environments
- Incident debugging
- Bulk configuration changes
- Firmware rollout coordination
The platform that demos best is not always the platform that fails safest.
6. Compare commercial models against lock-in risk
Pricing matters, but structure matters more than headline numbers.
Look for:
- Per-charger pricing that becomes punitive at scale
- Fees for adding integrations or exporting data
- Contract terms that make migration hard
- Professional services dependency for routine changes
A cheaper contract can become more expensive if every architecture change requires vendor intervention.
Use your pricing review together with your migration review. That is usually where hidden lock-in appears.
7. Use a weighted scorecard
Most teams benefit from a simple scorecard like this:
| Area | Suggested weight | |------|------------------| | Protocol and charger support | 20% | | Migration flexibility | 20% | | Routing and interoperability | 15% | | Data ownership and exports | 15% | | Security and operations | 15% | | Commercial model | 15% |
Adjust the weights to fit your business model, but keep migration and data in the scoring. Those are common blind spots.
8. Questions every shortlist vendor should answer
Ask for written answers to these:
- How do you support mixed OCPP 1.6 and 2.0.1 fleets?
- Can we run your platform in parallel with our current backend?
- How do we export historical sessions, CDRs, and status data?
- What parts of the platform require professional services?
- What happens if we want to add a second roaming or payment partner later?
- How do you handle charger-specific behavior that deviates from the standard?
- What is the rollback path if a migration wave fails?
If the answers stay vague, assume the operational reality will be worse than the demo.
Where EV Cloud fits
EV Cloud is built for teams that want infrastructure flexibility rather than a single closed stack.
That means:
- OCPP connectivity as a dedicated infrastructure layer
- Multi-backend routing for staged migration and parallel operations
- Compatibility with roaming and partner workflows
- Full access to operational data for your own systems
If you are comparing managed SaaS against self-hosted open source, read EV Cloud vs Open e-Mobility. If you are moving from research to procurement, use the pricing page and contact page to frame the rollout conversation.
