SH

Sascha Hess

xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

NOTFALL-KIT – ERP-MIGRATION 2026

ERP-Migration

Schritt-für-Schritt

Von der Analysephase bis zum Go-Live — Risiken minimieren, Migration beherrschen

1

Migrations-Readiness-Check

Vollständige Checkliste: Ist Ihr Unternehmen bereit für die Migration?

2

Datenmigrationskonzept

Schema-Mapping, Datentransformation und Validierungsstrategie

3

Testkonzept & UAT

Strukturiertes Testen vom Migrationslauf bis zum Benutzerabnahmetest

4

Go-Live & Rollback-Plan

Cutover-Planung, Fallback-Strategie und Hypercare-Phase

5

60-Tage-Migrationsplan

Vollständiger Projektplan von Kick-off bis zum produktiven Betrieb

WAS SIE IN DIESEM KIT ERWARTEN DÜRFEN

■  Migrations-Readiness-Check — Strukturierte Bewertung ob Ihr Unternehmen bereit ist.

■  Datenmigrationskonzept — Schema-Mapping, Transformation und Qualitätssicherung.

■  Vollständiges Testkonzept — Von Datenmigrationstests bis zum Benutzerabnahmetest.

■  Go-Live-Checkliste — Stunde für Stunde geplanter Cutover mit Rollback-Trigger.

■  60-Tage-Projektplan — Von Kick-off bis produktiver Betrieb, Woche für Woche.

ZIEL DIESES KITS

Nach dem Lesen und Umsetzen dieses Kits haben Sie ein vollständiges Migrationskonzept, eine validierte Datenmigrationsstrategie, ein strukturiertes Testkonzept mit UAT-Plan, eine Go-Live-Checkliste mit Rollback-Entscheidungsbäumen und einen realistischen 60-Tage-Projektplan — angepasst an Ihre ERP-Umgebung.

READINESS-DIMENSIONEN

■  Datenqualität: Wie vollständig, konsistent und bereinigt sind die Daten im Altsystem?

■  Ressourcen: Sind interne Schlüsselpersonen für das Projekt verfügbar (nicht 10 % — echte Kapazität)?

■  Fachbereich: Ist die Fachabteilung bereit, Prozesse zu überdenken und zu testen?

■  Management: Ist die Geschäftsführung committed — auch wenn es unbequem wird?

■  Rollback: Existiert ein realistischer Plan für den Fall dass der Go-Live scheitert?

CHECKLISTE ALTSYSTEM-ANALYSE:

DATENBESTAND:

  □ Gesamtvolumen der Daten erfassen (GB, Anzahl Datensätze je Tabelle)

  □ Datenalter analysieren: Wie alt sind die ältesten aktiven Stammdaten?

  □ Dubletten identifizieren: Wie viele Kundendatensätze sind doppelt?

  □ Pflichtfelder prüfen: Welche Felder sind im Altsystem leer die im Zielsystem Pflicht sind?

  □ Codierungen dokumentieren: Welche Listen, Codes, Schlüssel müssen gemappt werden?

SCHNITTSTELLEN:

  □ Alle Systemschnittstellen dokumentieren (ERP ↔ CRM, ERP ↔ WMS, ERP ↔ BI)

  □ Schnittstellen-Eigentümer identifizieren (wer ist für welche Schnittstelle verantwortlich?)

  □ Migrationszeitpunkt je Schnittstelle definieren (parallel, sequentiell, nach Go-Live)

PROZESSE:

  □ Kernprozesse End-to-End dokumentieren (Angebot → Auftrag → Lieferung → Rechnung)

  □ Systembrüche identifizieren: Wo wird manuell zwischen Systemen übertragen?

  □ Sonderregeln erfassen: Welche Ausnahmen und Sonderfälle gibt es?

Schlechte Datenqualität

Hoch

Kritisch

Datenbereinigung vor Migration starten

Ressourcenengpass Fachbereich

Mittel

Hoch

Ressourcenplan mit Backup-Personen

Schnittstellen funktionieren nicht

Mittel

Hoch

Frühe Integration Tests mit echten Daten

Benutzerakzeptanz fehlt

Mittel

Hoch

Change Management parallel starten

Go-Live-Termin unter Druck

Hoch

Kritisch

