Zum Hauptinhalt springen

Azure Migration

Ihre Workloads auf Azure umgezogen, mit dem Cutover geprobt, bevor er echt ist.

Wir migrieren Ihre Server, Anwendungen und Daten auf Azure auf einer Governance-konformen Landing Zone, in Wellen, mit jedem Cutover getestet, bevor er läuft. Sie erhalten die Umgebung auf Azure, die alte Infrastruktur stillgelegt und ein Team, das weiß, wie man sie betreibt.

Investition
Pro Projekt
Dauer
3–6 Monate
Format
Remote-first, vor Ort für Cutover

Auf einen Blick

Investition
Pro Projekt
Dauer
3–6 Monate
Format
Remote-first, vor Ort für Cutover
Märkte
DACH und Benelux

Für wen es gedacht ist

  • Ein Rechenzentrums-Vertrag oder eine Hardware-Erneuerung erzwingt einen Umzug, und Sie wollen ihn auf Azure statt auf neue Hardware.
  • Eine frühere Migration blieb stecken oder hat Workloads unverändert verschoben und teuer und fragil hinterlassen.
  • Sie brauchen den Umzug geordnet und geprobt, nicht an einem Wochenende durchgezogen auf gut Glück.
  • Ihr aktueller Hosting-Vertrag läuft bald mit einer Preiserhöhung aus, und Sie wollen die Azure-Zahl in der Hand haben, bevor Sie verhandeln oder gehen.
  • Sie migrieren SAP zusammen mit der allgemeinen Infrastruktur und brauchen beides aufeinander abgestimmt, nicht als getrennte Projekte, die sich gegenseitig behindern.

Umfang und Format

Drei bis sechs Monate, je nach Größe der Umgebung, remote-first mit Vor-Ort-Präsenz für den Cutover. Wir bewerten und gruppieren Workloads in Migrationswellen, bauen oder nutzen die Azure Landing Zone und migrieren dann Welle für Welle: Rehost, Replatform oder Re-Architect pro Workload, jeweils mit getestetem Cutover und Rollback. Geleitet von einem Team, das über 1.000 Server und über 300 Anwendungen nach Azure migriert hat, darunter eine gerettete Migration einer nationalen Fluggesellschaft. Wir legen die alte Infrastruktur still, sobald jede Welle landet, und übergeben den Betrieb.

Was Sie erhalten

Migrationsplan und Wellen-Gruppierung

Workloads nach Abhängigkeit und Risiko in Wellen gruppiert, mit dem Ansatz pro Workload: Rehost, Replatform oder Re-Architect.

Landing Zone bereit für den Umzug

Die Governance-konforme Azure-Grundlage, auf der die Workloads landen, gebaut oder aus einer bestehenden genutzt.

Migrierte Workloads, Welle für Welle

Jede Welle verschoben, getestet und mit geprobtem Rollback umgeschaltet, nicht in einem einzigen Wochenende.

Datenmigration und Validierung

Datenbanken und Daten verschoben, mit auf beiden Seiten geprüfter Integrität vor dem Cutover. Das schließt SQL-Server- und Azure-SQL-Umgebungen ein, ebenso SAP-Workloads, die in derselben Welle mitziehen.

Stilllegung der Altsysteme

Die alte Infrastruktur abgebaut, sobald jede Welle landet, damit Sie nicht doppelt zahlen.

Performance-Baseline nach dem Umzug

Jeder migrierte Workload dreißig Tage gegen seine Performance vor dem Umzug geprüft, damit eine Regression als Nachweis auffällt, nicht als Support-Ticket sechs Monate später.

Übergabe und Runbook

Betrieb dokumentiert und eine Arbeitssitzung, damit Ihr Team die Umgebung betreibt, nachdem wir gehen.

Preis

Pro Projekt kalkuliert. Wir kalkulieren gegen Zahl und Komplexität der Workloads und legen die Zahl vor der ersten Welle fest.

Wenn Sie in den letzten acht Wochen ein Microsoft Landscape Assessment oder ein Azure Architecture Review mit uns gemacht haben, wird dieses Festhonorar von diesem Projekt abgezogen.

Wo Ihre Daten liegen

Die Migration läuft in Ihren Tenant, in die Azure-Region, an die Sie gebunden sind. Der Zugriff folgt dem Least-Privilege-Prinzip und ist auf das Projekt beschränkt. Wo Datenresidenz zählt, wird die Landing Zone in der Azure-Region Germany West Central konfiguriert, und wir unterzeichnen Ihren Auftragsverarbeitungsvertrag, bevor wir beginnen.

Governance und Compliance

  • In Ihrem Tenant und Ihrer Region gebaut und migriert, mit Residenz in der Landing Zone durchgesetzt.
  • Jeder Cutover mit geprobtem Rollback getestet, bevor er in Produktion läuft.
  • Datenintegrität auf beiden Seiten jedes Datenumzugs validiert.
  • Ein unterzeichneter Auftragsverarbeitungsvertrag vor dem Start.
Unseren Governance-Ansatz lesen

Häufige Fragen

Wie lange dauert es?

Drei bis sechs Monate, je nach Größe und Komplexität der Umgebung.

Lift-and-Shift oder modernisieren?

Pro Workload. Manche werden unverändert rehostet, manche lohnen ein Replatform oder Re-Architect unterwegs. Der Plan sagt vor jedem Umzug, welches und warum.

Wie steht es um Ausfallzeiten?

Jeder Cutover ist geplant und mit Rollback geprobt. Die meisten Workloads ziehen mit minimaler oder keiner Ausfallzeit um; die wenigen, die ein Fenster brauchen, bekommen eines, das Sie vorab vereinbaren.

Betreiben Sie es danach?

Wir übergeben an Ihr Team mit einem Runbook und einer Arbeitssitzung. Wenn wir es weiter betreiben sollen, vereinbaren wir das separat.

Was, wenn unsere Migration schon feststeckt oder schiefläuft?

Wir haben schon mitten im Projekt übernommen, darunter eine Migration einer nationalen Fluggesellschaft, die feststeckte. Wir prüfen, was schon läuft und was nicht funktioniert, und planen die restlichen Wellen neu, statt bei null anzufangen.

Wer entscheidet, ob ein Cutover zurückgerollt wird?

Sie und Ihr Change Board legen das Rollback-Kriterium fest, bevor die Welle startet, nicht live während des Cutovers. Besteht ein Workload die Prüfung nach dem Umzug nicht, rollen wir nach diesem vereinbarten Kriterium zurück und versuchen es im nächsten Fenster erneut.

Was passiert mit Systemen, die nicht auf Azure umziehen können?

Manche Workloads ziehen nicht um: eine Anwendung, die an bestimmte Hardware gebunden ist, eine Abhängigkeit, die Sie nicht anfassen können. Wir kennzeichnen das im Wellenplan und schließen sie entweder aus der Migration aus oder isolieren sie auf der Altumgebung, bis sie ersetzt werden, statt einen Umzug zu erzwingen, der etwas zerstört.

Migrieren Sie SAP-Workloads?

Ja, als Teil desselben Wellenplans, wenn SAP im Umfang ist. SAP-Umzüge bekommen ihr eigenes Testing und ihre eigene Cutover-Probe innerhalb der Welle, die sie trägt, da die Toleranz für Ausfallzeiten dort meist geringer ist.

Was, wenn wir später den Hyperscaler wechseln wollen, statt dauerhaft auf Azure zu bleiben?

Das ist ein anderes Gespräch als dieses Projekt. Was wir bauen, die Landing Zone und die Workload-Architektur, ist gut genug dokumentiert, um bei Bedarf erneut umzuziehen, aber ein Wechsel weg von Azure ist nicht Teil dieses Umfangs.

Wie kalkulieren Sie eine Migration, bevor die vollständige Workload-Anzahl bekannt ist?

Wir führen zuerst einen kurzen Discovery-Schritt durch, meist im Rahmen eines Azure Architecture Review oder eines Microsoft Landscape Assessment, um eine genaue Workload-Anzahl und Komplexität zu ermitteln. Der Migrationspreis wird gegen diese Zahl festgelegt, nicht gegen Komplexität, die erst mitten im Projekt auftaucht.

Projekt anfragen