Lessen uit Salesforce- en HubSpot-projecten: je CRM-migratie staat of valt met de eerste 30 dagen

Of een CRM-migratie slaagt, wordt in de eerste 30 dagen bepaald. De data inladen is zelden het moeilijkste deel. Het lastige zit in de beslissingen die teams in de eerste maand uitstellen, over scope, historie, procesontwerp, de freeze, automatisering, toegang en back-ups. Die komen in de laatste weken terug, precies wanneer elke wijziging het meeste kost.

Bij de Salesforce- en HubSpot-migraties die we hebben uitgevoerd, verschillen de techstacks en de leveranciers. De fouten blijven dezelfde. Een CEO of CFO ziet de kosten terug in een go-live die een kwartaal opschuift, een salesteam dat in twee systemen werkt en een forecast waar tijdens de overstap niemand op vertrouwt. Voor de RevOps lead die het project trekt, zetten we hieronder op een rij wat steeds misgaat en wat wel werkt.

De meeste problemen bij een CRM-migratie beginnen in de discoveryfase

De beslissingen die je in week één uitstelt, bepalen hoe ver de schade doorwerkt in alles wat volgt. Ben je in maand drie nog objecten aan het mappen, dan ben je te laat begonnen. Scope creep komt zelden door slechte planning. Het is een symptoom van een onvolledige discovery.

Begin met een volledige inventaris van je data en rapporten. Zet elk object, elk aangepast veld en elk rapport waar iemand van afhankelijk is in een lijst, met de vulgraad en de datum waarop het voor het laatst is gebruikt. Markeer de velden die niemand gebruikt als kandidaat om te verwijderen, want goedkoper dan tijdens een migratie kom je er nooit meer van af. Onze gids over CRM-databaseontwerp beschrijft wat het datamodel van het nieuwe systeem moet kunnen dragen.

Beantwoord daarna schriftelijk hoeveel historie je meeneemt. Hoe ver ga je terug met cases, activiteiten, campagnes, contracten en bijlagen, en wat archiveer je in plaats daarvan? Dat ene antwoord bepaalt het volume, de planning en de toolkeuze. Spreek per record type met legal en finance een bewaartermijn af, in plaats van standaard alles te bewaren. Leg het antwoord vast, laat het aftekenen en ga door, want er in maand vier nog over discussiëren kost weken.

Bepaal per proces of je het ongewijzigd migreert of herontwerpt

Dit is de beslissing met de grootste gevolgen in elke Salesforce- of HubSpot-migratie. Wie halverwege besluit een complex proces te herontwerpen, maakt alles op alle fronten complexer. Nieuwe velden leggen oude beslissingen over automatisering weer op tafel, nieuwe automatisering doet hetzelfde met beslissingen over rapportage, en ongemerkt wordt de migratie een herimplementatie.

In onze Five Dots-kennisbank gebruiken we daarvoor een eenvoudige triage. Loop de klantreis van begin tot eind door met de mensen die de processen uitvoeren en geef elk proces één kleur.

• Groene processen migreren zoals ze zijn, want ze werken en de gebruikers zijn tevreden.
• Gele processen kloppen in principe en hebben kleine aanpassingen nodig, zoals eenvoudigere record types, goedkeuringen of velden.
• Rode processen passen niet bij hoe het bedrijf werkt en vragen om een workshop met gebruikers voordat er iets wordt gebouwd.
• Grijze processen horen helemaal niet in het CRM thuis en gaan naar het product of een andere tool, of verdwijnen.

Werk daarna in twee sporen. Het ene spoor migreert de groene en gele processen snel, zodat de kern staat. Het andere spoor herontwerpt de rode processen in workshops met gebruikers. Een deel van de rode processen haalt de deadline niet. Benoem die, houd een tijdelijke workaround aan en plan ze in voor na de cutover, in plaats van haastig een zwak ontwerp door te drukken. Leg elke keuze vast in één zin, bijvoorbeeld "lead routing migreert ongewijzigd, de dealfases worden herontworpen, de workflow voor verlengingen migreert ongewijzigd." Wie moeilijke keuzes ontwijkt, zodat alles op geel uitkomt, schuift het herontwerp alleen maar door naar de bouwfase.

Met "dat zoeken we later wel uit" wordt een project van zes maanden een project van twaalf maanden.

Leg een development freeze op het oude CRM schriftelijk vast

Zodra de voorbereiding van de migratie begint, moet nieuwe ontwikkeling in het bronsysteem stoppen. Dat geldt voor aangepaste velden, automatiseringen, layouts, aanpassingen aan integraties, validation rules en page layouts. Anders migreer je een systeem dat onder je handen blijft veranderen.