Realistischer Zeitplan, klare Abbruchkriterien

Datenverlust bei Migration

Niedrig

Kritisch

Vollbackup + Validierungsprotokoll

SCOPE-DOKUMENT VORLAGE:

IM SCOPE (wird migriert):

  ✓ Kundenstammdaten (aktive Kunden der letzten 5 Jahre)

  ✓ Lieferantenstammdaten (aktive Lieferanten)

  ✓ Artikelstammdaten (aktive Artikel + X Jahre Historie)

  ✓ Offene Aufträge, Bestellungen, Rechnungen zum Stichtag

  ✓ Kontenbuchungen: laufendes Geschäftsjahr + X Vorjahre

NICHT IM SCOPE (bleibt im Altsystem / wird nicht migriert):

  ✗ Archivdaten älter als X Jahre (werden im Altsystem read-only gehalten)

  ✗ Historische Angebote ohne Auftrag

  ✗ Inaktive Debitoren/Kreditoren (Definition: kein Umsatz in X Jahren)

CUTOVER-STICHTAG: [Datum festlegen]

PARALLELBETRIEB: [Ja/Nein — wenn ja: wie lange?]

STRATEGIEVERGLEICH:

BIG BANG (Komplettumstieg in einer Nacht):

  Vorteil:   Kein Parallelbetrieb, einmalige Datenmigration, klarer Schnitt

  Nachteil:  Hohes Risiko, langer Cutover (Wochenende), kein Fallback-Puffer

  Geeignet:  Kleinere Systeme, gut vorbereitete Teams, einfache Datenstrukturen

PHASED ROLLOUT (schrittweise nach Modulen oder Standorten):

  Vorteil:   Risiko verteilt, Lernkurve zwischen Wellen, Fachbereich entlastet

  Nachteil:  Parallelbetrieb mehrerer Systeme, komplexe Datensynchronisation

  Geeignet:  Große, komplexe Umgebungen, mehrere Standorte oder Tochtergesellschaften

PARALLEL BETRIEB (beide Systeme laufen gleichzeitig):

  Vorteil:   Maximale Sicherheit, Datenvergleich möglich

  Nachteil:  Doppelter Aufwand, Datenkonsistenz aufwendig, teuer

  Geeignet:  Kritische Systeme wo Ausfallrisiko inakzeptabel ist

KUNDEN.KDNR

VARCHAR(10)

Debitoren.Debitorennummer

VARCHAR(10)

1:1 Übernahme

KUNDEN.NAME1

VARCHAR(40)

Debitoren.Name1

VARCHAR(50)

1:1 Übernahme

KUNDEN.PLZ

CHAR(5)

Debitoren.PLZ

VARCHAR(10)

Format prüfen, DE-Plausibilität

KUNDEN.LAND

CHAR(2)

Debitoren.LKZ

CHAR(3)

ISO 2→3 Umschlüsselung

KUNDEN.STATUS

INT (0/1)

Debitoren.Gesperrt

BIT

0→False, 1→True

KUNDEN.UMSATZ

DECIMAL

—

—

Nicht migriert (BI-System)

-- Beispiel: Kundendaten transformieren (Pseudocode / SQL-Muster)

-- Dieses Skript illustriert das Transformationsmuster

INSERT INTO Ziel_DB.dbo.Debitoren (

    Debitorennummer,

    Name1,

    PLZ,

    Ort,

    Laenderkennzeichen,

    Gesperrt,

    Waehrung,

    Zahlungsbedingung,

    Migriert_Am,

    Quell_ID

)

