Umfang und Dauer schätzen

Erst messen, dann planen

Volumen aus der Analyse, Geschwindigkeit aus dem Pilot, vier Jobs gleichzeitig — und aus diesen drei Größen ergibt sich der Plan für jede Welle.

Wovon die Dauer abhängt

Keine zwei Migrationen laufen gleich schnell, denn die entscheidenden Faktoren unterscheiden sich von Organisation zu Organisation:

Faktor	Warum er wichtig ist	Wo Sie ihn sehen
Volumen einschließlich Versionen	Die Migrationsgeschwindigkeit wird daran gemessen, und der Versionsverlauf kann ein Vielfaches der Größe der aktuellen Dateien ausmachen	Analyse, im Laufverlauf und im Power-BI-Bericht
Anzahl der Dateien	Jede Datei wird einzeln verarbeitet, daher dauern viele kleine Dateien länger als dasselbe Volumen in wenigen großen	`File Count` eines Laufs
Umfang des Versionsverlaufs	Weniger Versionen pro Datei bedeuten weniger zu übertragendes Volumen	Die Versionseinstellungen des Jobs
Die Dateifilter	Nach Datum, Größe oder Typ ausgeschlossene Inhalte werden gar nicht übertragen	Die erweiterten Einstellungen des Jobs
Drosselung durch Microsoft 365	Microsoft 365 verlangsamt umfangreiche oder häufige Lesezugriffe	`SPO Rate Limit Delay` in den Laufdetails
Vier Jobs gleichzeitig	Der SMART-Migration-Server führt höchstens vier Jobs gleichzeitig aus	Die laufenden Jobs in der Übersicht
Die Edition	Enterprise+ migriert mit bis zu dreifacher Enterprise-Geschwindigkeit	Ihre Lizenz

Schritt 1: Das Volumen mit der Analyse messen

Führen Sie die Analyse für alles aus, was zum Umfang gehört – ein Import-Job erstellt die Jobs für einen ganzen Tenant, eine Site oder alle OneDrives. Lesen Sie dann das Volumen ab:

Pro Lauf im Laufverlauf: Files, Volume, Versions und Version volume. Diese Werte zählen die neuen und die geänderten Dateien. Bewegen Sie den Mauszeiger auf den Titel eines Analyse-Laufs, um seine Karte anzuzeigen; deren Total rechnet die unveränderten Dateien hinzu – die gesamte Quelle, wie der Lauf sie vorgefunden hat.
Pro Bibliothek, Site und Welle im Power-BI-Bericht, mit dem Volumen einschließlich Versionsverlauf und dem Alter der Inhalte.

Entscheiden Sie vor der Schätzung, was zurückbleibt: Inhalte, die seit Jahren niemand geöffnet oder geändert hat, Archive und Versionen, die Sie nicht benötigen. Jedes ausgelassene Gigabyte spart in jeder Welle Zeit.

Schritt 2: die Geschwindigkeit mit einer Pilotwelle messen

Führen Sie eine Pilotwelle mit Bibliotheken, die für den Rest typisch sind, als Jobs vom Typ Migration aus. Öffnen Sie für jeden Lauf seine Details:

Duration und Volume ergeben die Geschwindigkeit eines Jobs: das Volumen geteilt durch die Dauer, zum Beispiel in Gigabyte pro Stunde.
SPO Rate Limit Delay zeigt, wie viel der Dauer auf die Drosselung durch Microsoft 365 entfiel.

Verwenden Sie die Geschwindigkeit der größeren Läufe des Pilots: Kleine Läufe verbringen einen größeren Teil ihrer Zeit mit dem Starten und Abschließen.

Schritt 3: die Wellen berechnen

Teilen Sie für jede Welle ihr Volumen durch die Geschwindigkeit eines Jobs und das Ergebnis durch vier für die gleichzeitig laufenden Jobs:

Die Schätzung für eine Welle

Stunden ≈ Volumen der Welle einschließlich Versionen ÷ Geschwindigkeit eines Jobs ÷ 4

Ein Pilot, dessen Läufe 40 GB in 8 Stunden übertragen haben, migriert zum Beispiel 5 GB pro Stunde und Job. Eine Welle von 600 GB dauert dann etwa 600 ÷ 5 ÷ 4 = 30 Stunden. Die Zahlen dienen nur zur Veranschaulichung — verwenden Sie die Ihres eigenen Pilots.

Rechnen Sie dann hinzu, was keine Migrationszeit ist:

Prüfung und Abnahme. Die Verantwortlichen prüfen jede Welle vor der nächsten, meist über einige Tage.
Ein Puffer für Drosselung. Vier große Bibliotheken gleichzeitig lesen intensiver als eine, und Microsoft 365 kann alle vier verlangsamen.
Die abschließende Synchronisierung vor der Umstellung, die nur Änderungen kopiert und kurz ist.
Ein Puffer für Unterbrechungen. Netzwerkausfälle, Serverneustarts und Updates, fehlende Berechtigungen, geöffnete Dateien und abgelaufene Anmeldedaten kommen in jeder realen Migration vor, und jede davon kostet die Zeit, bis jemand es bemerkt und den Job erneut ausführt. Bemessen Sie den Puffer anhand Ihres Pilots, den Sie über normale Arbeitstage laufen lassen.

Auch Scans brauchen Zeit

Ein Tenant-Scan, der die Jobs erstellt, liest 30 bis 50 Sites pro Minute — etwa 30 bis 40 Minuten pro 1.000 Sites. Planen Sie ihn vor der Analyse ein, die dann pro Bibliothek ihre eigene Zeit benötigt.

Die Migration verkürzen

Lassen Sie weg, was niemand nutzt, mit From Date, und die nicht benötigten Dateitypen mit Source File Type.
Begrenzen Sie die Versionen mit Version History Scope.
Lassen Sie rund um die Uhr laufen: Setzen Sie Scheduled Date auf den Abend oder das Wochenende, und geben Sie den größten Jobs eine hohe Priority, damit sie zuerst starten.
Verteilen Sie die größten Bibliotheken auf die Wellen, statt sie parallel laufen zu lassen.
Halten Sie das Ziel mit wiederkehrenden Jobs aktuell, damit der letzte Lauf vor der Umstellung klein ist.
Enterprise+ migriert mit bis zu dreifacher Enterprise-Geschwindigkeit.

Lassen Sie Ihren Partner schätzen

Ihr SMART-Migration-Partner kann die Schätzung gemeinsam mit Ihnen anhand des Analyseberichts und des Pilots erstellen und daraus einen Zeitplan und ein Angebot machen.

Sobald die Migration läuft, hält der Bereich Migrationsfortschritt in der Übersicht die Schätzung aktuell: Er berechnet die verbleibende Zeit und den Durchsatz aus den Läufen selbst, als Arbeitszeit ohne die Stunden, in denen nichts lief — siehe Was eine Migration umfasst und was ihre Geschwindigkeit bestimmt

Siehe auch