Een CMS-migratie wordt zelden geblokkeerd door het protocol. Het wordt geblokkeerd door dingen die niemand vóór aanvang heeft vastgesteld: of opladers überhaupt opnieuw kunnen worden aangesloten, of historische gegevens kunnen worden verplaatst en wat er met bestuurders gebeurt tijdens de overgang.
Door deze drie eerst tot stand te brengen, verandert een riskant project in een volgorde-oefening.
Controleer of de opladers daadwerkelijk opnieuw kunnen worden aangesloten
Het backend-adres is een configuratiewaarde, en of u dit zelf op afstand kunt wijzigen, zonder medewerking van de gevestigde leverancier, is de vraag die bepaalt of migratie überhaupt mogelijk is.
Waar de gevestigde exploitant die waarde controleert, wordt de migratie een commerciële onderhandeling voordat het een technisch project wordt. Dit laat ontdekken is de meest voorkomende reden dat migraties vastlopen.
Test één lader voordat u het wagenpark plant
Sluit een enkele eenheid aan op het nieuwe platform en voer de volledige compatibiliteitsset uit: opstarten, transacties, meterwaarden, externe opdrachten, firmwarebeheer en onderbroken gevallen. Elk verschil dat u hier aantreft, is er een die u anders in de hele vloot in één keer zou aantreffen.
Doe dit op dezelfde firmwareversie waarop de vloot daadwerkelijk draait, niet de nieuwste, want die zal migreren.
Bepaal wat er met de geschiedenis gebeurt
De geschiedenis verloopt doorgaans niet netjes. Het plannen van een archief met gedefinieerde toegang is realistischer dan uitgaan van een schone import, en het is veel beter dan het gat ontdekken tijdens een factureringsgeschil.
- Of historische sessiegegevens van de zittende partij kunnen worden geëxporteerd, en in welk formaat.
- Of het nieuwe platform het kan verwerken, of dat de geschiedenis achterblijft in een archief.
- Hoe lang u na de overstap toegang behoudt tot het oude platform voor geschillenbeslechting.
- Of chauffeursaccounts, RFID-inloggegevens en tarieven worden overgedragen of opnieuw worden gemaakt.
Migreer in golven, niet in één keer
Verplaats eerst een kleine groep, idealiter naar een locatie waar u de toegang beheert en verstoringen kunt tolereren. Gebruik het lang genoeg op het nieuwe platform om intervalgerelateerde problemen te laten optreden, wat meestal ten minste een volledige factureringscyclus betekent.
Beweeg vervolgens in golven die zo groot zijn dat een probleem een beheersbaar deel van de vloot treft, met een gedefinieerde terugdraaiing voor elke golf.
Chauffeurs zijn het deel dat te zien is
De stilstand van de lader tijdens het omschakelen is kort. Er is geen sprake van verstoring van chauffeurs als hun accounts, kaarten of app niet meer werken. Dat is wat klachten genereert, en het is eerder een communicatie- en identiteitsprobleem dan een protocolprobleem.
Stel vroegtijdig vast of bestaande inloggegevens blijven werken, en als dat niet het geval is, plan dan de transitie voor stuurprogramma's afzonderlijk en vóór de hardware.
Houd beide paden in leven tijdens de periode
Waar een routeringslaag zich tussen opladers en backends bevindt, wordt migratie een configuratiewijziging per oplader en is het terugdraaien onmiddellijk mogelijk. Zonder één is het opnieuw richten een wijziging van de firmwareconfiguratie op elke eenheid en is terugdraaien weer hetzelfde werk.
Dit is het sterkste praktische argument voor een routeringslaag, en het is de moeite waard om dit vóór een migratie te overwegen in plaats van nadat er sprake is van schade.
Wat ziet er goed uit bij een cutover
- Een geteste compatibiliteitspositie op de daadwerkelijke firmwareversie.
- Een golfplan met rollback gedefinieerd per golf.
- Een overeengekomen antwoord over historische gegevens en archieftoegang.
- Inloggegevens van stuurprogramma's worden vóór de hardware afgehandeld.
- Monitoring op het nieuwe platform vóór de eerste golf, niet erna.