SELECT

    -- Feld 1: Debitorennummer — Direktübernahme, führende Nullen ergänzen

    RIGHT('0000000000' + LTRIM(RTRIM(k.KDNR)), 10) AS Debitorennummer,

    -- Feld 2: Name — Trim, Sonderzeichen normalisieren

    REPLACE(REPLACE(LTRIM(RTRIM(k.NAME1)), CHAR(9), ' '), '  ', ' ') AS Name1,

    -- Feld 3: PLZ — Validierung: nur 5-stellige deutsche PLZ

    CASE

        WHEN k.LAND = 'DE' AND LEN(LTRIM(RTRIM(k.PLZ))) = 5

             AND ISNUMERIC(k.PLZ) = 1

        THEN LTRIM(RTRIM(k.PLZ))

        ELSE '00000'   -- Fehler-PLZ → in Validierungsprotokoll erfassen

    END AS PLZ,

    LTRIM(RTRIM(k.ORT)) AS Ort,

    -- Feld 4: Länderkennzeichen — ISO-2 zu ISO-3 Mapping

    CASE k.LAND

        WHEN 'DE' THEN 'DEU'

        WHEN 'AT' THEN 'AUT'

        WHEN 'CH' THEN 'CHE'

        WHEN 'FR' THEN 'FRA'

        ELSE 'XXX'   -- Unbekannt → manuelle Nachbearbeitung

    END AS Laenderkennzeichen,

    -- Feld 5: Gesperrt-Flag

    CASE k.STATUS WHEN 1 THEN 1 ELSE 0 END AS Gesperrt,

    -- Felder 6-7: Defaults wenn im Altsystem nicht vorhanden

    'EUR' AS Waehrung,

    'ZB30' AS Zahlungsbedingung,   -- Standard-ZB, ggf. anpassen

    GETDATE() AS Migriert_Am,

    k.KDNR AS Quell_ID

FROM Alt_DB.dbo.KUNDEN k

WHERE k.AKTIV = 1                   -- Nur aktive Kunden

  AND k.LETZTER_UMSATZ >= DATEADD(YEAR, -5, GETDATE());  -- Letzte 5 Jahre

-- Validierungsabfragen nach jedem Migrationslauf ausführen

-- 1. Mengenvergleich: Wurden alle Datensätze migriert?

SELECT

    'Quelle' AS System,

    COUNT(*) AS Anzahl_Kunden

FROM Alt_DB.dbo.KUNDEN

WHERE AKTIV = 1 AND LETZTER_UMSATZ >= DATEADD(YEAR,-5,GETDATE())

UNION ALL

SELECT 'Ziel', COUNT(*) FROM Ziel_DB.dbo.Debitoren

WHERE Quell_System = 'MIGRATION_2026';

-- 2. Fehler-PLZ identifizieren (Nachbearbeitung erforderlich)

SELECT Debitorennummer, Name1, PLZ, Ort, Quell_ID

FROM Ziel_DB.dbo.Debitoren

WHERE PLZ = '00000' AND Quell_System = 'MIGRATION_2026';

-- 3. Unbekannte Länderkennzeichen

SELECT Debitorennummer, Name1, Laenderkennzeichen, Quell_ID

FROM Ziel_DB.dbo.Debitoren

WHERE Laenderkennzeichen = 'XXX' AND Quell_System = 'MIGRATION_2026';

-- 4. Summenvergleich: Offene Posten stimmen überein?

SELECT

    'Quelle' AS System,

    SUM(BETRAG) AS Offene_Posten_Gesamt,

    COUNT(*) AS Anzahl_Positionen

FROM Alt_DB.dbo.OFFENE_POSTEN

WHERE STICHTAG <= '2026-06-30'

UNION ALL

SELECT 'Ziel', SUM(Betrag), COUNT(*)

FROM Ziel_DB.dbo.OffenePosten

WHERE Migrationsstichtag = '2026-06-30';

EMPFOHLENE UMGEBUNGSSTRUKTUR FÜR ERP-MIGRATION:

ENTWICKLUNG (DEV):

  Zweck:    Erstentwicklung Migrationsskripte, Schema-Mapping, Tests

  Daten:    Anonymisierter Teilauszug (5-10 % der Produktionsdaten)

  Zugriff:  Projektteam IT

QUALITÄTSSICHERUNG (QAS/TEST):

  Zweck:    Integrationstests, UAT, Migrationsproben

  Daten:    Vollständige Kopie der Produktionsdaten (anonymisiert)

  Zugriff:  Projektteam IT + Fachbereich Key-User

PRE-PRODUKTION (PREPROD / STAGING):

  Zweck:    Cutover-Probe, finale Validierung, Go-Live-Rehearsal

  Daten:    Produktionsdaten (letzter Stand vor Go-Live)

  Zugriff:  Eingeschränkt — nur Go-Live-Team

PRODUKTION (PROD):

  Zweck:    Produktivbetrieb nach Go-Live

  Daten:    Migrierte Produktionsdaten

  Zugriff:  Alle Benutzer nach Go-Live-Freigabe

