Een draaiend legacysysteem migreren: eigenaarschap, omschakelen en terugvallen

Kies een overgangsgrens die medewerkers begrijpen

Een fase moet herkenbaar zijn in het dagelijkse werk. Kies bijvoorbeeld nieuwe serviceaanvragen vanaf een afgesproken moment, één klantgroep of een afgebakend procesonderdeel. Beoordeel of medewerkers bij die grens kunnen bepalen welk systeem zij gebruiken. Een technische modulegrens kan ongeschikt zijn wanneer één handeling voortdurend tussen oud en nieuw moet wisselen.

Beschrijf ook de uitzonderingen die nog in de oude applicatie blijven. Wie behandelt een wijziging aan een aanvraag van vóór de overgang? Hoe wordt een nieuwe gebruiker geïnstrueerd? Een bestaande geschiedenis als leesarchief aanbieden is iets anders dan twee actieve processen naast elkaar onderhouden. De grens moet duidelijk maken welke verantwoordelijkheid in deze fase werkelijk verhuist en welke oude werkwijze daarna kan worden afgebouwd.

Leg de normale werkroute en openstaande gevallen vast

Beschrijf welke toestanden tijdens een werkdag kunnen voorkomen: ontvangen, beoordeeld, in uitvoering en afgehandeld, met de eigen betekenis van het proces. Noteer waar openstaande gevallen zich bevinden wanneer de omschakeling begint. Een aanvraag die al naar een medewerker is doorgestuurd kan niet worden behandeld alsof zij nog niet is bekeken.

Gebruik deze uitgangssituatie om te bepalen welke overgangscontroles nodig zijn. Kan iedere medewerker zijn open werk terugvinden? Blijven afspraken met klanten herkenbaar? Welke controle gebeurt tijdelijk handmatig? Het valideren van de voorbereidende gegevensimport hoort bij het importtraject. De operationele proef onderzoekt vervolgens of mensen met die gegevens hun werk op het afgesproken moment kunnen voortzetten, inclusief taken die al onderweg waren.

Wijs per handeling één schrijfverantwoordelijkheid aan

Leg vast welk systeem nieuwe aanvragen, correcties en statuswijzigingen mag aannemen. Dat hoeft niet voor ieder gegeven hetzelfde systeem te zijn, maar iedere verantwoordelijkheid moet benoemd en technisch uitgevoerd kunnen worden. Twee schermen met dezelfde informatie geven medewerkers anders gemakkelijk de indruk dat zij beide mogen gebruiken.

Werk een gelijktijdige wijziging uit. Een planner past een afspraak aan terwijl een oude achtergrondtaak nog een eerdere status doorstuurt. Welke wijziging geldt en hoe wordt de andere verwerking tegengehouden of beoordeeld? Benoem ook wie een conflict mag oplossen. Een tijdelijke periode waarin twee systemen schrijven vraagt meer dan de belofte dat gegevens later wel gelijkgetrokken worden. Als de broninformatie onvoldoende onderscheid biedt, kan een strakkere overgangsgrens nodig zijn.

Werk de gegevensvergelijking, uitzonderingen en zakelijke controle ook afzonderlijk uit: Gegevens importeren in nieuwe software: van exportbestand naar beoordeelde dossiers.

Maak tijdelijk samenleven tot een expliciet ontwerp

Beschrijf welke informatie de systemen tijdens de overgang uitwisselen, in welke richting en met welke betekenis. Beperk de tijdelijke aansluiting tot de verantwoordelijkheden die de fase nodig heeft. Een nieuwe applicatie die iedere oude uitzondering overneemt kan haar beoogde ontwerpvoordeel verliezen voordat de eerste fase is afgerond.

Een vertaalgrens kan verschillende systeemmodellen scheiden, zoals beschreven in het anti-corruption-layer-patroon. Dat neemt afspraken over werking en eigenaarschap niet over. Laat een normale overdracht, een geweigerd bericht en een onzekere uitkomst zien. Noteer wie de tijdelijke aansluiting beheert en op welk moment zij kan verdwijnen. Zonder een afbouwcriterium kan tijdelijk dubbel beheer stilzwijgend de permanente werkwijze worden.

Microsoft Azure Architecture: Anti-Corruption Layer ↗

Spreek af wat er met lopende wijzigingen gebeurt

Kies bewust tussen een afgesproken invoerpauze, het later verwerken van veranderingen of een andere gecontroleerde overgang. De keuze hangt af van beschikbare broninformatie en de werkruimte van de organisatie. Veronderstel niet dat iedere oude applicatie een compleet wijzigingslogboek biedt. Onderzoek bijvoorbeeld hoe verwijderingen en correcties zichtbaar worden.

