Opschonen of migreren: is je CRM nog te repareren of is het op?

Door Robin Laseur

In de begroting voor volgend kwartaal staat een post voor een CRM-migratie, en de onderbouwing is één zin waar iedereen aan tafel mee instemt: het CRM is een puinhoop. Dubbele contacten, drie schrijfwijzen van hetzelfde bedrijf, deals aan het verkeerde account gekoppeld, rapporten die niemand vertrouwt. De reflex is om te vluchten naar een schoon nieuw platform en opnieuw te beginnen. Voordat dat wordt goedgekeurd, loont het om de puinhoop los te zien van de diagnose. Dat zijn namelijk twee verschillende dingen.
Opschonen of migreren is eigenlijk geen vraag over hoe rommelig je data is. Het is een vraag over waar de rommel zit. Zit hij in de data, dus in dubbelingen, verouderde records en wisselende notaties, dan lost opschonen het op en verplaatst een migratie het probleem alleen maar. Zit hij in het model, dus in een structuur die niet meer past bij hoe je bedrijf werkt, dan houdt geen enkele schoonmaak stand en is herbouwen de oplossing. De rommel is het symptoom. De plek waar hij zit, bepaalt de beslissing.
Waar ‘opschonen of migreren’ eigenlijk over gaat
Achter die woorden zitten twee verschillende ingrepen, en ze lossen verschillende problemen op. Opschonen is het corrigeren van de records: contacten en bedrijven ontdubbelen, notaties gelijktrekken, onvolledige regels aanvullen of archiveren, en drie versies van hetzelfde account samenvoegen tot één. Migreren is het verhuizen van die records naar een ander systeem, met al het veldmapping-, integratie- en testwerk dat daarbij hoort. Opschonen verbetert de data die je hebt. Migreren verandert de container waar die data in zit.
De beslissing hangt af van een derde factor die de meeste adviezen overslaan: je datamodel. Een datamodel is de structuur die bepaalt hoe je CRM informatie vasthoudt: welke objecten er zijn (contacten, bedrijven, deals, tickets), welke eigenschappen ze hebben, hoe ze aan elkaar gekoppeld zijn en welke regels ze consistent houden. HubSpot zegt het zelf treffend: een CRM is maar zo bruikbaar als het datamodel erachter, omdat het model de bouwtekening is en geen technisch detail. Past het model bij hoe je bedrijf echt werkt, dan is vervuilde data een kwestie van hygiëne. Past het niet, dan is vervuilde data een symptoom, en zet opschonen alleen de klok terug tot de vervuiling terugkomt.
De echte vraag is dus niet ‘hoe erg is het’. De vraag is ‘zit het probleem in de records of in de structuur die ze vasthoudt’. Dat onderscheid scheidt een CRM dat te repareren is van een CRM dat op is.
Waarom ‘eerst opschonen, dan migreren’ de eigenlijke beslissing overslaat
Zoek op dit onderwerp en bijna elke gids geeft hetzelfde antwoord: schoon je data op vóór de migratie, nooit tijdens, nooit erna. Dat advies klopt. Alleen beantwoordt het een andere vraag. ‘Eerst opschonen’ gaat ervan uit dat de migratie al vaststaat en bepaalt alleen de volgorde. De beslissing waar jij voor staat, komt een stap eerder: moet je überhaupt migreren, of lost opschonen op je huidige platform het probleem op?
Die eerdere beslissing laten de gidsen liggen, en juist die is duur als je hem verkeerd neemt. Keur je een migratie goed terwijl de rommel alleen in de data zat, dan betaal je voor een platformwissel om een hygiëneprobleem op te lossen. Vervolgens importeer je dezelfde dubbelingen in een systeem waar ze volgens brede consensus onder vakmensen een veelvoud kosten om op te lossen. Kies je voor opschonen terwijl de rommel in het model zat, dan glijden de records binnen een kwartaal terug in dezelfde vorm, omdat de structuur die ze voortbracht nooit is veranderd. Het volgordeadvies is goed zodra je besloten hebt te verhuizen. Of je moet verhuizen, vertelt het je niet.
Migreren is ook niet de veilige standaardkeuze waar het op lijkt als je gefrustreerd bent over het huidige systeem. Een groot deel van de CRM-migraties loopt volgens veelgenoemde schattingen uit de branche uit of stuit op serieuze dataproblemen. En het gaat zelden mis bij de import zelf. Het gaat mis bij het besluit om te verhuizen voordat duidelijk is wat er echt kapot was.
Het verschil: zit de rommel in je data of in je model?
Dit is de diagnose die de frustratie vervangt. Loop de problemen in je CRM na en deel ze in twee bakken in. De bak waar een probleem in valt, bepaalt het gereedschap.
Tekenen dat de rommel in de data zit, iets wat opschonen oplost: dubbele contacten en bedrijven na jaren handmatige invoer, telefoonnummers en landcodes in vijf verschillende notaties, records zonder e-mailadres of zonder activiteit in het afgelopen jaar of twee, en veldwaarden die nooit zijn bijgewerkt. Dit zijn problemen op recordniveau. Ze stapelen zich op in elk CRM dat al jaren in gebruik is, met dubbelingspercentages die vaak in de dubbele cijfers lopen, en geen van alle vraagt om een nieuw platform. Ze vragen om hygiëne, en steeds vaker kan het platform zelf het meeste daarvan automatiseren.
Tekenen dat de rommel in het model zit, iets wat opschonen niet oplost: rapporten die nooit sluiten omdat twee teams hetzelfde veld anders definiëren, een structuur zonder één eigenaar per veld waardoor hetzelfde feit op drie manieren wordt ingevoerd, eigen eigenschappen die er jarenlang aan zijn vastgeschroefd tot niemand meer weet welke leidend is, en een opzet die laat zien hoe het bedrijf werkte bij de inrichting, niet hoe het nu werkt. Wat al deze signalen gemeen hebben: opschonen houdt geen stand. Je ontdubbelt, trekt notaties gelijk, en binnen een kwartaal is dezelfde onenigheid terug, omdat de oorzaak in de structuur zit en niet in de invoer.
De scherpste test: zouden de problemen na een grondige opschoonronde terugkomen? Zo ja, dan zit de rommel in het model en bestrijdt opschonen een symptoom. Zo nee, dan is het model gezond en heb je een dataprobleem, geen platformprobleem. Een migratie is haar kosten pas waard als het model kapot is en het huidige platform echt geen beter model kan dragen. Die laatste voorwaarde weegt zwaarder dan ze lijkt, en daar wordt het meeste geld verspild.

