Zo laat je een Salesforce-datamigratie wel slagen

Kort antwoord: een Salesforce-datamigratie wordt beslist in de datakwaliteitsfase, weken voor de laaddag. Profileer de brondata, bepaal bewust wat je niet meeneemt, breng elk veld in kaart met een external ID erachter, en repeteer de cutover tot hij saai is. Laden is het makkelijke deel, en het is bijna nooit wat misgaat.

Waarom mislukken Salesforce-datamigraties echt?

Zelden door het laden. Data Loader, de Bulk API en de ETL-tools werken gewoon. Mislukkingen zijn terug te voeren op beslissingen die eerder zijn ontweken:

• Geen aangewezen eigenaar voor een datadomein, dus niemand kon een regel goedkeuren.
• Duplicaten die iedereen zag en waarover niemand afspraken maakte.
• Een bronveld waarvan de betekenis jaren geleden verschoof en dat op zijn label werd gemapt.
• Een scope die stilletjes "alles" werd, omdat niets weglaten veiliger voelde dan kiezen.

Alle vier zijn goedkoop op te lossen in week twee en genadeloos in de nacht van de cutover. Dat is het hele argument om datakwaliteit naar voren te halen.

Wat betekent profileren hier eigenlijk?

Profileren is meten, niet rondkijken. Voordat iemand een mappingregel schrijft, lever je cijfers per bronobject:

• Vulgraad per veld. Een veld dat in 4% van de records gevuld is, is geen veld maar een gerucht.
• Unieke waarden tegenover de doelpicklist. Hier worden "Prospect", "prospect" en "PROSPECT " drie waarden en een discussie.
• Duplicaatpercentage op de beoogde matchingsleutel. Meet dat voordat je de sleutel kiest, niet erna.
• Percentage wezen per relatie. Kindrecords zonder oplosbare ouder bepalen je laadvolgorde en je foutvolume.
• Oplospercentage van eigenaars. Welk deel van de records verwijst naar een actieve Salesforce-gebruiker, en wie krijgt de rest.
• Datumbereiken en uitschieters. Records met 1900 of 2099 vallen op het slechtst denkbare moment over een validatieregel.

De uitkomst is een kort profielrapport. Zijn echte taak is meningen omzetten in cijfers, zodat scopegesprekken eindigen in een besluit in plaats van een vergadering.

Wat besluit je niet mee te nemen?

Dit is de beslissing met de meeste hefboom en die de meeste plannen overslaan. Elk record heeft vier mogelijke bestemmingen, en maar een ervan is duur:

1. Migreren. Het is operationeel nodig, in Salesforce, door een benoemd proces.
2. Samenvatten. De historie telt als totaal, niet regel voor regel. Laad een rollup, geen tien jaar transacties.
3. Archiveren. Bewaar het in een warehouse of als export voor compliance, buiten het CRM.
4. Laten staan. Houd het oude systeem een afgesproken periode read-only beschikbaar zodat mensen dingen kunnen opzoeken.

Verstandige uitgangspunten: gesloten records ouder dan je rapportagehorizon worden samengevat, contacten zonder activiteit en zonder bereikbaar e-mailadres worden gearchiveerd, en vrije tekstvelden waarop niemand rapporteert komen helemaal niet mee. Elk record dat je uitsluit scheelt mappingwerk, validatiefouten, testgevallen en support na livegang. Minder scope is de goedkoopste prestatiewinst die er is.

Hoe bouw je een mapping die het contact met de data overleeft?

Een regel per doelveld, en elke regel bevat: bronveld, transformatieregel, standaardwaarde, eigenaar, de validatie die het moet doorstaan, en de datum waarop het besluit is bekrachtigd. Heeft een regel geen eigenaar, dan is het geen mapping maar een hoop.

Twee technische keuzes bepalen hoe rustig de rest van het project verloopt:

