Go-live & Einführung
Datenmigration & Bereinigung
Welche Historie zieht nach Gfacility um, was werfen Sie weg, was archivieren Sie, und wie validieren Sie, dass alles korrekt ankommt? Sparen Sie die Bereinigung, bringen Sie das alte Chaos ins neue Haus.
Aktualisiert am 18. Mai 2026
Go-live · 5.1
Warum das zuerst
Migration und Bereinigung sind untrennbar. „Alles migrieren” klingt sicher, bis Sie Gfacility mit 14.000 Tickets aus 2017 starten, deren Status niemand mehr versteht. Schlechte Daten zu importieren macht jeden Bericht unzuverlässig und jeden KI-Vorschlag nutzlos. Erst bereinigen, dann migrieren.
Was liefern Sie?
Migrationsmatrix
Pro Quellentität: Zielentität, Transformationsregeln, Stichtag, Scope.
Bereinigungs-Aktionsliste
Duplikate, veraltete Datensätze, gebrochene Referenzen, wer bereinigt was vor der Migration?
Archivstrategie
Was Sie nicht migrieren, und wie es unter Aufbewahrungspflichten abrufbar bleibt.
Dry-Run-Bericht
Ergebnis von mindestens zwei Dry-Run-Durchläufen: Zählwerte, Abweichungen, Laufzeit.
Die fünf Entitätsfamilien
Migration folgt immer denselben Schritten, unabhängig vom Quellsystem:
Stammdaten
Nutzer, Organisationen, Standorte, Kostenstellen. Zuerst, weil alle anderen Entitäten darauf verweisen.
Konfiguration
Klassifizierungen, Custom Fields, Workgroups, Workflows. Manuell oder per Export, meist wenig Volumen.
Transaktionsdaten
Offene Tickets, laufende Buchungen, geplante Aufgaben. Wenig Volumen, hoher Wert, alles mitnehmen.
Historie
Geschlossene Tickets, alte Buchungen. Entscheiden Sie, welcher Zeitraum (12 oder 24 Monate) und wie Sie Ihre Berichtslinie erhalten.
Wissensdatenbank
Artikel, FAQs, Vorlagen. Oft eine Gelegenheit, gleich aufzuräumen und umzustrukturieren.
Anhänge
Fotos, PDFs, Dokumente verknüpft mit Tickets und Assets. Meist das volumenstärkste Element.
Kernfragen
- 1Welche Quellsysteme enthalten Daten, die nach Gfacility müssen, TOPdesk, ServiceNow, Excel-Listen, Eigenentwicklungen, Outlook-Ressourcen?
- 2Scope-Grenzen pro Entität, nur aktive Datensätze, nur die letzten 24 Monate, nur bestimmte Abteilungen?
- 3Bereinigung vor Migration, wer entfernt Duplikate, deaktiviert ruhende Nutzer, schließt „verwaiste" Tickets ohne Owner?
- 4Transformationsregeln, wie mappen Sie alte Kategorien auf neue Klassifizierungen? Was passiert bei „unbekannt"?
- 5Anhangstrategie, mitmigrieren, separates Storage oder On-Demand aus dem Archiv abrufen?
- 6Stichtag & Freeze, wann wird die Quelle „eingefroren" (keine Änderungen mehr) und was machen Sie mit neuen Datensätzen, die in der Zwischenzeit eintreffen?
- 7Validierung, welche Checks führen Sie nach der Migration aus (Summen, Stichproben, signaturrelevante Datensätze manuell geprüft)?
- 8Archivlösung, für Daten, die nicht mitkommen: Bleibt das alte Tool read-only? Mit welcher Aufbewahrungsfrist, Owner und Zugriffsmodell?
- 9Wiederholbarkeit, können Sie die Migration mindestens zweimal vor dem echten Cutover als Dry Run fahren? Idempotent (erneutes Ausführen ändert nichts)?
- 10DSGVO-Auswirkung, schleppen Sie personenbezogene Daten mit, deren Aufbewahrungsfrist bereits abgelaufen ist? DSB prüft vor der Migration.
Vorlage — Migrationsmatrix pro Entität
| Entität | Quelle | Volumen | Scope | Bereinigungsaktion | Owner | Validierung |
|---|---|---|---|---|---|---|
| Nutzer | Entra ID | ~2.400 | Aktiv (90 Tage Login) | Ruhende deaktivieren | IT-Identity | Summe +/- 1% |
| Standorte | Excel + M365 Rooms | ~180 | Alle buchbaren | Kapazitätsneuvalidierung | FM | Manuelle Prüfung 100% |
| Offene Tickets | TOPdesk | ~340 | Alle offenen | > 6 Mon. alte schließen | Service Manager | Stichprobe von 50 |
| Geschlossene Tickets | TOPdesk | ~14.200 | Letzte 24 Mon. | PII-Redaktion > 12 Mon. | Service Manager + DSB | Monatssummen |
| Buchungshistorie | M365 | ~85.000 | Letzte 12 Mon. | Keine, read-only | Workplace-Lead | Aggregate |
| KB-Artikel | SharePoint-Wiki | ~220 | Top-150 meistgelesen | Neu schreiben + taggen | Service Manager | Content-Review |
| … | … | … | … | … | … | … |
Schritte
- 1Quellsysteme inventarisieren und einen Verantwortlichen pro Entität zuweisen.
- 2Bereinigungs-Sprints durchführen, Duplikate, ruhende Konten, älter als Aufbewahrungsfrist. Besser in der Quelle als während der Migration.
- 3Transformations-Mapping schreiben: Quellfeld → Gfacility-Feld, mit expliziten Regeln für „unbekannt" und „leer".
- 4Erster Dry Run auf der Abnahmeumgebung, mit erwartetem Volumen, nur um Zählwerte, Laufzeit und Fehler zu messen.
- 5Fehler beheben, Mapping schärfen und Bereinigungsaktionen an die Quelle zurückspielen.
- 6Zweiter Dry Run mit repräsentativem Bereinigungsstand, Endnutzer prüfen Stichproben.
- 7Archivstrategie vereinbaren, Quelle bleibt 12 Monate read-only, danach Export ins Cold Storage.
- 8Go/No-Go-Bericht liefern an Steering Committee: Zählwerte stimmen, Fehler < X, Freigabe durch Entitäts-Owner.