nov 25 2012 Hoe u zonder risico gegevens uit oude naar nieuwe bedrijfssoftware kunt overzetten

Stapsgewijze migratie

Mijn advies: verdeel de migratie in kleine, overzichtelijke stappen waarbij u van de ene volledig bruikbare en werkende situatie overgaat naar een nieuwe volledig bruikbare en werkende situatie. De sleutel hierbij is om alle gegevens stap voor stap te migreren en door synchronisaties tussen het oude en het nieuwe systeem te zorgen dat functionaliteiten van het oude systeem volledig beschikbaar blijven zolang dezelfde functionaliteiten in het nieuwe systeem nog niet volledig werken.

Voordelen van deze aanpak

Uw medewerkers zullen bij deze methode een tijd in beide pakketten moeten werken en daardoor lijkt het migratietraject wellicht langer. Deze manier van werken heeft echter de volgende voordelen:

• Uw medewerkers maken bijna direct kennis met het nieuwe pakket: zodra de eerste gegevens gemigreerd zijn, kunnen ze al ervaring opdoen met het nieuwe pakket. Ze leren al doende alle functionaliteit van het nieuwe pakket kennen.
• Zodra medewerkers in het nieuwe pakket gaan werken, merken ze vanzelf of de gegevens wel correct en volledig zijn overgezet. Omdat de hoeveelheid data per migratiestap beperkt is, zijn eventuele fouten die tijdens een migratiestap zijn opgetreden relatief eenvoudig en snel te corrigeren. Dit geeft uw medewerkers vertrouwen in het migratieproces, omdat ze zien dat problemen met data snel opgelost worden.
• Het migratieproces start met de eenvoudigste data, die geen afhankelijkheden van andere gegevens hebben. Door deze data in een vroeg stadium te controleren, kunt u kostbare correcties bij de migratie van complexere gegevens in een later stadium voorkomen.

Een voorbeeld

Als voorbeeld neem ik een fictief systeem A, het bestaande systeem, dat gegevens van klanten, producten en prijslijsten bevat. Het fictieve nieuwe bedrijfssysteem noem ik systeem B. Alle gegevens op systeem A moeten naar systeem B worden overgeheveld en het oude pakket moet worden uitgefaseerd.

Afhankelijkheden

Bij de migratie van de gegevens moet ik rekening houden met de onderlinge afhankelijkheden van de gegevens. Voor prijslijsten met staffelprijzen van producten zijn details van deze producten nodig. Voor prijslijsten met klantspecifieke prijzen is ook klantinformatie nodig. Dus voor ik de prijslijsten kan migreren, moet ik zowel de gegevens over klanten als die over producten gemigreerd hebben.

Uitgangssituatie

In de afbeelding heb ik schematisch weergegeven hoe ik de migratie bij dit voorbeeld stapsgewijs zou aanpakken. Bij stap 1 staat de uitgangssituatie: het oude systeem A is nog volledig in gebruik en het nieuwe systeem B is, hoewel operationeel, volledig ongebruikt. Vervolgens kies ik een set gegevens om naar het nieuwe systeem te migreren. In dit voorbeeld kies ik voor de klantgegevens.

Pre-migratie

In stap 2 start ik een periodieke synchronisatie van de klantgegevens vanuit systeem A naar systeem B. Deze synchronisatie start ik in eerste instantie handmatig en laat ik daarna automatisch om de 10 minuten herhalen. (Dit kan uiteraard ook met een andere frequentie.) Om aan te geven dat de gegevens in systeem B op dit punt van de migratie nog onvolledig kunnen zijn, is dit blok rood gekleurd in de afbeelding voor stap 2.

Medewerkers kunnen gewoon in systeem A blijven werken en ondertussen kan een hoofdgebruiker controleren of de synchronisatie van de gegevens volledig is gelukt. Natuurlijk moeten ook het toevoegen van nieuwe klanten en het deactiveren van oude klanten nog steeds correct functioneren.

Migratie

Als alle gegevens correct in het nieuwe systeem, systeem B, overgenomen worden, is het tijd voor stap 3. In deze stap zorg ik dat nieuwe gegevens die in systeem B worden ingevoerd, voortaan ook naar systeem A worden gesynchroniseerd. Zodra dit werkt, wordt het nieuwe systeem dus leidend voor klantgegevens. Bij twijfel krijgen wijzigingen in systeem B voorrang op wijzigingen in systeem A.

