De wielen vervangen terwijl de auto blijft rijden: terugblik op mijn migratie van Oracle naar Snowflake

Bij VodafoneZiggo werkte ik aan een grote migratie van Oracle naar Snowflake. Het Oracle-contract liep af en het programma had daardoor een harde deadline. Tegelijk speelde het systeem een kritieke rol in de bedrijfsvoering. Alle ontwikkeling stilleggen zou grote commerciële schade hebben veroorzaakt. Sommige urgente functionaliteit en bugfixes moesten tijdens de migratie in de database blijven binnenkomen.

Het voelde als de wielen vervangen terwijl de auto bleef rijden.

Ik werd halverwege de migratie aan het project toegevoegd, toen de planning al op rood stond. De einddatum van het Oracle-contract was meerdere keren uitgesteld en het bedrijf had besloten dat verder uitstel geen optie meer was.

Mijn opdracht was om mijn ervaring met data, infrastructuur, Python en CI/CD-automatisering in te zetten om de migratie te versnellen.

Het directe pijnpunt: één migratie-eenheid kostte dagen

Het Oracle-platform draaide op AWS en bevatte honderden terabytes aan data. De fysieke infrastructuur en de logische databases werden afzonderlijk beheerd. Het programma verdeelde het platform in tientallen logische database-eenheden en migreerde die release voor release.

Voor iedere eenheid moesten drie migratiesporen tegelijk worden uitgevoerd:

• DDL moest worden geconverteerd en in Snowflake toegepast;
• bestaande en nieuwe data moesten vanuit Oracle worden gekopieerd;
• Informatica PowerCenter-workflows moesten van Oracle naar Snowflake worden aangepast.

Veel stappen waren handmatig. Engineers voerden Snowflake-DDL zelf uit. PowerCenter-XML werd handmatig geëxporteerd, gewijzigd, geconverteerd en geïmporteerd. Een migratierelease duurde meerdere dagen en soms bijna een week.

Ondertussen bleven minstens 40 PowerCenter-developers nieuwe functionaliteit en bugfixes opleveren. Tegen de tijd dat een migratie klaar was, kon de gebruikte bronbaseline al achterhaald zijn. Een mislukte release was nog lastiger: het team moest reconstrueren welke SQL was uitgevoerd, welke XML actueel was en naar welke workflowversie veilig kon worden teruggekeerd.

De oorzaak: het migratiepad was niet volledig geautomatiseerd

De lange doorlooptijd veroorzaakte één vorm van drift. Productie bleef tijdens iedere meerdaagse migratie veranderen.

Handmatige uitvoering veroorzaakte een tweede vorm. Mensen konden vanuit verschillende versies werken en een gedeeltelijk geslaagde run kon Git, Oracle, Snowflake en de PowerCenter-server in verschillende toestanden achterlaten.

De drie migratievlakken hadden ook geen gezamenlijke, herhaalbare releasegrens. Een geslaagde DDL-deployment betekende niet dat de data was bijgewerkt. Gesynchroniseerde data betekende niet dat de PowerCenter-interfaces klaar waren voor omschakeling.

Ook was veel kennis geconcentreerd in het handmatige proces. De meest ervaren PowerCenter-specialist kende de conversieregels en uitzonderingen en had enkele Python-scripts geschreven, maar export, vergelijking, conversie, import, foutafhandeling en versiebeheer vormden nog geen volledig pad.

De aanpak: automatiseer de volledige migratierelease

In mijn eerste week leverde ik de eerste automatiserings-MVP en pilot op. Na beoordeling door de Architecture Board nam het team deze aanpak over en breidde die tijdens het hersteltraject van vier maanden verder uit.

Maak van DDL-migratie een CI/CD-release

Het project had al een eerste DDL-migratiemechanisme, maar engineers voerden de SQL nog grotendeels handmatig uit. Ik verbeterde dit mechanisme en bracht het onder in GitLab CI/CD.

Bij de initialisatie werd Oracle-DDL geëxporteerd, geparsed, gecontroleerd en naar Snowflake-syntax geconverteerd. Latere releases pasten de wijzigingen toe die voor de volgende logische database-eenheid nodig waren.

Voor uitvoering controleerde de pipeline of objecten al bestonden en vergeleek zij het verwachte met het werkelijke schema. Onverklaarbare verschillen leidden direct tot een fout. Releases waren idempotent, zodat een mislukte run na herstel opnieuw kon worden uitgevoerd zonder handmatige notities over eerder geslaagde statements.

De Python-orchestratie verzorgde versiegebonden DDL-conversie, uitvoeringscontrole en deployment. Het project gebruikte destijds geen dbt; het systeem dekte een deel van het databasewijzigingsbeheer dat teams tegenwoordig met moderne transformatietooling associëren.