PFLICHTFELDER VOR ERSTER DATENMIGRATION KONFIGURIERT:

STAMMDATEN-GRUNDKONFIGURATION:

  ✓ Buchungskreise angelegt und aktiviert

  ✓ Währungen konfiguriert (Haupt- und Fremdwährungen)

  ✓ Zahlungsbedingungen vollständig (alle aus Altsystem + neue)

  ✓ Steuerkennzeichen gemappt und getestet

  ✓ Kontenplan importiert und validiert

NUMMERNKREISE:

  ✓ Debitoren-Nummernkreis: Überlappung mit Altsystem ausgeschlossen

  ✓ Kreditoren-Nummernkreis: Überlappung ausgeschlossen

  ✓ Artikel-Nummernkreis: bestehende Nummern werden beibehalten

  ✓ Belegnummernkreise für neues Geschäftsjahr konfiguriert

BENUTZER & BERECHTIGUNGEN:

  ✓ Alle Benutzer im Zielsystem angelegt

  ✓ Rollen und Berechtigungen definiert und getestet

  ✓ Technische User für ETL und Schnittstellen angelegt

  ✓ Notfall-Passwörter in sicherem Tresor hinterlegt

ERP ↔ CRM

SAP RFC

REST API

4 Wochen vor Go-Live

Test

ERP ↔ Webshop

DB-Link

Middleware

2 Wochen vor Go-Live

Entwicklung

ERP ↔ Logistik

File-based EDI

API EDI

Go-Live-Nacht

Planung

ERP ↔ BI/Reporting

DB Views

DWH Connector

2 Wochen nach Go-Live

Offen

ERP ↔ Banking

SEPA-Datei

SEPA-Datei

Go-Live-Nacht

Test

DATENMIGRATIONS-PIPELINE:

SCHRITT 1 — EXTRAKTION (Extract):

  Quelle: Altsystem-Datenbank (read-only Zugriff)

  Tool:   SQL SELECT + BCP / SSIS / Python-Skript

  Output: Rohdaten in Staging-Bereich (CSV oder Staging-DB)

  Dauer:  Abhängig von Datenmenge (Richtwert: 1-2 Std. für 1 Mio. Sätze)

SCHRITT 2 — TRANSFORMATION (Transform):

  Input:  Rohdaten aus Staging

  Tool:   SQL Skripte / SSIS-Paket

  Schritte:

    a) Datenbereinigung (Trim, Sonderzeichen, Encoding)

    b) Validierung (Pflichtfelder, Formate, Referenzintegrität)

    c) Umschlüsselung (Codes, Schlüssel, Lookup-Tabellen)

    d) Anreicherung (Defaults setzen, berechnete Felder)

    e) Fehler-Routing (ungültige Sätze in Fehler-Protokoll)

  Output: Transformierte Daten in Zieltabellen (Staging-DB)

SCHRITT 3 — LADEN (Load):

  Input:  Transformierte Daten aus Staging

  Methode: Bulk Insert / API-Upload / Direct DB Load

  Reihenfolge: KRITISCH — Stammdaten vor Bewegungsdaten!

    1. Organisationseinheiten, Buchungskreise

    2. Kontenplan, Kostenstellen

    3. Kundenstamm, Lieferantenstamm

    4. Artikelstamm, Stücklisten

    5. Lagerbestände (zum Stichtag)

    6. Offene Aufträge, Bestellungen

    7. Offene Posten Debitoren/Kreditoren

    8. Sachkontensalden (Eröffnungsbilanz)

-- Protokolltabelle für jeden Migrationslauf

CREATE TABLE Migration_Protokoll (

    ProtokolllID    INT IDENTITY PRIMARY KEY,

    Lauf_Nr         INT NOT NULL,           -- Probemigration 1, 2, 3 ... Final

    Lauf_Typ        NVARCHAR(20),           -- 'Probe' oder 'Final'

    Lauf_Start      DATETIME2,

    Lauf_Ende       DATETIME2,

    Entitaet        NVARCHAR(100),          -- z.B. 'Debitoren', 'Artikel'

    Quelle_Anzahl   INT,                    -- Sätze in Quelle

    Geladen_Anzahl  INT,                    -- Erfolgreich geladen

    Fehler_Anzahl   INT,                    -- Mit Fehler

    Fehler_Details  NVARCHAR(MAX),          -- Fehlertext

    Validiert       BIT DEFAULT 0,

    Validiert_Von   NVARCHAR(100),

    Kommentar       NVARCHAR(500)

);