Spreek de datum van de freeze vooraf af met elk team dat ermee te maken krijgt. Alles wat na de freeze wordt gebouwd, valt buiten de migratie. Komt er toch een echt dringende wijziging, laat die dan via change control lopen, met één eigenaar en schriftelijk vastgelegde goedkeuringen. Informeel even iets toevoegen na de freeze kost meer aan testtijd dan de wijziging zelf.

Betrek compliance, legal en finance al tijdens de discovery

Teams die bij het bepalen van de scope zijn overgeslagen, melden zich in de laatste week, als wijzigingen het meeste kosten. Finance, legal en compliance komen steevast laat met eisen. Denk aan audits die leunen op data van opportunities, aparte objecten voor overeenkomsten die legal gebruikt, definities van ARR-velden die afwijken van wat RevOps aanneemt, en bewaarregels die voortkomen uit wettelijke verplichtingen. Elk daarvan los je in week twee goedkoop op en in week twintig duur.

Organiseer tijdens de discovery een workshop over de eisen van compliance en legal. Breng elk gereguleerd data-element in kaart en leg vast wie de eigenaar is. Houd een stakeholderlijst bij waar ook de stille teams op staan, niet alleen de teams die bij de kickoff aanwezig waren.

Licht elke automatisering door voordat je een record verplaatst

In de meeste CRM's zit jaren aan ongedocumenteerde automatisering. Workflows van iemand die twee jaar geleden is vertrokken, draaien nog steeds in productie en passen ongemerkt records aan.

Inventariseer alles, van workflows, assignment rules, validation rules en scoringslogica tot veldtriggers, inschrijvingen in sequences en integraties van derden. Leg per automatisering vast wat ze doet, waarom ze bestaat, wie ze heeft gebouwd, wanneer ze voor het laatst is gewijzigd en hoe kritiek ze is. Neem daarna per automatisering één besluit.

• Ongewijzigd migreren.
• Opnieuw bouwen voor het nieuwe platform.
• Uitfaseren.

Automatiseringen die "waarschijnlijk nog wel iets nuttigs doen" en standaard worden gemigreerd, nemen hun complexiteit mee naar het nieuwe systeem, waar die nooit wordt opgelost. Let op automatiseringen waarvan de voorwaarden specifieke record types noemen, want die gaan allemaal stuk zodra je record types samenvoegt. Begroot het herbouwen als een eigen werkstroom. Logica die je op het ene platform in vijf minuten instelde, vraagt op het andere vaak een andere aanpak, dus dit is geen klus voor de laatste sprint. Draaien HubSpot en Salesforce een tijd naast elkaar, dan beschrijft onze gids over de integratie van HubSpot en Salesforce wat je moet voorbereiden voordat je ze koppelt.

Behandel deduplicatie als werkstroom, niet als opruimklus in de laatste week

Dubbele data is altijd erger dan verwacht, en als je meerdere systemen samenvoegt, stapelen de duplicaten zich op. Bij klanten zagen we pieken in duplicaten die terug te voeren waren op een eerdere massamigratie en op uploads van target accounts, dus het opschonen begint vaak bij wat het vorige project heeft achtergelaten.

De volgorde doet ertoe. Schoon eerst elke bron afzonderlijk op en los daarna de verschillen in de gecombineerde dataset op. Sla je de eerste stap over, dan krijg je samengevoegde duplicaten met tegenstrijdige veldwaarden die achteraf niemand meer ontward krijgt. Match op meer dan alleen namen. Gebruik domeinen en relaties tussen bedrijven, en behoud bij het samenvoegen de activiteitenhistorie en de koppelingen tussen contactpersonen en accounts.

Zoek uit hoe het nieuwe platform zich bij een import gedraagt. HubSpot ontdubbelt bij een import bijvoorbeeld contacten op e-mailadres en bedrijven op domeinnaam, maar bedrijven die via de API worden aangemaakt, ontdubbelt het niet op domein. Een laadscript dat dat verschil negeert, maakt precies de duplicaten aan die je net hebt opgeschoond. Onze uitleg over een CRM bijwerken met Python zonder duplicaten aan te maken laat de matchinglogica in de praktijk zien.

Richt deduplicatie in als een aparte werkstroom met een naam, een eigenaar, een planning en een heldere definition of done.

Stem de beveiligings- en toegangsmodellen af voordat je gaat testen

Een strikt afgeschermd model op basis van salesgebieden en een open model op basis van rollen kun je niet zomaar samenvoegen. Doe je alsof dat wel kan, dan krijg je een testfase waarin de helft van de gebruikers hun eigen records niet ziet en de andere helft alles.