Medewerkers moeten klantgegevens kunnen wijzigingen in systeem B. Om onbedoeld gegevensverlies te vermijden, zet de beheerder de gebruikersrechten voor klantgegevens in systeem A op 'alleen-lezen'. De klantgegevens zijn zo nog steeds beschikbaar voor andere functies van systeem A, maar medewerkers kunnen ze daar niet meer wijzigen.

Na de eerste migratie

In stap 4 worden de klantgegevens alleen nog van het nieuwe naar het oude systeem gesynchroniseerd. Niemand kan de klantgegevens in systeem A nog aanpassen, omdat deze op alleen-lezen staan. Alle wijzigingen moeten nu dus direct in systeem B worden ingevoerd.

Dit kan als nadeel hebben dat de gegevens die in systeem B worden ingevoerd, niet direct beschikbaar zijn in systeem A. Ze moeten namelijk eerst gesynchroniseerd worden. Dit probleem kan ik verzachten door de synchronisatie in tweeën te splitsen in een snelle synchronisatie van alle nieuw toegevoegde gegevens en een langzame synchronisatie van alle gewijzigde gegevens. De snelle synchronisatie kan, bijvoorbeeld, elke minuut starten terwijl de langzame maar eens in het uur wordt uitgevoerd.

Nu de klantgegevens in het nieuwe systeem B zitten, kunnen de medewerkers mogelijk ook al functionaliteit in systeem B gebruiken die in systeem A niet beschikbaar was, zoals de registratie van telefoongesprekken of kansen bij klanten. Op deze manier zien medewerkers sneller welke mogelijkheden en voordelen het nieuwe systeem heeft.

Verder met de volgende migratiefase

Na stap 4 ben ik weer uitgekomen bij stap 1: de nieuwe uitgangssituatie. Dit is het moment om een nieuwe set gegevens te kiezen om te migreren. In het gekozen voorbeeld zijn de productgegevens nu aan de beurt. Voor deze gegevens doorloop ik dezelfde stappen als voor de klantgegevens en aan het einde van deze cyclus werken de medewerkers met zowel de klant- als de productgegevens in het nieuwe systeem.

Afronding

Deze cyclus moet een aantal keer worden herhaald om de volledige functionaliteit van systeem A naar systeem B over te hevelen. Als dat is afgerond kan de beheerder alle synchronisaties uitschakelen en vervolgens systeem A archiveren.

Valkuilen

Of deze methode ook voor uw systeem werkt, is afhankelijk van de technische mogelijkheden van zowel het oude als het nieuwe systeem.

Het succes van deze methode hangt er ten eerste van af hoe makkelijk of moeilijk het is om de gegevens uit uw oude systeem te halen en te veranderen. Gelukkig maken bedrijfstoepassingen tegenwoordig vaak gebruik van standaard databases die via standaard koppelingen te benaderen en te veranderen zijn. Migreren vanuit een toepassing met een eigen databaseformaat is aanzienlijk lastiger.

Een ander aandachtspunt is of er in het nieuwe systeem meer velden verplicht gevuld moeten zijn. Als dat het geval is, moet de projectleider bij het inrichten van de synchronisatie zinnige standaardwaardes voor het nieuwe systeem ingeven.

Een derde mogelijke valkuil is dat gegevens die in het oude systeem in één tabel staan, in het nieuwe systeem soms in verschillende tabellen terecht moeten komen. Om contactgegevens als voorbeeld te nemen: stel dat u in het oude systeem maar één afleveradres en één factuuradres per klant kon opnemen en dat het nieuwe systeem de adresgegevens in een aparte tabel opslaat, waarin een onbeperkte hoeveelheid afleveradressen en factuuradressen aan een klant kan worden gekoppeld. Dan moet het synchronisatie-script daarop zijn aangepast.

Conclusie

Ik heb laten zien dat het mogelijk is om een systeem in een beperkt aantal stappen te migreren zonder ergens risico te lopen op een niet-functionerend systeem. Dit proces is echter niet zonder haken en ogen en daarom is elke migratie maatwerk. Win dus altijd vakkundig advies in voor u een migratietraject start.