-- Typisches Validierungsprotokoll nach Lauf

SELECT

    Entitaet,

    Quelle_Anzahl,

    Geladen_Anzahl,

    Fehler_Anzahl,

    ROUND(100.0 * Geladen_Anzahl / NULLIF(Quelle_Anzahl,0), 1) AS Erfolgsquote_Pct,

    ROUND(DATEDIFF(SECOND, Lauf_Start, Lauf_Ende) / 60.0, 1) AS Dauer_Min

FROM Migration_Protokoll

WHERE Lauf_Nr = 3  -- Probemigration 3

ORDER BY Lauf_Start;

DATENBEREINIGUNG — WANN UND WAS

■  VOR der Migration im Altsystem: Offensichtliche Dubletten zusammenführen, kritische Pflichtfelder befüllen, veraltete Datensätze archivieren.

■  WÄHREND der Migration per Skript: Formatkonvertierungen, Zeichensatz-Normalisierung, Lookup-Umschlüsselungen, Defaults setzen.

■  NACH der Migration im Zielsystem: Fachliche Qualitätsprüfungen durch Key-User, manuelle Nachbearbeitung von Sonderfällen, finale Validierung.

TEST-EBENEN (von unten nach oben aufbauen):

EBENE 1 — TECHNISCHE MIGRATIONSTESTS (IT):

  Was:    Migrationsskripte laufen fehlerfrei durch

  Wer:    IT / Datenbankadministrator

  Kriterium: Fehlerquote < 0,1 %, alle Validierungsabfragen grün

  Wann:   Ab Woche 3 (nach erstem Probemigrationslauf)

EBENE 2 — INTEGRATIONSTESTS (IT + Fachbereich):

  Was:    Schnittstellen funktionieren, Prozesse end-to-end durchführbar

  Wer:    IT + Key-User Fachbereich

  Kriterium: Alle kritischen Geschäftsprozesse ausführbar

  Wann:   Ab Woche 6 (nach Systemkonfiguration)

EBENE 3 — BENUTZERABNAHMETEST / UAT (Fachbereich):

  Was:    Fachbereich testet eigene Prozesse mit echten Szenarien

  Wer:    Key-User + Endbenutzer-Stichprobe

  Kriterium: Go/No-Go-Entscheidung Fachbereich

  Wann:   Woche 8-10 (4-6 Wochen vor Go-Live)

EBENE 4 — PERFORMANCE & LASTTEST (IT):

  Was:    System hält Produktionslast stand

  Wer:    IT

  Kriterium: Kritische Transaktionen unter X Sekunden bei Volllast

  Wann:   Woche 9 (parallel zu UAT)

UAT-001

Auftragsanlage

Neuen Kundenauftrag mit 3 Positionen anlegen

Kundenstamm vorhanden

Auftrag angelegt, Liefertermin berechnet

PASS / FAIL

[Name]

UAT-002

Warenausgang

Lieferschein erstellen und buchen

Auftrag aus UAT-001

Bestand reduziert, Lieferschein gedruckt

PASS / FAIL

[Name]

UAT-003

Rechnungsstellung

Rechnung aus Lieferung erzeugen

Lieferschein aus UAT-002

Rechnung erstellt, OP gebucht

PASS / FAIL

[Name]

UAT-004

Zahlungseingang

Zahlung einem Debitor zuordnen

Offene Rechnung vorhanden

OP ausgeglichen

PASS / FAIL

[Name]

UAT-005

Bestellanforderung

BANF anlegen, Genehmigung + Bestellung

Artikel + Lieferant vorhanden

Bestellung gedruckt/gesendet

PASS / FAIL

[Name]

GO-LIVE FREIGABE — VORAUSSETZUNGEN (ALLE müssen erfüllt sein):