Organiseer in de discovery een workshop over het beveiligingsmodel. Zet de toegangsmodellen van de systemen naast elkaar, benoem de conflicten, kies een doelmodel en leg de beslissing en het migratiepad vast. Doe dit voordat het testen begint. Het sharing model beïnvloedt ook hoe snel je kunt laden. In de module Large Data Volumes op Trailhead legt Salesforce uit dat de deelrechten opnieuw worden berekend als je records toevoegt onder een private sharing model, en dat vertraagt grote loads.

Plan de laadvolgorde en de regels die je uitschakelt

Data heeft afhankelijkheden. In Salesforce kun je child records pas laden als hun parent records bestaan, en de gebruikers die eigenaar zijn van records moeten bestaan voordat hun data binnenkomt. Importeer parent records vóór child records, houd een mapping bij van oude naar nieuwe record-ID's, en onthoud dat records met automatische nummering, zoals cases en contracten, hun nummer krijgen in de volgorde waarin je ze importeert. Gaat dat mis, dan zitten er gaten in de reeks die veel tijd kosten om te herstellen. Bestanden, bijlagen en kennisartikelen zijn meestal het traagste deel, dus check of ze echt nodig zijn voordat je ze migreert.

Teams schakelen vaak validation rules, assignment rules en triggers uit om een grote load te versnellen, zoals dezelfde Trailhead-module ook beschrijft. Dat is prima, zolang de stap om ze weer aan te zetten op de checklist staat. Regels die tijdens de load uitgeschakeld waren, moet je systematisch weer inschakelen, en daarna toets je de data aan die regels, want records die de validatie hebben overgeslagen, repareren zichzelf niet.

Bescherm de testtijd en werk met één UAT-template

Loopt een migratie uit, dan wordt er als eerste op testen beknibbeld. Dat zou niet moeten. Loopt de datamigratie uit, dan schuift de go-live op en blijft de testtijd staan. Leg dat als afspraak in de governance vast voordat het project begint, niet als discussie die je verliest zodra de planning uitloopt. Reserveer ruim voor de cutover gebruikerslicenties en tijd voor de gebruikersacceptatietest.

Twee valkuilen bij het testen noemen we apart. Staging is geen productie. Layouts, validation rules, gebruikersprofielen en uitgeschakelde workflows lopen tussen omgevingen uit elkaar, dus houd een changelog bij van staging naar productie en loop die door vóór elke go-live-checklist. En UAT heeft één template nodig. Als blijkt dat één team een uitstekend template heeft terwijl de rest improviseerde, heeft de kwaliteitscontrole gefaald. Standaardiseer het template bij de kickoff, met objecten, velden, automatiseringen, integraties en gebruikersrollen, en pas het bij elk team op dezelfde manier toe.

Maak meer dan één keer een back-up van data en configuratie

Eén back-up bij de kickoff is geen back-upstrategie. Maak gedurende het hele project exports op vaste controlepunten, elk met een eigen naam.

• Een basisexport vóór de migratie, met data en configuratie apart geëxporteerd.
• Een export na de deduplicatie.
• Een export na het laden van elke objectgroep.
• Een laatste export vóór de go-live.

Geef elke export een datum en een omschrijving. Dat zijn je herstelpunten als er verderop iets stukgaat.

Data en configuratie hebben aparte back-ups nodig. Een data-export dekt geen automatiseringen, velddefinities, page layouts of rechten. De ingebouwde Data Export Service van Salesforce maakt bijvoorbeeld een ZIP-archief met CSV-bestanden en kan eens per 7 dagen draaien voor een wekelijkse export of eens per 29 dagen voor een maandelijkse, met bijlagen alleen als je die selecteert. Ingeplande standaardexports in afgeschermde gedeelde opslag kunnen genoeg zijn als je eisen aan herstel bescheiden zijn. Gespecialiseerde back-uptools maken vooral het terugzetten makkelijker.

Test het terugzetten. Een back-up die je nooit hebt teruggezet, is een back-up die je eigenlijk niet hebt, dus zet als proef een deel van de basisexport terug voordat je het nodig hebt. Bewaar exports op een gedeelde locatie met toegangsbeheer en een naamgeving die ook werkt als de projectleider op vakantie is op het moment dat er een incident is.

Neem zichtbare buffer op in de planning en zet Plan B op papier

Ervaren projectleiders van CRM-implementaties wantrouwen een al te ambitieuze go-live, en terecht. Bepaalt de vervaldatum van een licentie je deadline, reken dan terug vanaf die datum en houd weken, geen dagen, ruimte tussen de geplande cutover en het aflopen van de licentie, voor vertraging, fixes en support. Benoem die buffer expliciet in de planning. Verborgen buffer gaat op aan optimisme, benoemde buffer blijft overeind.

