Migreren nieuwe API schermen bij Tante Co

Binnen Tante Co ben ik de afgelopen periode bezig geweest met het migreren van de API die wordt gebruikt door de fysieke schermen. Dat klinkt als een vrij technische wijziging, maar in de praktijk was dit een traject met veel randvoorwaarden en weinig ruimte voor fouten. De schermen staan namelijk live in het veld en worden dagelijks gebruikt binnen zorginstellingen door heel Nederland.

Een live systeem dat niet uit mag vallen

De bestaande API werd actief gebruikt door zo’n 70 schermen, verspreid over ongeveer 50 organisaties. Deze schermen staan op locatie en zijn niet zomaar fysiek bereikbaar voor ons team. Even “langsgaan”, handmatig ingrijpen of iedere organisatie persoonlijk begeleiden was dus geen optie. Tegelijkertijd moest het systeem beschikbaar blijven: het platform is de core business van Tante Co, downtime is simpelweg geen optie!

Dat betekende dat elke stap in de migratie zorgvuldig gepland moest worden, met continuïteit als hoogste prioriteit.

Altijd kunnen terugvallen

Een belangrijk uitgangspunt was dat we op elk moment terug moesten kunnen naar de oude API. Bij fouten met de migratie gaan de schermen weer automatisch terug naar de oude versie, waar het platform dan ook op voorbereid moet zijn. Dit is niet alleen een theoretisch scenario, de leverancier kon niet uitsluiten dat een fout zich voor zou doen. Hiervoor heb ik uitgebreide fallback-mechanismen en meetmomenten ingebouwd.

De migratie van de schermen werd pas doorgevoerd nadat duidelijk was dat de nieuwe API stabiel draaide en de schermen correct bleven functioneren.

Bij afwijkingen kon er direct worden teruggeschakeld, zonder dat eindgebruikers hier iets van merkten.

Een API diep in de core

Wat deze migratie extra uitdagend maakte, is dat de API diep verweven zit in de core van het platform van Tante Co. Het is geen los component dat je even vervangt; veel processen leunen direct op de bestaande structuur en aannames.

Daarom was een big-bang-migratie (in één klap over) geen optie. In plaats daarvan heb ik gekozen voor een aanpak waarbij de oude en nieuwe API’s tijdelijk naast elkaar konden bestaan.

Side-by-side ontwikkelen

In de ontwikkelfase moesten beide API’s side-by-side kunnen werken, zonder elkaar in de weg te zitten. Dit vereiste duidelijke scheiding in codebase met expliciete versies.

Door deze opzet konden:

• schermen en functionaliteit getest worden op nieuwe API,
• bestaande schermen blijven draaien op de oude,
• en kon er gecontroleerd gemigreerd worden.

Dit gaf ruimte om te testen onder realistische omstandigheden, zonder direct risico te lopen voor het bestaande gebruik.

Resultaat

De migratie is stap voor stap uitgevoerd, met minimale impact op de eindgebruikers. Het systeem bleef operationeel, fallback-scenario’s bleven beschikbaar en zijn gelukkig niet nodig geweest. Verder heb ik een solide basis gelegd voor verdere doorontwikkeling.

Voor schermen die tijdens de migratie niet online waren heb ik een FAQ-document opgesteld die helpt met het handmatig migreren. Deze stappen kunnen niet op afstand worden gedaan en moeten telefonisch met een medewerker van de locatie worden uitgevoerd. Gelukkig lijkt dit om slechts een zeer beperkt aantal schermen te gaan.

Voor mij was dit een typisch voorbeeld van werken aan een live product: niet de “mooiste” technische oplossing staat voorop, maar een oplossing die betrouwbaar is, schaalbaar blijft en rekening houdt met de realiteit van het veld. Precies het soort werk waar Tante Co voor mij interessant wordt.