CTOs of in-house charging networks arrive at conversations with AMPECO carrying a set of assumptions about what a platform switch would mean for them — their custom logic, their team, their operational continuity, their specific business setup. Many of those assumptions are inaccurate. Not hypothetically inaccurate, but demonstrably so: the architecture, migration mechanics, and development model are consistently different from what most evaluating CTOs expect.
The five concerns below are drawn directly from conversations with operators who built their own platforms. They are the objections that stall evaluations, presented here with the specific answers that have moved evaluations forward.
“We’ll lose our proprietary capabilities — the custom logic, the integrations, the edge cases”
AMPECO is built to cover the full operational scope of a charging network: session management, billing, roaming, hardware management, driver experience, B2B portals, regulatory compliance across markets. For most operators, the platform handles what their in-house system does today, and handles it with more depth and breadth than a team maintaining a single-operator platform can sustain alone.
Operators who have developed a custom EV driver app, a B2B portal specific to their commercial model, or a pricing and billing engine tied to their business logic can keep those running and connect them to AMPECO through the platform’s API layer. Custom OCPI connections with roaming partners, API integrations with energy management systems, and data connections with existing CRM or finance systems can be migrated alongside the core platform. If driver account data lives in a CRM the operations team already uses, AMPECO connects to that system rather than requiring it to be replaced.
A UK operator running a lamppost charging network keeps three applications it built running on AMPECO’s infrastructure: an OCPI-based ad-hoc portal enabling smart charging without driver registration, a municipality reporting application, and an installer service tool. The operator owns them, built them, and continues to develop them independently. AMPECO is the foundation they run on.
“AMPECO will make our engineering team redundant”
The assumption behind this concern misplaces where engineering value actually lives.
Value is not in knowing how OCPP 2.0.1 works or in managing the mechanics of a payment terminal certification cycle. It is in domain knowledge: network topology, hardware edge cases, custom business logic, integration dependencies. That knowledge is not in the codebase being replaced. It is in the engineers who built it.
In a migration, that knowledge becomes more valuable, not less. Before any charge point moves to the new platform, the discovery phase maps firmware versions, custom integrations, business logic rules, and edge cases. The operators who run the smoothest migrations are the ones whose teams know their system most deeply, not despite their in-house experience, but because of it.
Once AMPECO handles the infrastructure layer — OCPP compliance updates, payment terminal certifications, regulatory sprints — the same engineering team has capacity for the work that had always been displaced by it. After migrating, one team shipped scheduled charging within months — a capability their customers had been requesting for years, but one the infrastructure maintenance queue had always displaced. The capacity had existed; infrastructure maintenance had simply always displaced it. This is a resource allocation question.
“We’ll lose control of our roadmap — we’ll be waiting on a vendor’s release cycle”
The roadmap concern usually reduces to a practical question: will we wait on a vendor queue for something our customers need?
The relevant comparison is throughput, not queue position. Powered by AI-native software and product development, AMPECO ships new capabilities daily at times the throughput of its pre-AI development baseline, measured by features shipped per sprint. For a team whose sprint capacity has been absorbed by compliance catch-up, that velocity difference is the central practical question. For most operators, the development pace means capabilities that would take quarters in-house are available across the platform in weeks when prioritized.
The honest answer on roadmap influence: operators contribute to the AMPECO roadmap. They do not control it. The development velocity means requests are addressed faster than most in-house teams can build anything, but delivery timelines vary significantly by feature complexity.
What does shape the roadmap is the operational reality of a large and diverse operator base. Common patterns — new regulatory requirements, emerging hardware compatibility issues, new billing model support — are prioritized by frequency and impact across the network. Individual operators benefit from that shared investment without bearing the cost of building it alone.
For requirements that fall outside those shared patterns, AMPECO’s API surface is the relevant question. If the requirement can be built as a custom layer on top of the platform, the operator maintains that differentiation. If it cannot, that is a genuine evaluation question and one a Proof of Concept is designed to answer.
“Migration will break our operations — downtime, lost data, hardware that won’t work”
Migration concerns are legitimate — a failed cutover at scale has real consequences — and the evidence on how they actually work is worth examining.
Swisscharge, one of Switzerland’s largest public charging networks, migrated approximately 20,000 charge points in a single overnight cutover with zero downtime.
From each charge point’s perspective, the migration is invisible — the hardware continues operating under its existing firmware and protocol configuration throughout the cutover.
Hardware diversity is not a constraint on migration scope. Evolt Charging migrated over 10,000 charge points from a 15-year in-house platform across 111 firmware versions and 12 hardware manufacturers. Justin Meyer, Managing Director: “the technical depth and long-term development capability” were the deciding factors in choosing AMPECO. Migration scope at that scale and that level of hardware diversity was handled successfully.
Before any charge point moves, the discovery phase establishes a complete picture of what exists: firmware inventory, custom integrations, business logic rules, operational dependencies. Discovery is where migration risk is understood and scoped, not where it is eliminated. Operators who invest thoroughly in this phase enter the cutover with a clear account of what the migration covers and what operational continuity looks like on the other side.
“Our specific setup is too complex — a standard platform won’t support how we actually work”
Every operator with a custom-built platform has some version of this concern. The commercial arrangements, billing logic, driver authorization model, or operational setup feels specific enough that a standard platform could not accommodate it.
Operators going into discovery expecting to find hard blockers consistently find fewer than they anticipated.
AMPECO’s operator base spans more than 200 networks across 70+ markets, each with its own billing structures, B2B arrangements, hardware configurations, and regulatory requirements. Most configurations that feel unique to one operator have been addressed in some form for others: multi-party commercial billing, custom driver authorization models, location revenue-sharing arrangements, multi-jurisdiction fiscal compliance. These are not novel requests in the platform’s development history.
What is genuinely specific to an operator’s setup typically falls into one of two categories. Either it runs on top of the platform as operator-owned software communicating through AMPECO’s APIs — the operator keeps full control and development ownership. Or it is something the implementation team scopes and addresses as part of the migration. Platform-level incompatibilities are uncommon in discovery, even for operators whose setup looks highly custom from the outside.
The lamppost network operator mentioned in the first section — the one running three custom-built applications — evaluated AMPECO specifically for an operational setup with requirements that don’t exist in most charging networks. Their assessment was that the platform’s architecture would support what they needed. What had looked like a blocker on paper did not become one in practice.
AMPECO works as the complete infrastructure for a charging network — not as a partial layer sitting alongside an existing in-house system. Discovery establishes what full adoption looks like for your specific setup: which custom logic transfers directly, which requires a custom layer built on the API surface, and what the full adoption sequence looks like operationally.
Turning answers into specifics
Each of the five sections above addresses an objection drawn from conversations with operators who built their own platforms. The answers are grounded in architecture mechanics, migration evidence, and development velocity data.
Those specifics become real only in your context: your custom logic, your firmware inventory, your migration scope, your architecture requirements.
The Proof of Concept maps that context. It takes your business logic, integration dependencies, and custom workflows against AMPECO’s architecture and produces a written assessment: what transfers directly, what needs a custom layer on top, and what requires product team input — based on what your setup actually contains.
Continue reading:
What Are Your In-House CPMS Engineers Actually Building? — the framework behind the commodity/differentiation question, for teams mapping their own situation before the evaluation begins.
Why CPMS Customizability Is More Than a Nice to Have — a deeper look at how AMPECO’s architecture supports operator-specific customisation in practice, with examples across billing logic, workflows, and custom integration layers.