Kies de datum van de cutover met de salesagenda in je achterhoofd. Stap over wanneer de druk op sales het laagst is, vaak direct na een kwartaalafsluiting, en niet in de laatste weken van een kwartaal. Houd na de cutover een tijdje een klein aantal licenties op het oude systeem aan, alleen-lezen, zodat mensen nog bij de historie kunnen terwijl het nieuwe systeem nog landt.

Zet vóór de go-live Plan B op papier. Wat doe je als je de freeze moet verlengen, de go-live moet uitstellen, alvast de niet-kritieke objecten migreert en de rest laat wachten, of de scope moet verkleinen? Bepaal de criteria nu, leg ze vast en deel ze met de stuurgroep voordat de beslissing er echt toe doet.

Wil je hulp bij het inrichten van die eerste 30 dagen? Onze implementaties van HubSpot en Salesforce beginnen met discovery, het datamodel en het migratieplan, die we samen met je eigen team opzetten.

Houd één besluitenlogboek bij en zorg dat iedereen het gebruikt

Besluiten die in vergaderingen worden genomen, moeten worden vastgelegd, en iedereen moet daarvoor dezelfde plek gebruiken. Notion, Confluence, Jira of één gedeeld document werken allemaal, want de tool doet er minder toe dan de discipline. Kies er één, spreek bij de kickoff de werkwijze af en wijs iemand aan die erop toeziet. Een besluit is pas rond als het is vastgelegd.

Staan besluiten verspreid over drie tools, twee Slack-threads en het hoofd van één persoon, dan worden ze steeds opnieuw ter discussie gesteld, en besluiten die telkens weer ter discussie staan, zijn de doodsteek voor elke planning. Leg de beslissingsbevoegdheid daarnaast bij een klein kernteam. Brede goedkeuringsrondes vertragen elk besluit, en traag besluiten is het grootste risico in een migratie.

Waarom fouten bij een CRM-migratie terug te voeren zijn op de eerste 30 dagen

Elke les hier heeft dezelfde oorzaak. Beslissingen die in de eerste 30 dagen thuishoren, worden pas in de laatste 30 dagen genomen. Discovery, historie en bewaartermijnen, migreren of herontwerpen, de freeze, de inventaris van automatiseringen, het stakeholderoverzicht, het beveiligingsmodel, de laadvolgorde, back-ups, buffer, Plan B en één besluitenlogboek horen allemaal aan het begin.

Regel ze voordat iemand een record aanraakt, en de migratie wordt eenvoudiger. Kies je nog een platform, lees dan eerst onze vergelijking van HubSpot en Salesforce. Begin je dit kwartaal aan een migratie, boek dan een gesprek en we helpen je de eerste 30 dagen te plannen.

FAQ over CRM-migratie

Wat moet er in de eerste 30 dagen van een CRM-migratie gebeuren?

In de eerste 30 dagen leg je de scope en de historie vast, per proces de keuze tussen migreren en herontwerpen, de development freeze, de inventaris van automatiseringen, het overzicht van stakeholders en compliance, het beveiligingsmodel en het back-upplan. Bouwen en laden komen na die beslissingen, niet ervoor.

Moeten we alle historische data naar het nieuwe CRM migreren?

Meestal niet. Spreek met legal en finance per record type af hoe ver je teruggaat, migreer wat mensen echt gebruiken en archiveer de rest in afgeschermde opslag waar je het nog kunt terughalen.

Moeten we ontdubbelen vóór of na een CRM-migratie?

Ontdubbel vóór en tijdens de migratie. Schoon eerst elk bronsysteem op en los daarna de verschillen in de gecombineerde dataset op, zodat je geen samengevoegde duplicaten met tegenstrijdige waarden in het nieuwe CRM laadt.

Wat is een development freeze bij een CRM-migratie?

Een development freeze is de datum waarna niemand meer nieuwe velden, automatiseringen, layouts of integraties bouwt in het oude CRM. Iets dringends gaat via change control, met één eigenaar en een schriftelijke goedkeuring, zodat het team geen systeem migreert dat intussen nog verandert.

Wanneer stap je het best over op een nieuw CRM?

Stap over wanneer de druk op sales het laagst is, en dat is vaak direct na een kwartaalafsluiting. Plan een buffer van weken vóór de vervaldatum van een licentie, en houd na de go-live nog een tijd alleen-lezentoegang tot het oude systeem.

Wat hoort er in een back-up voor een CRM-migratie?

Een back-up voor een migratie bevat data en configuratie, apart geëxporteerd, op meerdere controlepunten. Maak een basisexport vóór de migratie, daarna exports na de deduplicatie, na elke load en vóór de go-live, en test het terugzetten van de basisexport voordat je het nodig hebt.