Integreer DMS in de release

Het team koos AWS DMS voor Full Load en doorlopende CDC. Dit was een gezamenlijke architectuurbeslissing. Als een van de twee AWS-systeembeheerders hielp ik de DMS-integratie te implementeren, de taken te configureren en beheren, en de controles in CI/CD op te nemen.

Iedere logische migratie-eenheid had een DMS-taak. De initiële load duurde meestal vier tot acht uur en gebruikte een DMS-replicatie-instance met hoge capaciteit. Daarna bleef CDC de Oracle-wijzigingen toepassen terwijl de overige releasestappen werden voorbereid.

DMS CDC werkt asynchroon. Voor de omschakeling bleven controles op taakstatus, vertraging en datareconciliatie noodzakelijk.

Eén keer ontwikkelen, PowerCenter automatisch aanpassen

We konden de PowerCenter-ontwikkeling niet voor de duur van het programma stilzetten. Twee workflows handmatig onderhouden zou het werk en de drift verder vergroten.

Developers bleven daarom de Oracle-versie onderhouden. Samen met de PowerCenter-specialist bracht ik de conversieregels en uitzonderingen onder in een standaard GitLab-pipeline.

Na activering door een developer deed de pipeline globaal het volgende:

1. de nieuwste XML van de PowerCenter-server exporteren;
2. deze met de versie in Git vergelijken;
3. stoppen zodra drift werd gevonden;
4. de workflow voor Snowflake converteren;
5. het resultaat valideren en importeren;
6. de releasestatus in Git vastleggen.

De export vlak voor de conversie voorkwam dat een oudere Git-versie een nieuwere productiewijziging overschreef. Dit werd het standaard migratiepad voor PowerCenter.

Schakel alle drie de vlakken via één gate om

Door automatisering duurden de belangrijkste stappen buiten de dataload nog enkele uren. Met een initiële load van vier tot acht uur en CDC die Snowflake dicht bij Oracle hield, kon één logische database-eenheid binnen een dag over alle vlakken worden gemigreerd.

Daardoor werd het haalbaar om wijzigingen voor die eenheid tijdens het migratievenster te bevriezen. Een release mocht alleen omschakelen nadat:

• DDL-conversie en schemavergelijking waren geslaagd;
• DMS Full Load en CDC de vereiste status hadden bereikt;
• de controle van kritieke data was geslaagd;
• PowerCenter geen onopgeloste drift meer bevatte;
• de geconverteerde workflows succesvol waren geïmporteerd;
• de business het resultaat had geaccepteerd.

Een mislukte gate stopte de omschakeling.

Tijdens de stabilisatie bleven Oracle, de oorspronkelijke PowerCenter-workflows en DMS CDC beschikbaar. Bij een mislukte cutover kon PowerCenter terug naar de vorige release en kon de interface weer naar het oorspronkelijke pad wijzen. Na herstel voerde het team de idempotente release voor data, DDL en ETL opnieuw uit.

Het resultaat: van meerdere dagen naar minder dan één

De doorlooptijd van de migratierelease voor één logische database-eenheid daalde van meerdere dagen—soms bijna een week—naar minder dan één dag. Het kortere venster maakte een gecontroleerde wijzigingsstop mogelijk en verminderde sterk de tijd waarin productiedrift zich kon opstapelen.

PowerCenter-developers kregen feedback binnen minuten in plaats van uren of dagen. Op basis van minstens 40 developers die ieder ongeveer één tot twee uur per week bespaarden, plus minder handwerk voor de PowerCenter-specialist, schat ik voorzichtig dat de automatisering minstens 40 uur handwerk per week wegnam. Dit is een inschatting op basis van deelname en eerdere verwerkingstijd, geen formele urenmeting.

Het programma was klaar voordat het Oracle-contract afliep.

Dat resultaat behoorde toe aan het hele team: de projectmanager, AWS-systeembeheerders, PowerCenter-specialist, het externe Snowflake-beheerteam, businessgebruikers en de developers die productie draaiende hielden.

Mijn bijdrage was het bestaande DDL-migratiemechanisme verbeteren tot een idempotente CI/CD-release, de handmatige PowerCenter-conversie omvormen tot een standaardpad met driftdetectie, en het DMS-werk integreren in dezelfde beheerste migratierelease.

Mijn belangrijkste les is eenvoudig: automatisering verandert het migratievenster. Zodra een release kort genoeg is, kunnen productiewijzigingen voor die begrensde periode worden bevroren en kunnen data, DDL en ETL samen omschakelen, met bekende gates en een bekende weg terug.