Opschonen, herbouwen en migreren naast elkaar
Frustratie brengt de keuze terug tot twee opties: opschonen of migreren. Er zijn er drie, en de middelste slaan migratiegidsen vaak over, omdat je er geen migratie mee verkoopt.
Wat je vergelijkt | Opschonen | Herbouwen op je huidige platform | Migreren |
Wat het oplost | Vervuilde records | Een kapot model op een platform dat nog past | Een kapot model én een platform dat niet meer past |
Wat het ongemoeid laat | Het model (goed, als het model gezond is) | De leverancier en je integraties | Heel weinig, alles verhuist |
Relatieve kosten en risico | Laag, vaak te automatiseren | Gemiddeld, structureel maar op dezelfde plek | Hoog, het riskantste routineproject dat de meeste commerciële teams draaien |
Mislukt als | Het model het echte probleem is | Het platform het model dat je nodig hebt echt niet kan dragen | Het model in orde was en alleen de data vervuild |
Eerlijke standaardkeuze | Begin hier bij rommel op recordniveau | Het onderbenutte antwoord als de structuur kapot is maar het systeem past | Alleen de juiste keuze als structuur én platform niet kloppen |
Lees de tabel van links naar rechts en de logica is helder. Opschonen repareert records. Herbouwen repareert de structuur zonder van leverancier te wisselen, iets wat platforms als HubSpot direct ondersteunen met hun tools voor databeheer en datamodellen. Migreren repareert de structuur door het platform eronder te vervangen, en betaalt zich alleen terug als het huidige platform het model dat je echt nodig hebt niet kan dragen. Naar migratie grijpen terwijl herbouwen volstaat, is de meest voorkomende manier waarop het CRM-budget wordt overschreden.
Wanneer opschonen genoeg is, en wanneer je echt moet migreren
Opschonen is genoeg als je rapporten kloppen zodra de dubbelingen weg zijn, als iedereen het eens is over de velddefinities ook al zijn de waarden rommelig, en als de structuur nog steeds weerspiegelt hoe sales, marketing en service werken. Dat geldt voor de meeste CRM's die als een puinhoop voelen. De wanorde is echt, maar zit op recordniveau. Een gedisciplineerde opschoonronde plus regels die fouten bij de invoer voorkomen, lossen het op. Je hebt geen nieuw platform nodig om te stoppen met ‘john SMITH’ invoeren zonder gekoppeld bedrijf.
Je moet echt migreren als twee voorwaarden tegelijk gelden. Ten eerste is het model zo kapot dat herbouwen op dezelfde plek niet meer gaat: de objecten, koppelingen en regels beschrijven je bedrijf niet meer en zijn binnen het huidige systeem niet om te vormen. Ten tweede is het platform zelf nu de beperking, omdat het het model, de schaal of de integraties die je hierna nodig hebt niet aankan. Geldt maar één van de twee, dan wijst dat een andere kant op. Een kapot model op een capabel platform vraagt om herbouwen. Een gezond model dat tegen het plafond van een platform aanloopt, is een echte platformbeslissing. Dan is vergelijken waar je terechtkomt, bijvoorbeeld HubSpot tegenover Salesforce, de logische volgende stap. Alleen als beide gelden, is migreren het eerlijke antwoord en niet het gefrustreerde.