Leg het overgangsmoment vast in zakelijke termen. Vanaf wanneer maakt een medewerker een nieuwe aanvraag in het nieuwe systeem? Waar worden wijzigingen aan een oude aanvraag gedaan? Een technische kloktijd alleen beantwoordt die vragen niet. Maak ook duidelijk hoe een te laat ontvangen bestand of bericht wordt behandeld. Anders kan de migratie correct lijken terwijl na de overgang toch een wijziging ontbreekt.

Oefen een werkdag rond het omschakelmoment

Een overgangsproef moet niet alleen laten zien dat een nieuw record kan worden geopend. Gebruik ook werk dat vóór de omschakeling is gestart, een wijziging op het grensmoment en een late melding uit het oude systeem. Spreek af welke handelingen alleen worden gesimuleerd en welke in een afgesproken proefomgeving werkelijk worden uitgevoerd.

Laat medewerkers uitleggen waar zij verdergaan en hoe zij onzekerheid herkennen. Een nieuwe aanvraag kan bijvoorbeeld in het nieuwe systeem horen, terwijl een correctie op een oude aanvraag nog een expliciete oude route gebruikt. De proef onderzoekt of die grens uitvoerbaar is. Als veel gevallen handmatige uitleg blijven vragen, moet de fasegrens of instructie worden aangepast voordat een bredere groep gebruikers overstapt.

Controleer lopende verwerking aan beide kanten

Controleer tijdens de overgang of de verwachte zakelijke gebeurtenissen zijn verwerkt. Een gelijke totale recordtelling kan verbergen dat twee gevallen ontbreken en twee andere dubbel voorkomen. Maak daarom een verschiloverzicht dat een aanvraag of opdracht langs de betrokken systemen kan volgen, met herkenbare referenties en verwerkingstoestanden.

Spreek af hoe vaak iemand de verschillen beoordeelt en wanneer verdere omschakeling wordt gepauzeerd. Een onverklaarde achterstand kan een tijdelijke technische storing zijn, maar ook een verkeerde verantwoordelijkheidsgrens tonen. Behandel het overzicht als werkvoorraad met een eigenaar. Bewaar ook hoe een verschil is opgelost, zodat dezelfde late melding niet telkens opnieuw tot onderzoek of dubbele verwerking leidt.

Maak ingebruikname een expliciet besluit

Spreek vooraf af welke controles geslaagd moeten zijn, welke beperkingen tijdelijk acceptabel zijn en wie toestemming geeft om over te gaan. Een technisch team kan niet zelfstandig bepalen dat ontbrekende historische gegevens zakelijk onbelangrijk zijn. Betrek daarom de eigenaar van de betreffende werkroute.

Neem ook bereikbaarheid van mensen mee. Een migratie op een rustig moment helpt weinig wanneer niemand een onverklaarde afwijking kan beoordelen. Zorg dat instructies voor medewerkers, beheer en eventuele leveranciers dezelfde overgang beschrijven. Als een belangrijk criterium niet is gehaald, moet een uitstel of beperktere eerste stap mogelijk zijn. Dat besluit hoort bij het plan, niet pas bij de stress van de omschakeling.

Definieer een terugval na nieuwe invoer

Terugvallen is eenvoudig te zeggen zolang alleen een kopie is gemaakt. Nadat medewerkers nieuwe aanvragen, correcties of berichten hebben verwerkt, moet ook die activiteit een plek krijgen. Een oude database terugzetten kan nieuwe informatie laten verdwijnen. Beschrijf daarom op welke momenten terugkeer nog eenvoudig is en vanaf wanneer extra reconciliatie nodig wordt.

Een herstelplan kan een tijdelijke handmatige registratie of een afzonderlijke export van nieuwe wijzigingen bevatten. Welke route geschikt is moet vóór de overgang worden onderzocht en geoefend met voorbeeldgevallen. Spreek geen gegarandeerde hersteltijd af op basis van alleen een document. Laat zien welke handelingen al zijn uitgevoerd en welke afhankelijkheden nog onzeker zijn.

Google SRE: Testing for Reliability ↗

Voorbeeld: een aanvraagroute gefaseerd overzetten

Fictief voorbeeld: een onderhoudsbedrijf laat nieuwe serviceaanvragen vanaf maandag in een nieuw portaal binnenkomen. Lopende opdrachten blijven voorlopig in de bestaande planning. De tijdelijke aansluiting geeft goedgekeurde nieuwe aanvragen door aan de planning, maar laat het portaal niet zelfstandig afspraken overschrijven. Een late wijziging uit de planning blijft herkenbaar als een aparte gebeurtenis.

Tijdens de proef wordt een aanvraag gewijzigd terwijl zij wordt overgedragen. Het team ontdekt dat de oorspronkelijke route een oude bevestiging opnieuw kan versturen. Het past de grens en controle aan voordat meer gebruikers overstappen. Het fasebesluit berust daarna op een werkende overdracht, verklaarde verschillen en een afgesproken vervolg voor openstaande opdrachten. Dat is ander bewijs dan alleen een geslaagde gegevensimport.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• Legacy Software Moderniseren ↗
• Software Audit ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag