Der weitere zeitliche Verlauf ergab sich mittels einer Rückwärtsterminierung. Durch eine noch straffere Organisation des Jahresabschlusses sowie die Vorverlegung des Prüfungszeitraums durch die Wirtschaftsprüfer konnte der Beginn der produktiven Migration für den 06.02.2009 geplant werden. Mit den Daten des zu migrierenden Geschäftsjahres sollte auch eine Generalprobe durchgeführt werden, um genauere Erkenntnisse über die zu erwartenden technischen Laufzeiten während der Migration zu gewinnen. Als Randbedingung für diese Generalprobe war zu berücksichtigen, dass auch ein slowakischer Buchungskreis zu migrieren war und die EU die Euro-Einführung in der Slowakei zum 01.01.2009 beschlossen hat. Diese sollte im Produktivsystem noch vor dem Datenabzug für die Generalprobe beginnen. Man hat sich entschieden, die Euro-Umstellung bereits am 10.01.2009 durchzuführen, sodass am folgenden Wochenende eine Kopie des Produktivsystems erstellt werden konnte, um am 18.01. mit der Generalprobe zu beginnen. Alle Funktions- und Integrationstests wurden im Jahr 2008 durchgeführt.

Aus dem Projektplan ist ersichtlich, dass sich die Phasen für die Erstellung von Fachkonzept und Blueprint sowie die Realisierung überschneiden. Der Grund hierfür liegt in der Komplexität einer Einführung des neuen Hauptbuchs. Viele Entscheidungen konnten nur in interdisziplinären Workshops mit Beteiligung von Buchhaltung, Controlling, IT und Beratern getroffen werden. Durch die überlappenden Projektphasen wurde auch der Lernkurve der Mitarbeiter Rechnung getragen.Die Hypercare-Phase, auch After-Go-Live-Support, also die erhöhte Verfügbarkeit der IT-Mitarbeiter und Berater bei Problemen oder Fragen in der Anwendung, begann nicht erst mit der produktiven Migration, sondern bereits mit Phase 1 (01.01.2009). In Phase 1 galten für alle Buchungen im Hauptbuch bereits die Regeln der Belegaufteilung. In dieser Zeit kam es daher vor allem zu Problemen bei der Verbuchung von Belegen. Nach der Migration änderte sich in der Buchungslogik nichts mehr. Der Schwerpunkt der Anwenderbetreuung lag daher direkt nach der Migration in der Erklärung des Zahlenwerks, das sich durch die Migration ergibt. Gerade die Unterscheidung von Erfassungs- und Hauptbuchsicht fiel den Anwendern nicht leicht und führte daher zu einer Reihe von Fragen.

Funktions- und Integrationstests waren in drei Teilphasen untergliedert:
* Test von Phase 1 (Zeitraum Migrationsdatum bis Aktivierungsdatum)
* Test der eigentlichen Migration
* Test von Phase 2 (nach Migration und Aktivierung des neuen Hauptbuchs)


Beim Test der Phase 1 wurde vor allem darauf geachtet, dass alle Vorgänge verbucht werden konnten. Eine korrekte Segmentableitung war zu diesem Zeitpunkt noch nicht notwendig, da das neue Hauptbuch nicht aktiviert ist. Durch den Test der Phase 1 wurde auch sichergestellt, dass für die Testmigration ausreichende und aussagekräftige Daten zur Verfügung stehen. Während der anschließenden technischen Migration wurden die Funktionen des Migration Cockpits selbst sowie die dabei angewendete Kontierungsableitung getestet. Die Abstimmung erfolgte immer im Vergleich von klassischem und neuem Hauptbuch. Hier durften keine Abweichungen auftreten. Anders der Vergleich mit Profit-Center-Rechnung und UKV-Ledger: Da die grundsätzliche Ableitungslogik für Profit-Center und Funktionsbereich überarbeitet wurde, konnten die Salden auf diesen Ebenen zwischen klassischen Ledgern und neuem Hauptbuch nicht übereinstimmen. Zudem wurde in der klassischen Profit-Center-Rechnung nur die GuV abgebildet. Bevor das Systemverhalten bei aktiviertem neuem Hauptbuch (Phase 2) durch die Buchung aller Vorgänge in Finanzbuchhaltung und Controlling sowie einen repräsentativer Anteil der logistischen Prozesse getestet wurde, erfolgte die Abstimmung der Migration. Diese erfolgte immer in zwei Schritten. Zunächst erfolgte eine technische Überprüfung mithilfe der Transaktion GCAC (Ledgervergleich) auf Ebene des Buchungskreises. Erst im Anschluss folgte die Detailabstimmung auf Ebene Sachkonto, Funktionsbereich, Profit-Center und Segment.

Erschwert wurde die Feinabstimmung durch die bereits erwähnte Neuableitung von Funktionsbereich, Profit-Center und Segment in den Belegen des aktuellen Geschäftsjahres. Im Standard des Migration Cockpits ist dies nicht möglich. Wenn ein Beleg bereits in der Erfassungssicht eine der genannten Kontierungen enthält, wird dieser Eintrag in die Hauptbuchsicht übernommen. Mithilfe einer Modifikation konnte auch in diesen Fällen eine Neuableitung der Kontierung in der Hauptbuchsicht erfolgen. Durch die Modifikation wurde z. B. die aktuell gültige statt die historische Zuordnung von Kostenstellen- und Auftragsstammdaten verwendet, womit in Phase 1 vorgenommene Zuordnungsänderungen bereinigt wurden. Nachteil dieses Vorgehens ist, dass Erfassungs- und Hauptbuchsicht der Belege aus Phase 1 unterschiedliche Kontierungen tragen. Nur so war aber eine Bereinigung des Buchungsstoffs mit Stichtag 01.01.2009 möglich.