Go-live & adoption
Data migration & cleanup
Which history moves to Gfacility, what do you dump, what do you archive — and how do you validate that everything lands correctly? Skip the cleanup and you bring the old mess into the new house.
Updated May 18, 2026
Go-live · 5.1
Why this first
Migration and cleanup are inseparable. “Migrate everything” sounds safe — until you start Gfacility with 14,000 tickets from 2017 whose status no one understands anymore. Importing bad data makes every report unreliable and every AI suggestion useless. Clean up first, then migrate.
What do you deliver?
Migration matrix
Per source entity: target entity, transformation rules, reference date, scope.
Cleanup action list
Duplicates, stale records, broken references — who cleans up what before migration?
Archive strategy
What you don't migrate, and how it stays retrievable under retention obligations.
Dry-run report
Result of at least two dry-run executions: counts, mismatches, runtime.
The five entity families
Migration always follows the same steps, regardless of the source system:
Master data
Users, organisations, locations, cost centres. First, because all other entities reference them.
Configuration
Classifications, custom fields, work groups, workflows. Manual or via export — usually not a lot of volume.
Transactional data
Open tickets, current bookings, planned tasks. Low volume, high value — bring it all.
History
Closed tickets, old bookings. Decide which period (12 or 24 months) and how you preserve your reporting line.
Knowledge base
Articles, FAQs, templates. Often a chance to clean up and restructure right away.
Attachments
Photos, PDFs, documents linked to tickets and assets. Usually the heaviest in volume.
Key questions
- 1Which source systems contain data that must go to Gfacility — TOPdesk, ServiceNow, Excel lists, in-house tooling, Outlook resources?
- 2Scope boundaries per entity — only active records, only the last 24 months, only specific departments?
- 3Cleanup before migration — who removes duplicates, deactivates dormant users, closes "orphan" tickets without an owner?
- 4Transformation rules — how do you map old categories to new classifications? What does "unknown" do?
- 5Attachment strategy — migrate along, separate storage, or fetch on-demand from archive?
- 6Reference date & freeze — when does the source get "frozen" (no more changes) and what do you do with new records that arrive in the meantime?
- 7Validation — which checks do you run after migration (totals, samples, signature records reviewed manually)?
- 8Archive solution — for data that doesn't come along: does the old tool stay read-only? With which retention period, owner and access model?
- 9Repeatability — can you dry-run the migration at least twice before the real cutover? Idempotent (re-running changes nothing)?
- 10GDPR impact — are you carrying personal data whose retention period has already expired? DPO checks before migration.
Template — Migration matrix per entity
| Entity | Source | Volume | Scope | Cleanup action | Owner | Validation |
|---|---|---|---|---|---|---|
| Users | Entra ID | ~2,400 | Active (90d login) | Deactivate dormant | IT-Identity | Total +/- 1% |
| Locations | Excel + M365 Rooms | ~180 | All bookable | Capacity re-validation | FM | Manual check 100% |
| Open tickets | TOPdesk | ~340 | All open | Close > 6m old | Service Manager | Sample of 50 |
| Closed tickets | TOPdesk | ~14,200 | Last 24m | PII redaction > 12m | Service Manager + DPO | Monthly totals |
| Booking history | M365 | ~85,000 | Last 12m | None — read-only | Workplace lead | Aggregates |
| KB articles | SharePoint wiki | ~220 | Top-150 most read | Rewrite + tag | Service Manager | Content review |
| … | … | … | … | … | … | … |
Steps
- 1Inventory source systems and assign a responsible per entity.
- 2Run cleanup sprints — duplicates, dormant accounts, older than retention. Better in the source than during migration.
- 3Write transformation mapping: source field → Gfacility field, with explicit rules for "unknown" and "empty".
- 4First dry run on the acceptance environment, with expected volume — only to measure counts, runtime and errors.
- 5Fix errors, tighten mapping, and feed cleanup actions back to the source.
- 6Second dry run with representative cleanup state — end users check a sample.
- 7Agree archive strategy — source stays read-only for 12 months, then export to cold storage.
- 8Deliver go/no-go report to steering committee: counts match, errors < X, sign-off by entity owners.