Wat migratiegidsen wegmoffelen: migreren is geen herstart
Onder de meeste migratieadviezen ligt de stille aanname dat een nieuw platform een schone lei is. Dat is het niet. Een migratie verhuist je datamodel mee met je data, tenzij je het model bewust opnieuw ontwerpt als onderdeel van de verhuizing. Importeer je een kapotte structuur in een nieuw systeem, dan heb je hetzelfde disfunctioneren opnieuw gebouwd onder een ander logo. Tegen flinke kosten, en met een team dat nu ook nog onbekende software moet leren. De vaak aangehaalde uitspraak dat CRM-migraties slechte data verplaatsen in plaats van repareren, geldt net zo goed voor structuur als voor records.
De omgekeerde kanttekening bespaart het meeste geld. Een kapot model betekent niet dat je je platform moet verlaten. Moderne CRM's laten je het model ter plekke herinrichten: objecten en eigenschappen opnieuw definiëren, koppelingen repareren, één eigenaar per veld aanwijzen en invoerregels afdwingen voor alles wat hierna komt. HubSpot bouwt zijn klantdatabeheer precies hieromheen: één consistent record dat je bijhoudt met vaste afspraken en eigenaarschap, niet met periodieke reddingsprojecten. ‘Het CRM is op’ is dus een uitspraak over het model, niet automatisch over de leverancier. Stel vast wat er echt kapot is, de structuur of het platform, voordat je iets tekent. Frustratie pleit voor migreren. De diagnose pleit meestal voor iets goedkopers.
Veelgestelde vragen
Moet je je CRM-data opschonen vóór of na de migratie?
Ervoor, altijd, als je al besloten hebt te migreren. Opschonen in een nieuw systeem is flink lastiger en duurder dan bij de bron, omdat je dan vecht tegen workflows en rapportages die al draaien. Maar dit is de vraag over volgorde, niet de vraag over de beslissing. Stel eerst vast of je überhaupt moet migreren.
Hoe weet je of je CRM het repareren waard is?
Doe de terugkeertest. Zouden dezelfde problemen na een grondige opschoonronde binnen een kwartaal terugkomen? Zo nee, dan is het model gezond en is je CRM met alleen hygiëne te repareren. Zo ja, dan zit de rommel in de structuur en bestrijdt opschonen een symptoom. Dat wijst op herbouwen of, alleen als het platform ook de beperking is, op migreren.
Is een rommelig CRM altijd een reden om van platform te wisselen?
Nee, en wie het zo behandelt, verspilt migratiebudget. De meeste rommelige CRM's hebben een probleem op recordniveau dat opschonen oplost, of een structureel probleem dat herbouwen op het huidige platform oplost zonder van leverancier te wisselen. Van platform wisselen is alleen gerechtvaardigd als het model kapot is en het huidige platform echt geen beter model kan dragen.
Wat is het verschil tussen een dataprobleem en een modelprobleem?
Een dataprobleem bestaat uit vervuilde records: dubbelingen, verouderde gegevens, wisselende notaties. Opschonen lost het op. Een modelprobleem is een kapotte structuur: velden die teams verschillend definiëren, geen vaste eigenaar per feit, een opzet die niet meer bij het bedrijf past. Opschonen lost dat niet op, omdat de structuur de rommel steeds opnieuw aanmaakt.
De belangrijkste punten
Of je je CRM opschoont of migreert, hangt af van waar de rommel zit, niet van hoe erg het eruitziet. Rommel in de data vraagt om opschonen. Rommel in het model vraagt om herbouwen of migreren.
Het gangbare advies (‘eerst opschonen, dan migreren’) beantwoordt een vraag over volgorde en gaat ervan uit dat de migratie al vaststaat. De echte beslissing komt een stap eerder.
Gebruik de terugkeertest: als de problemen na een grondige opschoonronde terug zouden komen, zit de rommel in de structuur en niet in de invoer.
Er zijn drie opties, geen twee. Opschonen repareert records, herbouwen op je huidige platform repareert een kapot model zonder van leverancier te wisselen, en migreren repareert een model als het platform zelf ook de beperking is.
Migreren is geen herstart. Je model gaat mee, tenzij je het opnieuw ontwerpt, en een kapot model kun je meestal herbouwen zonder je platform te verlaten.
Doe de test of het CRM echt het probleem is voordat je een migratie goedkeurt, want frustratie en diagnose wijzen zelden naar dezelfde oplossing. Een dataprobleem onderscheiden van een modelprobleem, en een modelprobleem van een platformprobleem: dat soort analyse doet Flatline als HubSpot Gold Partner, met een consultancypraktijk die begint bij de diagnose en niet bij een herbouw. Wil je een second opinion over de vraag of jouw CRM te repareren is of op, voordat het budget vastligt? Neem contact op, dan lopen we het samen met je door.
Gerelateerde artikelen
F.A.Q.
Moet je je CRM-data opschonen vóór of na de migratie?
Ervoor, altijd, als je al besloten hebt te migreren. Opschonen in een nieuw systeem is flink lastiger en duurder dan bij de bron, omdat je dan vecht tegen workflows en rapportages die al draaien. Maar dit is de vraag over volgorde, niet de vraag over de beslissing. Stel eerst vast of je überhaupt moet migreren.
Hoe weet je of je CRM het repareren waard is?
Doe de terugkeertest. Zouden dezelfde problemen na een grondige opschoonronde binnen een kwartaal terugkomen? Zo nee, dan is het model gezond en is je CRM met alleen hygiëne te repareren. Zo ja, dan zit de rommel in de structuur en bestrijdt opschonen een symptoom. Dat wijst op herbouwen of, alleen als het platform ook de beperking is, op migreren.
Is een rommelig CRM altijd een reden om van platform te wisselen?
Nee, en wie het zo behandelt, verspilt migratiebudget. De meeste rommelige CRM's hebben een probleem op recordniveau dat opschonen oplost, of een structureel probleem dat herbouwen op het huidige platform oplost zonder van leverancier te wisselen. Van platform wisselen is alleen gerechtvaardigd als het model kapot is en het huidige platform echt geen beter model kan dragen.
Wat is het verschil tussen een dataprobleem en een modelprobleem?
Een dataprobleem bestaat uit vervuilde records: dubbelingen, verouderde gegevens, wisselende notaties. Opschonen lost het op. Een modelprobleem is een kapotte structuur: velden die teams verschillend definiëren, geen vaste eigenaar per feit, een opzet die niet meer bij het bedrijf past. Opschonen lost dat niet op, omdat de structuur de rommel steeds opnieuw aanmaakt.



