De eerste soort schreeuwt: de compiler weigert, een commando bestaat niet meer, een plugin laadt niet. Vervelend, maar u weet meteen waar u staat. Dit werk is te tellen en te budgetteren.

De tweede soort meldt zich tijdens het testen: een venster dat er anders uitziet, een lijst die niet meer sorteert zoals vroeger, een import die halverwege stopt. Ook dit vindt u, zolang u effectief test.

De derde soort geeft geen enkele foutmelding. De toepassing draait, uw mensen werken door, en pas weken later merkt iemand dat een totaal niet klopt. Dat is de soort waar migraties hun reputatie aan te danken hebben.

1. Getal- en datumnotatie

Notatie hangt af van meer dan uw code alleen: van de instellingen van de machine, van de regionale instellingen van de gebruiker, en van de manier waarop uw versie van 4D die interpreteert. Verandert een van die drie, dan verandert de uitkomst — zonder dat er technisch iets misgaat.

Waar het pijn doet: bedragen die als tekst worden opgebouwd voor een factuur, datums die als string naar een extern systeem vertrekken, getallen die uit een importbestand gelezen worden. Een punt die een komma wordt, of een dag en een maand die van plaats wisselen, geeft geen fout. Het geeft een ander cijfer.

Na te kijken: elke plaats waar een getal of datum omgezet wordt naar tekst of omgekeerd — export, import, rapportering en koppelingen met andere systemen.

2. Mailverzending

De manier waarop 4D mail verstuurt is over de jaren grondig veranderd. Oude code gebruikt vaak een aanpak die in recente versies niet meer bestaat of anders werkt. Het vervelende: mail die niet vertrekt geeft niet altijd een fout in uw toepassing. De code loopt door, de gebruiker ziet een bevestiging, en het bericht komt gewoon nooit aan.

Dit is dubbel gevaarlijk omdat het vaak gaat om berichten die niemand mist tot het te laat is: een automatische bevestiging aan een klant, een rapport dat 's nachts vertrekt, een waarschuwing bij een fout.

Na te kijken: elke plaats waar uw toepassing zelf mail verstuurt, en of er effectief iets met het resultaat gebeurt.

3. Printen en rapportering

Printen leunt op de printerdefinitie, op de lettertypes die op de machine staan, en op de manier waarop uw versie van 4D de pagina opbouwt. Na een migratie — vaak samen met een nieuw besturingssysteem of nieuwe machines — is minstens een van die drie anders.

Het resultaat is zelden een foutmelding. Het is een kolom die net buiten de bladspiegel valt, een lettertype dat vervangen wordt door een ander, of een rapport dat een regel per pagina meer toont — waardoor een totaal op de verkeerde plaats belandt.

Hoe u ze wel vangt

De enige betrouwbare methode is vergelijken. Zet de oude en de nieuwe versie naast elkaar op dezelfde gegevens, laat beide dezelfde reeks handelingen uitvoeren, en vergelijk de uitvoer regel per regel.

• Neem een kopie van uw echte gegevens, niet een testset. Stille fouten zitten net in de uitzonderingen die testdata niet bevat.
• Exporteer uit beide versies dezelfde lijsten, facturen en rapporten naar tekst, en vergelijk die bestanden automatisch. Uw ogen slaan verschillen over; een vergelijking niet.
• Doe dat op een machine met dezelfde regionale instellingen als die van uw gebruikers.
• Test mailverzending naar een echte mailbox die iemand leest.

Waarom dit zoveel uitmaakt

Een migratie wordt zelden afgerekend op de commando's die verdwenen zijn. Ze wordt afgerekend op het moment dat iemand een factuur met een verkeerd bedrag ziet vertrekken. Dat is meestal geen groot technisch probleem — het is een detail dat niemand heeft nagekeken, omdat er nooit een foutmelding is geweest.

Dit vergelijkingswerk is precies wat een migratie-audit systematisch doet: nagaan waar uw toepassing stil van gedrag verandert, voor uw klanten het merken.