• Zet een external ID op elk object dat je laadt. Die draagt de sleutel uit het oude systeem, waardoor ouder-kindrelaties zonder Salesforce-ID's oplossen, laden via upsert idempotent wordt en opnieuw draaien veilig is. Zonder external ID riskeer je bij elke herstart duplicaten.
• Kies de matchingsleutel voordat je een transformatie schrijft. E-mail, fiscaal nummer, oud ID of een samengestelde sleutel. Het profielrapport vertelt welke daarvan in jouw data echt uniek is.

Leg daarna schriftelijk vast welke automatisering tijdens het laden uitstaat en wie hem weer aanzet: validatieregels, triggers, flows, toewijzingsregels, duplicaatregels en e-mailmeldingen. Een onbedoelde welkomstmail aan 40.000 gemigreerde contacten is de klassieke versie van deze fout.

Hoeveel dry runs, en wat meet je?

Minimaal drie, in een sandbox die op productie lijkt.

1. Vormrun. Laadt het uberhaupt? Veldtypes, verplichte velden, picklistwaarden, recordtypes.
2. Correctheidsrun. Valideer relaties in plaats van aantallen. Kloppende totalen met gebroken ouders is de meest geruststellende manier waarop dit misgaat.
3. Getimede run. Volledig volume, van begin tot eind gemeten, zodat het cutovervenster een waargenomen getal is en geen schatting.

Bewaar elk foutenlogboek en behandel het foutpercentage als een trend. Is run drie niet duidelijk schoner dan run een, dan convergeert de mapping niet en is de livedatum fictie.

Wat hoort er in het cutoverplan?

Een cutoverplan is een reeks met kloktijden en een eigenaar per regel, geen verhaal:

1. Bevries het bronsysteem en kondig de bevriezing aan bij gebruikers, niet alleen in het projectkanaal.
2. Maak de laatste delta-extractie.
3. Zet de automatisering op de afgesproken lijst uit.
4. Laad ouders voor kinderen, in de vastgelegde volgorde, in golven die fouten isoleren.
5. Zet de automatisering weer aan en bevestig per item dat hij terug is.
6. Draai reconciliatiequeries: aantallen per object, wezencontroles, steekproeven op records die de business vooraf heeft aangewezen.
7. Akkoord vanuit de business op die records, daarna go of no-go.
8. Ontdooien, of de rollback uitvoeren.

Definieer de rollback voor de cutovernacht, wanneer het nog een ontwerpvraag is en geen paniek. In de praktijk betekent dat: houd het oude systeem leidend en read-only tot de akkoordverklaring, en houd op elk gemigreerd record een external ID zodat een gerichte verwijdering of een volledige herlading mogelijk blijft. Bemens daarna de eerste 48 tot 72 uur fatsoenlijk, want de vragen van dag een laten zien wat het profielrapport gemist heeft.

Wij doen migraties op deze manier binnen onze Salesforce-trajecten, en dat is mede hoe we 16+ organisaties live in productie hebben gebracht. Ben je er een aan het afbakenen en wil je een tweede mening over de data voordat er een datum vastligt, begin dan hier.

FAQ

Hoe lang duurt een Salesforce-datamigratie?

Het laden duurt uren. Het project duurt zo lang als de datakwaliteitsbesluiten duren, en daarom moet de getimede dry run je cutovervenster bepalen, niet de planning.

Schonen we de data in het bronsysteem of tijdens het laden?

Waar mogelijk in de bron, waar de eigenaars zitten. Transformatieregels in een laadscript zijn onzichtbaar voor de business en worden na livegang opnieuw ter discussie gesteld.

Hebben we external IDs nodig als we maar een keer migreren?

Ja. Ze maken herstarts veilig, lossen relaties op zonder Salesforce-ID's en maken later een rollback of gerichte herlading mogelijk.

Hoeveel historie nemen we mee?

Alleen wat een benoemd proces of rapport gebruikt. Vat de rest samen en archiveer het overige buiten het CRM: historie is in dit soort projecten de meest voorkomende bron van scope creep.