TECHNISCH:

  ✓ Finale Datenmigration: Fehlerquote < 0,1 % (kein kritischer Fehler offen)

  ✓ Validierungsabfragen: Summenabgleich Debitoren/Kreditoren < 0,01 % Abweichung

  ✓ Performance: Kritische Transaktionen < definierte Grenzwerte

  ✓ Backups: Vollbackup Altsystem UND Zielsystem vor Cutover-Start bestätigt

  ✓ Rollback-Mechanismus: Getestet und in < 4 Stunden durchführbar

FACHLICH:

  ✓ UAT-Abnahme: Schriftliche Freigabe aller Fachbereichsleiter vorliegt

  ✓ Offene UAT-Fehler: Keine kritischen, alle hohen Priorität gelöst

  ✓ Schulungen: Mindestens 90 % der Benutzer geschult und bestätigt

ORGANISATORISCH:

  ✓ Hypercare-Team: Besetzung für erste 2 Wochen nach Go-Live geplant

  ✓ Kommunikation: Alle Benutzer über Go-Live-Termin informiert

  ✓ Management-Freigabe: Schriftliche Bestätigung Go-Live-Entscheidung

STAKEHOLDER-MAP ERP-MIGRATION:

CHAMPIONS (hoch, positiv):          → Aktiv einbinden, als Multiplikatoren nutzen

  Typisch: IT-affine Key-User, neue Teamleitung, junge Mitarbeiter

SKEPTIKER (hoch, negativ):          → Frühzeitig adressieren, Bedenken ernst nehmen

  Typisch: Langjährige Erfahrungsträger, "das war immer so"-Kultur

NEUTRALE (mittel):                  → Informiert halten, nicht vernachlässigen

  Typisch: Operative Benutzer, Teilzeitkräfte

ENTSCHEIDER (Top-Management):       → Sichtbar committen lassen, Fortschritt melden

  Typisch: Geschäftsführung, Bereichsleiter

ERFOLGSFAKTOR:

→ Management muss die Migration aktiv vorleben — nicht nur tolerieren.

→ Key-User sind die wichtigsten Botschafter: früh einbinden, wertschätzen.

Key-User

Vollständige Prozesse, Systemkonfiguration, Fehlerbehandlung

Präsenz-Workshop

6 Wochen vor Go-Live

2-3 Tage

Endbenutzer

Eigene Prozesskette, tägliche Aufgaben

Gruppentraining (10-15 Personen)

2-3 Wochen vor Go-Live

0,5-1 Tag

Management

Reporting, Dashboards, KPI-Auswertungen

Kurz-Demo (2 Stunden)

2 Wochen vor Go-Live

2 Std

IT-Team

Administration, Berechtigungen, Backup

Technisches Training

4 Wochen vor Go-Live

1-2 Tage

KOMMUNIKATIONS-MEILENSTEINE

■  Kick-off (Projektstart): Warum migrieren wir? Was ändert sich? Was nicht?

■  8 Wochen vor Go-Live: Schulungstermine kommunizieren, Fragen sammeln.

■  4 Wochen vor Go-Live: UAT-Ergebnisse kommunizieren, Fortschritt zeigen.

■  1 Woche vor Go-Live: Go-Live-Ablauf erklären, Ansprechpartner benennen.

■  Go-Live-Tag: Status-Updates alle 2 Stunden bis System freigegeben.

■  Nach Go-Live: Erste-Woche-Bericht, Problemstatus, Danke sagen.

GO-LIVE-NACHT — CUTOVER-ABLAUF (Beispiel Freitag 18:00 bis Montag 06:00):

FREITAG 18:00 — ALTSYSTEM EINFRIEREN

  □ Letzter Buchungsschnitt im Altsystem

  □ Alle offenen Transaktionen abschließen (Benachrichtigung an alle User)

  □ Altsystem auf "read-only" stellen (kein Schreiben mehr möglich)

  □ Go-Live-Team vollständig verfügbar: Anwesenheit bestätigen

FREITAG 18:30 — BACKUP & EXTRAKTION

  □ Vollbackup Altsystem (bestätigt, Größe plausibel, Restore-Test!)

  □ Vollbackup Zielsystem (Stand vor Go-Live)

  □ Finale Datenextraktion starten (offene Posten, Bestände, offene Aufträge)

  □ Laufzeit-Schätzung für Extraktion: __ Std.

