Een data migratie mislukt vrijwel nooit zoals mensen zich voorstellen — een dramatische crash halverwege het overstapweekend. Hij mislukt stilletjes. Een groep records die niet meekwam omdat een foreign key verwees naar iets waar het migratiescript geen rekening mee hield. Een rapport dat drie weken lang stilletjes verkeerd is geweest voordat iemand merkt dat de totalen niet kloppen. Een nachtelijke job die op de oude server prima werkte en op de nieuwe vastloopt omdat niemand controleerde of de standaardinstellingen van de nieuwe database overeenkwamen met die van de oude. Niets daarvan ziet eruit als een mislukking op de overstapdag zelf. Het ziet eruit als een mislukking een maand later, als niemand nog weet welke stap de oorzaak was.
Deze gids gaat specifiek over de datalaag: een productiedatabase verhuizen naar een nieuwe engineversie, een nieuw platform of een nieuwe leverancier, terwijl de applicatie erboven grotendeels hetzelfde blijft. Dat is een ander project dan de vraag of uw infrastructuur überhaupt in de cloud hoort — onze gids over cloudmigratie behandelt die bredere beslissing — en weer anders dan de applicatie zelf vervangen, wat onze gids over legacy software vervangen vanuit de applicatiekant behandelt. Hier blijft de applicatie grotendeels bestaan; het is de database erónder die verhuist.
Waarom dit zich voordoet
Een data migratie is zelden optioneel zodra hij eenmaal op de agenda staat. De gebruikelijke aanleidingen:
- Een einde-ondersteuningsdeadline. Een specifieke engineversie stopt op een vaste datum met beveiligingsupdates — onze gids over [de deadline van SQL Server 2016](/nl/articles/sql-server-2016-einde-ondersteuning) behandelt één voorbeeld — en erop blijven draaien na die datum houdt op een keuze te zijn die u stilletjes kunt blijven uitstellen.
- Uit uw jas gegroeid. Querytijden die ooit instant waren, duren nu seconden, en de oplossing is een grotere instance, een andere engine, of een beheerde dienst die meeschaalt zonder dat u hem zelf hoeft te verzorgen.
- Consolidatie. Twee bedrijven fuseren, of twee systemen die los van elkaar zijn gegroeid moeten allebei dezelfde rapportagelaag voeden.
- De hosting verhuist, niet de software. De database gaat van een server op uw eigen kantoor naar een beheerde clouddatabase, terwijl de applicatie die erop aansluit vrijwel ongewijzigd blijft.
Geen van deze gevallen is op de dag zelf een crisis. Ze worden er een als u wacht tot de deadline nog een maand weg is om met het echte werk te beginnen.
De vier fases die een migratie saai houden
Een migratie die goed verloopt, is bijna per definitie onopvallend. U komt daar door het ongeglamoureuze werk vóór de overstapdag te doen, niet erop.
1. Beoordeel voordat u iets aanraakt
Voordat er ook maar één byte verhuist, moet u weten wat daadwerkelijk kapotgaat. Compatibiliteitsproblemen — een datatype dat de nieuwe engine anders behandelt, een functie waar uw applicatie op leunt en die op het doel niet bestaat, een stored procedure geschreven tegen gedrag dat tussen versies is veranderd — zijn op papier veel goedkoper te vinden dan in productie. Dit is een reële stap met echte tooling erachter, geen voorzichtigheid om de voorzichtigheid: Microsofts eigen aanpak voor SQL Server-omgevingen is precies op zo'n beoordeling gebouwd, met wat het zelf migratieblokkerende problemen, deels ondersteunde functies en breaking changes noemt, allemaal vóórdat u ook maar één record verplaatst.
Relevant als u specifiek in die wereld zit: Microsofts eigen gratis beoordelingstool voor precies deze klus, de Data Migration Assistant, is op 16 juli 2025 uit de running gehaald. Verwijst een oudere gids of de aantekeningen van een collega u daarnaar, dan is dat advies al verouderd. Microsofts huidige pad hangt af van waar u naartoe gaat — de Azure SQL-migratie-extensie voor Azure Data Studio voor een overstap naar Azure SQL Managed Instance, of Azure Database Migration Service, die Microsoft beschrijft als gebouwd voor naadloze migraties van meerdere databasebronnen naar Azure met minimale downtime, voor een migratie op grotere schaal. De specifieke tool is minder belangrijk dan de gewoonte waar hij op wijst: controleer wat actueel is voordat u ergens op plant, want precies deze tool is binnen twee jaar veranderd.
2. Maak de data schoon en breng die in kaart, niet alleen het schema
Het schema is het makkelijke deel om op te plannen. De data zelf is waar migraties daadwerkelijk misgaan: dubbele klantrecords die allebei "werkten" onder de losse validatie van de oude applicatie, foreign keys die verwijzen naar records die jaren geleden soft-deleted zijn en nooit opgeruimd, datumvelden die formats mengen omdat drie verschillende integraties jarenlang naar dezelfde kolom schreven, encoderingsproblemen die een accent laten verschijnen als een vraagteken. Niets daarvan komt aan het licht totdat u het probeert te verhuizen naar iets strenger.
Breng elk veld dat u verhuist in kaart naar wat het vandaag daadwerkelijk betekent, niet naar wat de oorspronkelijke documentatie zegt dat het zou moeten betekenen — jarenlang gebruik in de praktijk wijkt vrijwel altijd af van het oorspronkelijke ontwerp. Bepaal expliciet wat u migreert versus archiveert: oude transactiehistorie die u wettelijk moet bewaren maar die niemand dagelijks raadpleegt, hoeft niet voortaan in uw snelle, dure productiedatabase te blijven staan.
3. Kies bewust uw overstapmethode
Er zijn twee basisvormen, en de meeste MKB-bedrijven kiezen standaard voor de eerste zonder de tweede serieus te overwegen:
Een big-bang-overstap. Vries schrijfacties naar de oude database in, kopieer alles over, controleer het, en schakel de applicatie over — allemaal binnen één ingepland downtimevenster. Eenvoudiger om uit te voeren en te overzien, en voor de meeste migraties op MKB-schaal de juiste keuze, omdat de hoeveelheid data meestal ruim binnen een weekend of een avond past.
Een gefaseerde migratie, of parallelle draai. Houd beide systemen gelijktijdig live en gesynchroniseerd gedurende een periode, en migreer in stappen, zodat er geen enkel alles-of-niets-venster is. Dat levert minder downtimerisico op, tegen de prijs van echte extra complexiteit — u heeft een manier nodig om de twee databases synchroon te houden terwijl beide live zijn, en een plan voor wat er gebeurt als ze het even niet met elkaar eens zijn. De moeite waard wanneer een volledige stilstand oprecht niet te tolereren is; overkill, en een bron van eigen bugs, wanneer dat niet zo is.
Kies de methode op basis van hoeveel downtime uw bedrijf daadwerkelijk kan absorberen — expliciet bepaald, samen met de mensen die van het systeem afhankelijk zijn, niet geschat op basis van wat redelijk klinkt — in plaats van op welke optie geavanceerder klinkt. Het ordersysteem van een webshop en een intern rapportagedashboard hebben zelden hetzelfde antwoord, en ze hetzelfde behandelen is hoe een migratieplan onnodig duur of stilletjes risicovol wordt.
4. Valideer voordat u het afgerond noemt
Kloppende recordaantallen aan beide kanten is de minimumcheck, niet de finish. Draai uw echte rapportages tegen de gemigreerde data en vergelijk de uitkomst met wat het oude systeem voor dezelfde periode produceerde. Controleer handmatig een aantal records die een mens kan verifiëren, niet alleen een steekproef die de eigen logica van het migratiescript koos. Heeft u de luxe van een niet-productieomgeving om te oefenen, draai de volledige migratie daar dan eerst, exact zoals u hem echt gaat uitvoeren, en neem de tijd op — een oefenronde is ook hoe u ontdekt dat uw "venster van vier uur" er in werkelijkheid zeven zou worden.
Het terugvalplan dat niemand hoopt nodig te hebben
Houd de oude database intact en bereikbaar, desnoods in alleen-lezenmodus, voor een vastgestelde periode na de overstap — lang genoeg om de problemen te vangen die alleen zichtbaar worden zodra het echte dagelijkse gebruik weer op gang komt, niet alleen de problemen die het eerste uur al opvallen. Bepaal vooraf wat daadwerkelijk een terugval zou triggeren, in plaats van dat live te beslissen onder druk op de dag dat iets er verkeerd uitziet. De migratie die écht misgaat, is meestal degene waarbij de enige kopie van de "voor"-staat werd verwijderd op het moment dat de "na"-staat leek te werken.
Wat meeverhuist, en wat niet
Een database naar een nieuwe engine of een nieuwe leverancier verhuizen reset geen wettelijke klok die aan de data erin vastzit. Bevat wat u migreert persoonsgegevens met hun eigen bewaartermijn, dan verhuist die verplichting gewoon mee — onze gids over hoelang u klantgegevens onder de AVG moet bewaren behandelt die vraag rechtstreeks, en het is de moeite waard die te checken voordat u beslist wat u archiveert versus verwijdert tijdens de verhuizing in plaats van erna.
De fouten die telkens terugkomen
De compatibiliteitsbeoordeling overslaan omdat "het eigenlijk dezelfde database is." Eigenlijk hetzelfde is precies waar een standaardcollation, de precisie van een datatype, of een verouderde functie stilletjes verschilt.
Het schema als de migratie behandelen en de data als bijzaak. Het schema verhuist bijna altijd probleemloos. De opgebouwde rommel in de data is waar het echte werk zit.
Geen oefenronde. De eerste keer dat u de volledige migratie draait, mag niet de enige keer zijn dat het er echt toe doet.
De bron te snel verwijderen. De oude database is uw terugvalplan. Houd hem totdat u er echt op vertrouwt dat u hem niet meer nodig heeft, niet totdat het eerste uur er goed uitziet.
Eén downtimegetal voor elk systeem. Een venster van vier uur kan ruim voldoende zijn voor de ene database en bij lange na niet genoeg voor een andere die een ander deel van het bedrijf voedt.
Veelgestelde vragen
Hoeveel downtime heeft een data migratie daadwerkelijk nodig? Dat hangt af van de hoeveelheid data, de methode die u kiest, en het doel. Een kleine operationele database past vaak binnen een ingepland venster van een paar uur; een gefaseerde, bijna-downtimevrije migratie ruilt dat korte venster in voor weken waarin twee systemen synchroon draaien. Bepaal eerst de acceptabele downtime — de methode volgt daaruit.
Kan een database zonder enige downtime migreren? Bijna nul is realistisch met een gefaseerde, parallelle aanpak, maar "nul" in absolute zin is zeldzaam — er is vrijwel altijd een kort laatste moment waarop de applicatie overschakelt van de oude naar de nieuwe database.
Hoelang duurt een typische data migratie voor het MKB? De technische verhuizing zelf kan voor de meeste systemen op MKB-schaal variëren van een paar uur tot een weekend. Het project daaromheen — beoordeling, datacleansing, een oefenronde — duurt doorgaans langer dan mensen vooraf plannen, omdat het werk aan datakwaliteit lastiger vooraf te schatten is dan de kopieerstap zelf.
Hebben we een oefenmigratie nodig, of kunnen we het gewoon één keer goed doen? Een oefenronde is hoe u problemen vindt voordat ze live problemen zijn — een script dat werkt op een schone testset gedraagt zich vaak anders tegen jaren aan echte productierommel. Hem overslaan is de meest voorkomende reden dat een migratie zijn geplande venster overschrijdt.
Welke tools gebruiken we voor de migratie zelf? Dat hangt sterk af van uw bron- en doelengine, en het antwoord verandert in de tijd — de tool die Microsoft twee jaar geleden aanraadde voor SQL Server-beoordelingen is in 2025 uit de running gehaald ten gunste van nieuwere opties. Controleer wat actueel is voor uw specifieke engines, in plaats van de exacte toolnamen uit een oudere gids te volgen.
De volgorde op orde krijgen
De technische kopieerslag van een data migratie is zelden het lastigste deel — dat zijn de beoordeling, de datacleansing en een oefenronde die daadwerkelijk vóór de echte datum wordt gedraaid. Ons team Data & Databases doorloopt die volgorde van begin tot eind, inclusief de compatibiliteitsbeoordeling en de datareconciliatie die de meeste MKB-bedrijven onderschatten. En wanneer de bestemming van de migratie een beheerd cloudplatform is in plaats van een andere server, verzorgt ons team Cloud & Infrastructure de hostingkant van die verhuizing als onderdeel van hetzelfde project, in plaats van de database en zijn nieuwe thuis als twee losse klussen te behandelen.