Go-live & adoptie
Datamigratie & cleanup
Welke historie verhuist mee naar Gfacility, wat dump je, wat archiveer je — en hoe valideer je dat alles correct landt? Zonder cleanup pak je het oude rommeltje gewoon mee naar het nieuwe huis.
Bijgewerkt op 18 mei 2026
Go-live · 5.1
Waarom dit eerst
Migratie en cleanup zijn onlosmakelijk verbonden. “Alles overnemen” klinkt veilig — tot je Gfacility opstart met 14.000 tickets uit 2017 waarvan niemand weet wat de status nog betekent. Slechte data importeren maakt elke rapportage onbetrouwbaar én elke AI-suggestie onbruikbaar. Eerst opschonen, dan migreren.
Wat lever je op?
Migratiematrix
Per bron-entiteit: doel-entiteit, transformatieregels, peildatum, scope.
Cleanup-actielijst
Duplicaten, stale records, foute referenties — wie ruimt wat op vóór migratie?
Archief-strategie
Wat ga je niet migreren, en hoe blijft het bij bewaarplicht toch terugvindbaar?
Droogloop-rapport
Resultaat van minimaal twee droogloopruns: aantallen, mismatches, runtime.
De vijf entiteit-families
Migratie loopt altijd langs dezelfde stappen, ongeacht het bronsysteem:
Masterdata
Gebruikers, organisaties, locaties, kostenplaatsen. Eerst, want alle andere entiteiten verwijzen ernaar.
Configuratie
Classificaties, custom velden, werkgroepen, workflows. Manueel of via export — meestal niet erg veel volume.
Transactionele data
Open tickets, lopende boekingen, geplande taken. Klein volume, hoge waarde — alles meeneemen.
Historie
Gesloten tickets, oude boekingen. Beslis welke periode (12 of 24 maanden) en hoe je rapportagelijn behoudt.
Kennisbank
Artikelen, FAQ's, sjablonen. Vaak kans om meteen op te schonen en te herstructureren.
Bijlagen
Foto's, PDF's, documenten gekoppeld aan tickets en assets. Meestal het zwaarst in volume.
Kernvragen
- 1Welke bronsystemen bevatten data die naar Gfacility moet — TOPdesk, ServiceNow, Excel-lijsten, eigen tooling, Outlook-resources?
- 2Scope-grenzen per entiteit — alleen actieve records, alleen laatste 24 maanden, alleen specifieke afdelingen?
- 3Cleanup vóór migratie — wie ruimt duplicaten op, beëindigt slapende gebruikers, sluit "weeskind" tickets zonder eigenaar?
- 4Transformatieregels — hoe map je oude categorieën op nieuwe classificaties? Wat doet "onbekend"?
- 5Bijlagen-strategie — meeverhuizen, op aparte opslag, of alleen-op-aanvraag terughalen vanuit archief?
- 6Peildatum & freeze — wanneer wordt de bron "bevroren" (geen wijzigingen meer) en wat doe je met nieuwe records die tussentijds binnenkomen?
- 7Validatie — welke checks doe je na migratie (totalen, steekproeven, signature-records die handmatig zijn nagekeken)?
- 8Archiefoplossing — voor data die niet meekomt: blijft de oude tool nog read-only? Met welke bewaartermijn, eigenaar en toegangsmodel?
- 9Herhaalbaarheid — kan je de migratie minimaal twee keer drooglopen vóór de echte cutover? Idempotent (uitvoering verandert niets bij herhaling)?
- 10GDPR-impact — neem je persoonsgegevens mee waarvoor de retentietermijn al verlopen is? DPO checkt vóór migratie.
Template — Migratiematrix per entiteit
| Entiteit | Bron | Volume | Scope | Cleanup-actie | Eigenaar | Validatie |
|---|---|---|---|---|---|---|
| Gebruikers | Entra ID | ~2.400 | Actief (90d login) | Slapenden deactiveren | IT-Identity | Totaal +/- 1% |
| Locaties | Excel + M365 Rooms | ~180 | Alle reserveerbare | Capaciteit re-validatie | FM | Manuele check 100% |
| Open tickets | TOPdesk | ~340 | Alle open | Sluiten > 6m oud | Service Manager | Steekproef 50 stuks |
| Gesloten tickets | TOPdesk | ~14.200 | Laatste 24m | PII redactie > 12m | Service Manager + DPO | Maand-totalen |
| Boekingen historie | M365 | ~85.000 | Laatste 12m | Geen — read-only | Workplace-lead | Aggregaten |
| KB-artikelen | SharePoint wiki | ~220 | Top-150 meest gelezen | Herschrijven + taggen | Service Manager | Inhoudelijke review |
| … | … | … | … | … | … | … |
Stappen
- 1Bronsystemen inventariseren en per entiteit een verantwoordelijke benoemen.
- 2Cleanup-sprints uitvoeren — duplicaten, slapenden, ouder dan bewaartermijn. Liever in de bron dan tijdens migratie.
- 3Transformatiemapping schrijven: bron-veld → Gfacility-veld, met expliciete regels voor "onbekend" en "leeg".
- 4Eerste droogloop op acceptatie-omgeving, met verwacht volume — alleen om aantallen, runtime en fouten te meten.
- 5Fouten oplossen, mapping aanscherpen, en cleanup-acties terugkoppelen naar bron.
- 6Tweede droogloop met representatieve cleanup-staat — eindgebruikers checken steekproef.
- 7Archief-strategie afspreken — bron blijft read-only 12 maanden, daarna export naar koude opslag.
- 8Go/no-go-rapport opleveren aan stuurgroep: aantallen kloppen, fouten < X, sign-off door entiteit-eigenaars.