Migrate to Spirii

You migrate a charging network to Spirii by repointing each charger’s Open Charge Point Protocol (OCPP) connection to Spirii’s backend, once the locations and charge boxes exist in Connect ready to receive them.

​

Before you start

This guide is for a charge point operator moving an existing network from another charge point management system (CPMS) onto Spirii. It covers chargers and tokens. Your commercial exit from your current provider, and the physical installation itself, sit outside it. Know these three things before you plan a date.

​

Remote or on-site

A remote migration is the cheaper approach, and it needs every charger in scope reachable through its manufacturer’s backend or over a VPN via its installed SIM. Older units without that access need a technician at the charger to change the setting by hand, which is slower and has to be scheduled around site access. Most networks end up with a mix: remote for the recent hardware, on-site for the rest. Split your inventory that way early, so the on-site work runs in parallel with the batches that can move remotely. Three other things extend a migration beyond the remote path, so establish early whether they apply: a SIM card swap or router setup, replacing the EVSE ID labels on your chargers, and new graphics for charger screens.

​

How a migration runs

Four phases. For a network of fifty chargers or more migrating remotely, the whole sequence typically runs about three months.

​

1. Pre-migration

​

Collect the data

Every charger you migrate needs a row of data before it can be created in Connect. The physical connector order matters more than it looks. It’s what makes connector DE*SPI*E00012345*1 in the platform the same socket a driver is standing in front of. Record the model and firmware version for every unit, and confirm each one against the models and firmware levels Spirii has validated. This is the prerequisite the rest of the plan rests on: a model that turns out not to be validated needs corrective action from its manufacturer and a repeat test afterwards, which moves every date behind it. Your Spirii representative confirms the current levels. Agree how configuration access is granted, and keep charger credentials out of any shared file. Access is usually given through your manufacturer backend to the people doing the work.

​

Build the network in Connect

Create the customers, locations, and charge boxes before migration day. Each charge box waits as a placeholder until its physical charger reaches it, and takes no sessions until then, so building them ahead of a batch has no effect on traffic still running on your current platform. See Charger activation. There are two routes: Spirii can also run the creation for you from your collected data. And if you’re integrating the Spirii API into your own systems as part of the move, that work runs in parallel with the migration rather than waiting for it to finish. Alongside the infrastructure, set up what makes the sites operational:

• Tariffs — the price each location’s chargers bill against
• Publishing and roaming settings — configured per location
• A service level agreement — where you’ve committed response times to a site owner
• The installation partner — recorded on each site

​

Coordinate roaming

Roaming is tied to your CPO operator prefix, such as DE*SPI. Before roaming works under Spirii, the prefix has to be registered with your national registry and approved by the roaming hubs. See Roaming connection. Moving roaming exposure between platforms involves the hubs and your current provider, so plan it with your Spirii representative well before your first batch. Line up two things alongside it: Roaming data propagates on the hubs’ own schedule, so expect a short delay before external networks reflect the change.

​

Prepare the configuration

The OCPP settings a charger needs are the same across manufacturers; only the place you enter them differs. Your manufacturer’s backend or local configuration environment is where they go. Reaching the endpoint also needs the AWS Root CA certificate and the security profile settings. Your Spirii representative supplies the current ones alongside any model-specific recommendations.

​

Set up a support channel

Open a shared channel across everyone involved — your operations team, your installer, your hardware manufacturer, and Spirii — and get it in calendars at least a week ahead. A charger that won’t connect often needs two parties in the same conversation. On an assisted migration, a weekly meeting through the project keeps the batch plan and its open items in one place.

​

2. Migration test

A migration test is mandatory for any network above five chargers, and worth running below that. Moving a small batch first finds the problems that only appear on your hardware, in your configuration, and settles the process before it runs at volume. The cut-over itself is a handshake between something you created and something your installer configures: Carry what you learn into the plan. A configuration value that needed adjusting on one model needs it on every unit of that model.

​

3. Migration

Move the rest in batches, each running the same sequence as the test. A week of validation per batch is the standard pace, and you can compress it, or run fewer and larger batches, according to how much risk you’re willing to carry. Group batches by hardware model. Units of one model behave the same way through the cut-over, so a configuration adjustment found on the first unit applies across the batch, and the charge boxes come online with the same connector layout beneath them. Grouping by site instead splits a model across windows and repeats the same discovery each time. Chargers needing a technician on site are their own batch, scheduled around site access rather than around the remote work. A cut-over draws a clean line through the session record. Sessions that started before it finish on your previous platform and their records stay there; every session after it belongs to Spirii and produces a charge detail record in Connect. There is no partial session split across the two platforms.

​

Migrating tokens

Tokens migrate in the same window as the chargers, and after them, so there are working chargers to authorise against. An RFID token’s UID is physical and doesn’t change, so the same card keeps working — you re-register it in Spirii rather than reissuing it to the driver. Create the tokens in Spirii first, then deactivate them at your previous provider. A token live in both platforms can behave unpredictably, since which system authorises it depends on the charger it’s presented to. Each token needs a billing customer, a type, its UID, and a label. Carry your existing labels across, or set new ones in Connect. Tokens that authorise on roaming networks need the label format described in Token authentication, which also covers issuing and managing them. Bulk upload in Connect takes a CSV of up to 100 tokens per upload, so a larger fleet is either several uploads or a run through the tokens API.

​

4. Post-migration

Migrated chargers need watching against real traffic. Verify each of these once drivers are using the network:

• Connect — sessions and charge detail records landing, with correct consumption and pricing
• Driver apps — the location visible, with the right details, in Spirii Go or your branded app
• Tokens — RFID and virtual tokens authorising as expected
• Roaming — inbound sessions from external networks arriving and settling
• Payment terminals — transactions capturing rather than only pre-authorising
• Support — your own support line reaching the right people for a migrated site
• Charger screens — branding and on-screen content correct

Physical work runs alongside this phase: replacing the EVSE ID labels where your prefix changed, and updating branding on charger screens. Neither blocks a migration test, and both belong on the list before a site is fully live. Screen graphics come from you; Spirii applies them after migration. The phase closes when two billing runs have been validated. That’s the real proof: sessions priced correctly, the payout matching your own figures, and exclusions explained. See Understanding your payout for reconciling the invoice against the specification file.

​

Next steps