FREITAG ca. 20:00 — TRANSFORMATION & LOAD

  □ Transformationsskripte auf finale Extraktion ausführen

  □ Validierungsabfragen: Zähler, Summen, Fehlerprotokoll

  □ Bei Fehlerquote > 0,5 %: STOP → Eskalation → Rollback-Entscheidung

  □ Load in Zielsystem starten

SAMSTAG 02:00 — VALIDIERUNG FINAL

  □ Alle Validierungsabfragen grün? → Weiter

  □ Summenabgleich Debitoren/Kreditoren → Differenz dokumentieren

  □ Key-User Stichprobencheck: 10 Datensätze je Entität manuell prüfen

  □ Performance-Test: kritische Transaktionen unter Grenzwert?

SAMSTAG 06:00 — GO/NO-GO ENTSCHEIDUNG

  □ Projektleiter + IT-Leiter + Fachbereichsleiter: gemeinsame Entscheidung

  □ GO: Altsystem endgültig sperren, Zielsystem für Produktion freischalten

  □ NO-GO: Rollback-Plan aktivieren (Zielsystem zurücksetzen, Altsystem reaktivieren)

MONTAG 06:00 — SYSTEM FREIGABE

  □ Offizielle Freigabe für alle Benutzer

  □ Hypercare-Team vollständig im Einsatz

  □ Erste Status-Kommunikation an alle Benutzer

ROLLBACK-TRIGGER — SOFORTIGER ABBRUCH WENN:

KRITISCH (sofortiger Rollback ohne Diskussion):

  ✗ Datenverlust nachgewiesen (Sätze fehlen die im Altsystem vorhanden waren)

  ✗ Fehlerquote > 1 % bei kritischen Stammdaten (Debitoren, Kreditoren, Artikel)

  ✗ Summenabgleich Offene Posten: Abweichung > 100 EUR

  ✗ Technischer Ausfall Zielsystem während Cutover

  ✗ Zeitpuffer erschöpft: Wenn um 04:00 noch kein GO möglich → Rollback

BEURTEILUNGSSACHE (Projektleiter-Entscheidung):

  ! Fehlerquote 0,1-1 %: Können Fehler bis Montag manuell behoben werden?

  ! Performance unter Grenzwert: Ist Degradierung für Benutzer akzeptabel?

  ! Einzelne Schnittstelle funktioniert nicht: Kann Prozess manuell überbrückt werden?

ROLLBACK-DURCHFÜHRUNG (< 4 Stunden):

  1. Zielsystem sofort für alle Benutzer sperren

  2. Backup vom Altsystem wiederherstellen (Restore-Dauer: __ Std. — vorher gemessen!)

  3. Altsystem reaktivieren und testen

  4. Benutzer informieren: "Wir arbeiten weiter im Altsystem — neuer Termin folgt"

  5. Ursachenanalyse starten, nächsten Go-Live-Termin planen

HYPERCARE-PLANUNG (2-4 WOCHEN NACH GO-LIVE)

■  Vollbesetzte Hotline: Dedizierte Ansprechpartner für Benutzer-Fragen — nicht normaler Support.

■  Eskalationspfad: Frage → Key-User → Projektteam → Softwarehersteller (SLA definiert!).

■  Tägliches Jour-fixe: 07:30 Uhr: Was kam gestern rein? Was ist heute kritisch?

■  Fehler-Tracking: Alle gemeldeten Probleme sofort erfassen, kategorisieren, priorisieren.

■  Wochenbericht: Täglich → Projektleiter, Wöchentlich → Management.

-- Monitoring-Abfragen für die ersten Wochen nach Go-Live

-- 1. Fehlgeschlagene Buchungen / Fehlerprotokolle täglich prüfen

SELECT TOP 50

    Fehlerzeitpunkt,

    Benutzer,

    Transaktion,

    Fehlermeldung,

    Datensatz_ID

FROM Ziel_DB.dbo.Anwendungsfehler_Log

WHERE Fehlerzeitpunkt >= DATEADD(DAY, -1, GETDATE())

ORDER BY Fehlerzeitpunkt DESC;

-- 2. Migrierte Datensätze die nachbearbeitet werden mussten

