Een ERP-migratie is het vervangen van uw huidige bedrijfssoftware door een ander systeem, of de overstap naar een nieuwe versie van hetzelfde product. Wie wil veranderen van ERP, denkt vaak eerst aan de keuze van het nieuwe pakket. In de praktijk wordt het project bepaald door iets anders: hoe goed uw gegevens, uw processen en uw mensen de overstap doorstaan.
Deze gids is bedoeld voor directies, financieel verantwoordelijken en IT-managers van het Nederlandse mkb en grotere middelgrote bedrijven. U leest wanneer een overstap zin heeft, hoe u een omschakelstrategie kiest, hoe de gegevensmigratie verloopt en wat u regelt voor het geval het misgaat. Staat uw keuze voor een nieuw pakket nog open, lees dan eerst de gids over een ERP kiezen.
Wanneer is het tijd om uw ERP te vervangen?
Niemand migreert voor de lol. Een overstap kost aandacht, geld en rust in de organisatie, dus er moet een zwaarwegende reden zijn. Veelvoorkomende signalen:
- Het systeem remt de groei. Nieuwe vestigingen, een tweede bedrijfsonderdeel, een webwinkel of een buitenlandse entiteit passen er niet meer in zonder omwegen.
- Maatwerk wordt een blok aan het been. Elke aanpassing is duur, afhankelijk van één persoon of breekt bij een update.
- Ondersteuning loopt af. De leverancier stopt met een versie, of de partij die het systeem onderhoudt bestaat niet meer.
- Veel werk gebeurt buiten het systeem. Als uw medewerkers de belangrijkste cijfers in spreadsheets bijhouden, is het ERP geen bron van waarheid meer.
- Wet- en regelgeving verandert. Denk aan elektronisch factureren, BTW-aangiften en rapportageverplichtingen. Meer daarover leest u in ERP en e-facturatie.
- De bedrijfsvoering is veranderd. Een overname, een nieuw verdienmodel of een andere productiewijze vraagt andere functies.
- Infrastructuur en beveiliging. Servers in eigen beheer die niet meer te onderhouden zijn, kunnen aanleiding zijn om de overstap naar de cloud te onderzoeken. Zie cloud-ERP of on-premise.
Geen goede reden is een nieuwe, aantrekkelijker demo. Een ander pakket lost slechte processen, rommelige gegevens en onduidelijke verantwoordelijkheden niet op; het maakt ze zichtbaar.
Migreren of upgraden?
Het woord migratie dekt twee verschillende situaties:
| Situatie | Wat verandert er | Typisch risico |
|---|---|---|
| Overstap naar een ander pakket | Software, datamodel, processen en vaak ook de manier van werken | Gegevens passen niet één op één; gebruikers moeten opnieuw leren |
| Overstap naar een nieuwe versie van hetzelfde product | Technische basis, soms functies en schermen | Maatwerk en koppelingen die niet meer werken |
| Van eigen server naar cloud | Hosting, beheer en vaak het licentiemodel | Prestaties, integraties en afhankelijkheid van de leverancier |
| Van een los pakket naar een geïntegreerd ERP | Meerdere systemen worden samengevoegd | Dubbele stamgegevens en onduidelijke eigenaarschap |
Ook een versie-upgrade is zelden een kwestie van een knop indrukken. Zodra er maatwerk of koppelingen in zitten, gedraagt het project zich als een kleine implementatie.
Voorbereiding: wat u doet voordat u een pakket kiest
De meeste migraties worden gewonnen of verloren vóór het eerste testsysteem bestaat. Zorg voor deze basis.
Leg vast wat er nu is
Maak een eerlijke inventaris van het huidige landschap: welke modules worden echt gebruikt, welke aanpassingen zijn gemaakt, welke koppelingen bestaan er met boekhouding, webwinkel, vervoerders, banken en rapportagetools. Vraag ook naar het onzichtbare: de spreadsheets, macro’s en handmatige stappen waar uw team op leunt. Juist daar zit kennis die verloren gaat bij een overstap.
Bepaal wat u wilt bereiken
Formuleer de doelen in bedrijfstaal: sneller afsluiten, minder handwerk in de orderverwerking, betere voorraadinzicht, beheersbare onderhoudskosten. Vertaal ze naar een programma van eisen. Zonder dat document vergelijkt u pakketten op indruk, en beoordeelt u het resultaat achteraf op gevoel.
Organiseer het project
Een migratie heeft een opdrachtgever met mandaat, een projectleider aan uw kant, en per proces een eigenaar die het kent. Reken erop dat uw beste mensen tijd moeten vrijmaken. Wie de kennisdragers alleen "erbij" laat doen, krijgt een systeem dat niet past op de praktijk. Hoe het project in zijn geheel verloopt, staat beschreven in de ERP-implementatie.
Kies de partner met zorg
De integrator bepaalt voor een groot deel hoe soepel de overstap verloopt. Vraag naar ervaring met migraties vanuit uw huidige systeem, naar de manier van gegevensoverdracht en naar wie uw aanspreekpunt wordt. Handvatten vindt u in een ERP-integrator kiezen. Op hoe de mise-en-relation werkt leest u hoe wij u kosteloos in contact brengen met een passende, onafhankelijke integrator; het project zelf voert die integrator uit.
Het pakket: een kort overzicht van het speelveld
Veel Nederlandse bedrijven overwegen dezelfde kandidaten. Zonder hier een voorkeur uit te spreken:
- Odoo is een modulair ERP met een open-sourcekern, waarbij u functies naar behoefte activeert. Zie Odoo en, voor de achtergrond, open-source ERP.
- Exact Online en AFAS zijn in Nederland veel gebruikte clouddiensten, sterk in boekhouding, administratie en HR en vooral populair in het mkb en bij dienstverleners.
- Microsoft Dynamics 365 Business Central is een cloud-ERP voor groeiende mkb-bedrijven, dicht aansluitend op de Microsoft-omgeving. Meer in Business Central.
- SAP Business One richt zich op kleinere en middelgrote ondernemingen met een vertrouwde SAP-structuur. Zie SAP Business One.
- Oracle NetSuite is een cloud-ERP voor groeiende bedrijven, ook met meerdere entiteiten en landen. Zie Oracle NetSuite.
Wilt u direct vergelijken, bekijk dan de vergelijkingen, bijvoorbeeld Odoo en Business Central. Bent u een kleiner bedrijf, dan helpt ERP voor het mkb om de ambitie af te stemmen op uw omvang.
De omschakelstrategie: big bang, gefaseerd of parallel
Dit is de belangrijkste ontwerpkeuze in het project. U beslist hoe en wanneer de organisatie van oud naar nieuw gaat.
Big bang
Op één afgesproken moment gaat alles tegelijk over. Het oude systeem gaat in een leesstand of wordt afgesloten, het nieuwe wordt de enige werkomgeving.
Voordelen: geen tijdelijke koppelingen tussen oud en nieuw, één opleidingsmoment, duidelijke einddatum, geen dubbele administratie.
Nadelen: één beslissend moment, veel wijzigingen tegelijk voor de gebruikers en weinig ruimte om een fout bij te sturen zonder dat de dagelijkse gang van zaken schade ondervindt.
Dit past bij bedrijven met sterk samenhangende processen, waar een half werkend systeem onmogelijk is, en bij kleinere organisaties met overzichtelijke inrichting.
Gefaseerde bascule
U schakelt per onderdeel over: bijvoorbeeld eerst de financiële administratie, dan inkoop en voorraad, daarna productie of projecten. Een variant is per entiteit, vestiging of land.
Voordelen: het risico wordt gespreid, het team leert stap voor stap en fouten uit een fase kunt u in de volgende vermijden.
Nadelen: u heeft tijdelijke koppelingen tussen oud en nieuw nodig, de rapportage is een tijd lang verdeeld over twee bronnen en het project duurt langer. Een slecht ontworpen fasering levert dubbel werk op.
Parallel draaien
Beide systemen werken een periode naast elkaar met dezelfde invoer. Dit geeft veel zekerheid over de uitkomsten, maar kost veel menskracht. Gebruik het gericht, bijvoorbeeld voor een afsluiting van de boekhouding of een kritiek proces, niet als standaardaanpak voor het hele bedrijf.
Welke aanpak past bij u?
| Criterium | Big bang | Gefaseerd | Parallel |
|---|---|---|---|
| Samenhang van de processen | Hoog | Laag tot gemiddeld | Afhankelijk van scope |
| Belasting van het team | Piek rond de livegang | Gespreid, maar langer | Zwaar gedurende de overlap |
| Technische complexiteit | Lager | Hoger door tijdelijke koppelingen | Hoger door dubbele invoer |
| Risico per moment | Hoog | Lager | Laag voor de uitkomst, hoog voor de capaciteit |
| Terugval | Vooraf te regelen | Per fase te regelen | Het oude systeem blijft beschikbaar |
Kies dus op basis van uw eigen situatie. Een productiebedrijf met een nauw verweven planning en voorraad redeneert anders dan een dienstverlener met losse projectadministratie. Voor sectorspecifieke punten kijkt u bij ERP voor productie of ERP voor groothandel.
Gegevensmigratie: het hart van het project
Bij de reprise de données gaat het meestal mis, niet in de techniek maar in de kwaliteit van wat u overzet. Een nieuw ERP met oude vervuiling blijft vervuild.
Stap 1: bepaal wat mee moet
Niet alles verdient een plek in het nieuwe systeem. Maak met de procesverantwoordelijken en uw accountant een duidelijke indeling:
- Stamgegevens: relaties, leveranciers, artikelen, stuklijsten, prijslijsten, medewerkers en vaste activa.
- Openstaande posten: debiteuren, crediteuren, openstaande orders, lopende contracten en projecten.
- Saldi: de beginbalans en de openingsstanden van het grootboek.
- Historie: alleen wat u operationeel nodig heeft. De rest kan in een archief of rapportagelaag blijven.
Wettelijke bewaarplichten voor financiële gegevens blijven gelden. Spreek met uw accountant af hoe en waar u die gegevens beschikbaar houdt, ook als het oude systeem uit de lucht gaat.
Stap 2: opschonen
Dit is werk voor mensen die de gegevens kennen, niet voor de integrator alleen. Denk aan:
- dubbele relaties en artikelen samenvoegen;
- verlopen, inactieve of onbruikbare records archiveren;
- ontbrekende velden aanvullen, zoals BTW-nummers, betaalvoorwaarden of eenheden;
- inconsistente benamingen en codes rechtzetten;
- afwijkende adresnotaties, landcodes en rekeningnummers controleren.
Plan hiervoor ruim tijd in. Het is de meest onderschatte post van elk migratietraject.
Stap 3: mapping
Bij de mapping legt u vast welk veld in het oude systeem overeenkomt met welk veld in het nieuwe. Dat lijkt eenvoudig, maar systemen denken verschillend. Het ene pakket kent een vaste indeling van het grootboek, het andere werkt met dimensies; het ene gebruikt artikelvarianten, het andere losse artikelen. Leg de regels schriftelijk vast, inclusief wat er met velden zonder tegenhanger gebeurt. Dat document wordt later uw bewijs bij discussies.
Stap 4: transformeren en laden
De integrator bouwt scripts of gebruikt importtools om de gegevens om te zetten en in te laden. Belangrijk is dat dit herhaalbaar is: u wilt de overdracht meerdere keren kunnen draaien, en niet eenmalig met de hand uitvoeren. Handmatig corrigeren in de doeldata verdient geen plaats; fouten herstelt u in de bron of in het script.
Stap 5: proefmigraties en controle
Voer de overdracht meerdere keren uit op een testomgeving en controleer het resultaat met echte gebruikers. Leg afstemmingen vast:
- sluit het saldo van het grootboek aan op de bron;
- komen de totalen van debiteuren en crediteuren overeen;
- klopt de voorraadwaarde met de laatste telling;
- kunnen gebruikers hun eigen relaties, orders en artikelen terugvinden;
- doorlopen de belangrijkste processen van offerte tot betaling zonder omwegen.
Elke proefronde levert een lijst met afwijkingen op. Pas een volgende ronde pas aan als de vorige lijst is afgehandeld. De laatste generale repetitie, op het niveau van de echte livegang en met dezelfde volgorde en tijdsduur, geeft u het vertrouwen voor het definitieve moment.
Koppelingen en integraties
Gegevens zitten ook in wat u met andere systemen uitwisselt: bank, webwinkel, vervoerders, EDI, salarisverwerking, BI-tools en de Belastingdienst. Inventariseer elke koppeling, besluit of die blijft, wordt vervangen of vervalt, en test ze met echte berichten. Vergeet de uitgaande documenten niet: facturen, pakbonnen, aanmaningen en betalingsbestanden moeten in het nieuwe systeem correct en herkenbaar zijn voor uw klanten.
Testen, opleiden en livegang
Acceptatietest met echte scenario’s
Test niet alleen losse functies, maar complete bedrijfsscenario’s: een order die de voorraad raakt, een inkoopfactuur met afwijkend bedrag, een retour, een creditnota, een afsluiting aan het einde van de periode. Laat de mensen testen die ermee gaan werken, niet alleen de projectleiders. Leg vast wat als blokkerend, belangrijk of cosmetisch telt, zodat de livegang niet verzandt in discussies.
Opleiden voor het moment suprême
Gebruikers die het systeem nooit eerder zagen, maken op dag één fouten die u kunt vermijden. Train in kleine groepen op een omgeving met herkenbare gegevens, en maak een korte handleiding per rol. Wijs per afdeling een superuser aan die vragen opvangt in de eerste weken.
Go/no-go
Spreek vooraf af welke criteria bepalen of u live gaat: alle blokkerende fouten opgelost, de laatste proefmigratie afgestemd, de koppelingen werkend, de gebruikers getraind, de terugvalprocedure getest. Een go/no-go zonder vooraf bepaalde criteria wordt een onderhandeling onder tijdsdruk.
Het kiezen van het moment
Kies een periode met een natuurlijke pauze. Voor veel bedrijven is dat het begin van een boekjaar of een nieuwe periode, zodat u de beginbalans eenvoudig kunt vaststellen. Vermijd drukke pieken in uw seizoen, de afsluiting van het jaar en vakantieperiodes waarin sleutelpersonen ontbreken.
Risico’s en het terugvalplan
Elke migratie kent risico’s. Het gaat erom dat u ze benoemt voor ze zich voordoen.
| Risico | Gevolg | Maatregel |
|---|---|---|
| Slechte gegevenskwaliteit | Foutieve orders, facturen en voorraad | Opschonen vóór de overdracht, meerdere proefmigraties |
| Onderschatte scope | Uitloop en oplopende kosten | Helder programma van eisen, wijzigingsbeheer |
| Te weinig tijd van eigen mensen | Systeem past niet bij de praktijk | Capaciteit vrijmaken en vastleggen in het plan |
| Koppelingen die niet werken | Stilstand in order- of betaalstromen | Elke koppeling inventariseren en testen |
| Weerstand bij gebruikers | Omwegen, spreadsheets, slechte datakwaliteit | Vroeg betrekken, superusers, goede opleiding |
| Afhankelijkheid van één persoon | Kennisverlies bij ziekte of vertrek | Documenteren en kennis spreiden |
| Fouten na livegang | Vertraging en onzekerheid | Extra ondersteuning in de beginperiode |
Lees ook veelgemaakte fouten in ERP-projecten voor patronen die in de praktijk steeds terugkeren, en het artikel over ERP-kosten voor het financiële plaatje van een overstap.
Een terugvalplan dat werkt
Een terugvalplan (retour-arrière) is een afspraak over wat u doet als de livegang niet slaagt. Het bestaat uit meer dan de intentie om "het oude systeem terug te zetten". Regel het concreet:
- Beslismoment en bevoegdheid. Wie besluit tot terugval, op grond van welke criteria en tot welk tijdstip? Na een bepaald punt is terugkeren niet meer reëel, omdat er al nieuwe transacties in het nieuwe systeem zijn vastgelegd.
- Het oude systeem blijft beschikbaar. Zet het in een leesstand of houd het bruikbaar tot de eerste afsluiting in het nieuwe systeem is gelukt. Zorg dat licenties, hosting en ondersteuning niet te vroeg aflopen.
- Een bevroren, geteste back-up. Maak vlak voor de overdracht een volledige kopie van het oude systeem en controleer dat die daadwerkelijk te herstellen is.
- Regels voor transacties tijdens de overgang. Wat doet u met orders, ontvangsten en betalingen die tijdens de bascule binnenkomen? Hoe neemt u ze alsnog over, in welke volgorde?
- Communicatie. Informeer klanten, leveranciers, de bank en uw accountant over het moment van overgang en over wat zij kunnen verwachten.
- Test van de terugval. Oefen het scenario, in elk geval op papier en bij voorkeur ook technisch.
Houd er rekening mee dat een terugval na een tijdje in het nieuwe systeem werken zelden volledig kan. Dat is een reden om de go/no-go streng te doen en de eerste dagen intensief te begeleiden.
Na de livegang
Het project eindigt niet bij de overgang. De periode erna bepaalt of het nieuwe ERP echt wordt gebruikt zoals bedoeld.
- Hypercare. Reken in de beginperiode op extra ondersteuning van de integrator en snelle reactie op meldingen. Laat gebruikers vragen en fouten op één plek melden.
- Eerste afsluiting. Draai de eerste maand- of periodeafsluiting met extra aandacht en vergelijk de uitkomsten met de verwachting.
- Opruimen. Rond de oude omgeving netjes af: archiveren, toegang beperken, licenties beëindigen en de bewaarplicht borgen.
- Verbeteren. Verzamel wensen en knelpunten, bepaal wat bij het ontwerp hoort en wat als vervolgproject geldt. Maatwerk dat u in de beginfase uitstelde, beoordeelt u nu met echte ervaring.
- Evalueren. Toets de oorspronkelijke doelen aan het resultaat. Kwam de besparing, het inzicht of de snelheid die u verwachtte?
Wat u zelf kunt doen om het project te laten slagen
Samengevat zijn dit de punten die het meeste effect hebben:
- Begin met doelen en een programma van eisen, niet met een pakket.
- Kies een omschakelstrategie die past bij de samenhang van uw processen.
- Maak gegevensopschoning een eigen werkstroom met eigenaren.
- Oefen de overdracht herhaaldelijk met echte gegevens en laat gebruikers controleren.
- Stel go/no-go-criteria vooraf vast en bereid een geteste terugval voor.
- Reserveer capaciteit in uw eigen team, en plan de livegang op een rustig moment.
- Houd na de livegang extra begeleiding en leg afspraken vast over verbeteringen.
Wilt u weten welke integrator ervaring heeft met een overstap vanuit uw huidige systeem? Beschrijf uw situatie via het aanvraagformulier. We brengen u kosteloos in contact met een passende integrator, die vervolgens het project voor u uitvoert en de aanpak, de planning en de kosten met u bespreekt.
Veelgestelde vragen
Wat is het verschil tussen een ERP-migratie en een ERP-implementatie?
Bij een implementatie voert u voor het eerst een ERP in, vaak na spreadsheets of losse pakketten. Bij een migratie vervangt u een bestaand systeem of gaat u naar een nieuwe versie. Daardoor komt er een zware taak bij: bestaande gegevens, koppelingen en gewoontes moeten mee. Het project lijkt dus kleiner dan het is.
Wanneer is het verstandig om van ERP te veranderen?
Als het huidige systeem uw groei, uw ketens of uw wettelijke verplichtingen niet meer aankan en aanpassingen steeds meer kosten dan ze opleveren. Ook het einde van ondersteuning voor een versie, een overname of een andere bedrijfsvoering zijn goede redenen. Een tijdelijke ergernis of een nieuwe interface is dat meestal niet.
Is een big bang of een gefaseerde bascule beter?
Dat hangt af van de samenhang van uw processen, de risico’s bij een storing en de capaciteit van uw team. Een big bang is overzichtelijker en vermijdt dubbel werk, maar kent één beslissend moment. Een gefaseerde overgang spreidt het risico, maar vraagt tijdelijke koppelingen en meer coördinatie. Uw integrator weegt dit samen met u af.
Welke gegevens moet ik echt overzetten?
Stamgegevens zoals relaties, artikelen en stuklijsten, openstaande posten, openstaande orders en de beginbalans van het grootboek. Historische transacties zijn vaak niet nodig in het nieuwe systeem en kunnen in een archief of rapportagelaag blijven staan. Leg met uw accountant vast wat u wettelijk moet kunnen terugvinden.
Hoe voorkom ik dat de migratie mislukt?
Begin met een scherp programma van eisen, ruim gegevens op voordat u ze overzet en oefen de overdracht meerdere keren met echte gegevens. Maak gebruikers vroeg eigenaar van hun processen, stel duidelijke go/no-go-criteria vast en bereid een terugvalplan voor. De meeste problemen ontstaan door te weinig testen, niet door de software.
De genoemde softwarenamen zijn handelsmerken van hun respectievelijke eigenaren en worden uitsluitend ter informatie vermeld. Deze site is onafhankelijk en niet verbonden aan een softwareleverancier.