Migreren zonder big bang

Een oude applicatie in één keer vervangen klinkt overzichtelijk en gaat bijna altijd mis. Gefaseerd migreren is trager op papier en sneller in de praktijk.

  • Migratie
  • Architectuur
  • .NET

Waarom de big bang vastloopt

Bij een volledige herbouw ligt de roadmap stil zolang het duurt. Ondertussen blijft de oude applicatie in gebruik en dus veranderen. Elke wijziging daar moet twee keer gemaakt worden, en de datum schuift op.

Daar komt bij dat de kennis over de oude applicatie meestal impliciet is. Pas als een gebruiker iets mist, blijkt dat er een regel bestond die nergens stond opgeschreven.

De strangler-aanpak

Zet een reverse proxy voor de oude applicatie en verplaats functionaliteit module voor module naar de nieuwe stack. Elke module die klaar is, gaat live; de rest blijft gewoon draaien.

Belangrijk daarbij: schrijf eerst karakteriseringstests op de flow die je verplaatst. Die tests beschrijven wat het systeem nu doet — inclusief het gedrag dat niemand meer kan uitleggen — en dat is precies wat je wilt behouden.

Wat je onderweg meeneemt

  • Automatiseer de deploy voordat je begint; handmatig uitrollen wordt bij twee systemen onhoudbaar.
  • Neem databasemigraties op in de pipeline, met een uitgewerkte rollback.
  • Houd één bron van waarheid voor authenticatie, zodat gebruikers niet twee keer inloggen.
  • Meet vanaf dag één: zonder cijfers is niet aantoonbaar dat de nieuwe module beter is.

Speelt dit bij jou ook?

Mail de vraag. Je krijgt antwoord van degene die het artikel schreef.

Er is een onverwachte fout opgetreden. Herladen 🗙