SELECT

    Entitaet,

    COUNT(*) AS Nachbearbeitet,

    MIN(Nachbearbeitet_Am) AS Erste_Nachbearbeitung,

    MAX(Nachbearbeitet_Am) AS Letzte_Nachbearbeitung

FROM Ziel_DB.dbo.Migrations_Nachbearbeitung

WHERE Nachbearbeitet_Am >= DATEADD(DAY, -7, GETDATE())

GROUP BY Entitaet

ORDER BY Nachbearbeitet DESC;

-- 3. Performance-Trend: Kritische Transaktion (z.B. Auftragsanlage)

SELECT

    CAST(Messzeitpunkt AS DATE) AS Datum,

    Transaktion,

    AVG(Dauer_Sek) AS Avg_Dauer_Sek,

    MAX(Dauer_Sek) AS Max_Dauer_Sek,

    COUNT(*) AS Anzahl_Messungen

FROM Ziel_DB.dbo.Performance_Log

WHERE Transaktion IN ('Auftragsanlage','Warenausgang','Rechnungsstellung')

  AND Messzeitpunkt >= DATEADD(DAY, -30, GETDATE())

GROUP BY CAST(Messzeitpunkt AS DATE), Transaktion

ORDER BY Datum, Transaktion;

Analysephase

Risikoanalyse war präzise

Datenqualität unterschätzt

Frühere Data-Profiling-Tools einsetzen

Datenmigration

ETL-Skripte stabil

Probemigration 1+2 zu kurz geplant

Mindestens 3 Probeläufe mit 2 Wochen Abstand

Testing

UAT gut strukturiert

Performance-Test zu spät

Lasttest parallel zu UAT

Go-Live

Cutover-Plan funktionierte

Kommunikation zu wenig

Stündliche Updates an alle Benutzer

Post Go-Live

Hypercare-Team gut

Hotline überlastet Woche 1

Doppelte Besetzung erste Woche

WOCHE 1-2: STABILISIERUNG

■  Alle gemeldeten Fehler klassifizieren: kritisch (sofort), hoch (< 2 Tage), mittel (< 1 Woche).

■  Offene Migrationsnacharbeiten abschließen (Datensätze mit Status "Fehler-PLZ" etc.).

■  Schnittstellen-Monitoring: Alle Schnittstellen täglich auf Fehler prüfen.

■  Benutzer-Feedback systematisch sammeln: Was fehlt? Was ist anders als erwartet?

WOCHE 3-4: OPTIMIERUNG

■  Performance-Tuning: Abfragen die langsamer als erwartet identifizieren und optimieren.

■  Reporting: Erst-Auswertungen aus dem neuen System validieren (stimmen Zahlen mit Altsystem überein?).

■  Schulungs-Nachschuss: Benutzer die noch unsicher sind gezielt nachschulen.

■  Projektabschluss vorbereiten: Dokumentation finalisieren, Übergabe an Betrieb.

VOR DEM START

Projektleiter benennen und offiziell kommunizieren. Lenkungsausschuss konstituieren. Budget freigeben. Key-User in allen Fachbereichen nominieren. Kick-off-Termin mit allen Stakeholdern fixieren.

ERGEBNIS NACH 60 TAGEN

Nach 60 Tagen haben Sie: eine vollständig migrierte ERP-Umgebung mit validierten Daten, ein dokumentiertes Migrations-Protokoll als Revisions-Nachweis, abgenommene UAT-Protokolle von allen Fachbereichen, ein stabiles System in der Hypercare-Phase und ein vollständiges Lessons-Learned-Dokument für künftige Projekte.

ERP-Migrations-Beratung

Vollständige Projektbegleitung von der Analysephase bis Go-Live — als externer Projektleiter oder technischer Berater.

Datenmigrations-Konzept

Erstellung eines vollständigen Datenmigrationskonzepts mit Schema-Mapping, ETL-Strategie und Validierungskonzept.

SQL Server Datenbankoptimierung

Performance-Analyse und Optimierung der ERP-Datenbankumgebung vor und nach der Migration.

Testkonzept & UAT-Begleitung

Strukturiertes Testkonzept erstellen, UAT moderieren und Go/No-Go-Entscheidung vorbereiten.

Interim IT-Management

Übernahme der IT-Projektsteuerung auf Zeit — Dienstleister-Management, Budgetcontrolling, Reporting an Geschäftsführung.