Export und Import müssen in der Regel innerhalb eines festen Zeitraums erfolgen, üblicherweise innerhalb eines Wochenendes - das Quellsystem muss aus Gründen der Datenkonsistenz während der Umstellung komplett offline sein. Wenige große Tabellen bestimmen erfahrungsgemäß die Gesamtlaufzeit der Migration, hier setzen verschiedene Optimierungsverfahren an.

Liegt der Engpass bei der Exportgeschwindigkeit, so können kritische Tabellen üblicherweise unsortiert entladen werden. Dies kann den Export signifikant beschleunigen - allerdings ist dann in vielen Fällen eine spätere Reorganisation der betroffenen Tabellen im Zielsystem notwenig. Export- und Importprozesse lassen sich von einem sequenziellen auf ein paralleles Verfahren umstellen, sprich eine Tabelle muss nicht mehr komplett entladen werden, bevor sie in das Zielsystem geladen wird, sondern der Export ist über das Netzwerk direkt mit einem Import gekoppelt. Hierdurch lassen sich einzelne Tabellen um bis zu 50 Prozent schneller in das Zielsystem transferieren.

Liegt der Engpass beim Ladevorgang, existieren je nach Datenbank plattformspezifische Optimierungen. Im Beispiel IBM DB2 UDB haben Entwickler der SAP und der IBM gemeinsam eine Möglichkeit geschaffen, SAP-Daten mittels des Tools "DB2 Load" zu laden. Dies führt gegenüber den sonst üblichen einzelnen Insert-Operationen zu Laufzeitverbesserungen.

Inkrementeller Umstieg

Müssen Anwender große Systeme umstellen und gleichzeitig die Offline-Zeiten verkürzen, sollten sie eine inkrementelle Migration in Betracht ziehen. Hierbei werden kritische große Tabellen - welche im herkömmlichen Verfahren üblicherweise die Gesamtlaufzeit einer Migration bestimmen - während des produktiven Betriebs entladen. Daten aus diesen Tabellen lassen sich sukzessive in ein initial installiertes SAP-Zielsystem übertragen. Da sich die Inhalte der Tabellen im Quellsystem ständig ändern und somit im Zielsystem Inkonsistenzen aufweisen, werden alle Datenänderungen in speziellen Tabellen des produktiven Systems mitprotokolliert und Schritt für Schritt im Zielsystem nachgezogen.

In einem zweiten Projektabschnitt schaltet man das Quellsystem offline, alle noch anstehenden Änderungen aus den Protokolltabellen werden ins Zielsystem transferiert und die nicht inkrementell übertragenen Tabellen mittels R3load migriert.

Je nach der eingesetzten Datenbanksoftware können spezielle, von SAP unterstützte Verfahren zur Anwendung kommen, etwa für eine Betriebssystemumstellung. Sind die Datenbanksicherungen beispielsweise zwischen verschiedenen Unix-Derivaten kompatibel, lässt sich ein Wechsel des Betriebssystems mit deutlich vermindertem Aufwand realisieren.