Bevor Sie mit einem Partner für die Cloud-Migration unterschreiben, fragen Sie, wie er erfasst, was Sie betreiben, wie er für jede Anwendung eine Migrationsstrategie wählt, wie er die Zielumgebung entwirft und absichert, wie er jede Umstellung zurückrollen kann, wie er Ihnen die Kosten zeigt und wie er Ihr Team darauf vorbereitet, das Ergebnis zu betreiben. Konkrete, schriftliche Antworten sagen mehr über die bevorstehende Migration aus als der Tagessatz.
Fragen Sie, wie er herausfindet, was Sie tatsächlich betreiben
Ein Migrationsplan ist nur so gut wie das Inventar dahinter. Fragen Sie den Partner, wie er es aufbauen will: aus Interviews mit den Verantwortlichen der Anwendungen, aus Infrastrukturdaten wie Servermetriken und Netzwerkverbindungen, aus dem Code selbst oder aus allen dreien. Vorhandene Dokumentation ist ein Ausgangspunkt, kein Beweis, denn sie entfernt sich mit der Zeit von dem, was tatsächlich läuft.
Fragen Sie, was das Inventar erfassen wird und wem es danach gehört. Eine gute Antwort nennt die Felder und bestätigt, dass das Inventar bei Ihnen bleibt, wie auch immer Sie sich danach entscheiden.
- Jede Anwendung, ihre fachlich Verantwortlichen und wie kritisch sie ist
- Laufzeitumgebungen, Frameworks und Betriebssysteme, mit Markierung für alles am Supportende
- Datenbanken, Dateifreigaben, geplante Jobs und Queues, von denen jede Anwendung abhängt
- Integrationen in beide Richtungen, auch die, die niemand dokumentiert hat
- Lizenzen, die an Hardware oder Prozessorzahlen gebunden sind und sich womöglich nicht in die Cloud übertragen lassen
- Akzeptable Ausfallzeiten und der Geschäftskalender: Monatsabschluss, Hochsaison, regulatorische Fristen
Erwarten Sie eine Strategie pro Anwendung, nicht eine für den gesamten Bestand
Anwendungen ziehen auf unterschiedliche Weise in die Cloud. Die üblichen Optionen: eine Anwendung unverändert umziehen (Lift-and-Shift), sie mit kleinen Änderungen wie einer verwalteten Datenbank auf eine neue Plattform heben (Replatforming), sie für Cloud-Dienste umbauen (Refactoring), sie durch ein Software-as-a-Service-Produkt ersetzen, sie vorerst belassen, wo sie ist, oder sie stilllegen. Ein Partner, der für alles denselben Ansatz vorschlägt, hat nicht genau genug hingesehen.
Fragen Sie nach den Kriterien, nach denen er wählt, und lassen Sie sich vor der Unterschrift zeigen, wie er sie auf drei oder vier Ihrer eigenen Anwendungen anwendet. Seine Überlegungen zu Ihren echten Systemen sagen mehr als eine Methodenfolie. Fragen Sie insbesondere, wie er mit Anwendungen auf Laufzeitumgebungen am Supportende umgeht, denn ein unveränderter Umzug trägt die alten Risiken auf die neue Plattform.
Klären Sie, wer die Landing Zone entwirft und absichert
Die Landing Zone ist die vorbereitete Zielumgebung: Kontostruktur, Identitäten und Zugriffe, Netzwerk, Logging, Verschlüsselung und die Leitplanken, die jede Anwendung erbt. Ein Fehler an dieser Stelle wiederholt sich in jeder Anwendung, die dort landet. Fragen Sie, wer sie entwirft, ob sie als Code definiert ist, zum Beispiel mit Terraform, und ob Ihr Sicherheitsteam sie prüft, bevor die erste Anwendung umzieht.
Cloud-Sicherheit ist geteilte Verantwortung. Der Anbieter sichert die zugrunde liegende Infrastruktur, und Sie bleiben dafür verantwortlich, wie Sie sie konfigurieren und nutzen. Fragen Sie den Partner, welche Kontrollen er einrichtet, welche bei Ihrem Team bleiben und wie die Zugänge seiner eigenen Entwickler vergeben, protokolliert und am Ende wieder entzogen werden.
- Getrennte Konten oder Projekte pro Umgebung, mit isolierter Produktion
- Single Sign-on mit namentlichen Nutzern und Rollen nach dem Prinzip der minimalen Rechte, ohne gemeinsam genutzte Administrator-Zugangsdaten
- Zentrales Logging und Audit-Trails, die Projektentwickler nicht abschalten können
- Standardmäßige Verschlüsselung im Ruhezustand und bei der Übertragung, mit Secrets außerhalb des Codes
- Regionen, die so gewählt sind, dass sie Ihre Pflichten zu Datenresidenz und DSGVO erfüllen
Lassen Sie sich eine Umstellung und einen Rollback Schritt für Schritt erklären
Die Umstellung ist der Moment, in dem Traffic und Daten in die neue Umgebung wechseln, und dort ist eine Migration für das Geschäft am sichtbarsten. Bitten Sie den Partner, eine Umstellung für eine Ihrer Anwendungen Schritt für Schritt durchzugehen: wie die Daten synchronisiert werden, wie der Traffic umgeschaltet wird, welche Prüfungen danach laufen und wer entscheidet, dass es funktioniert hat.
Fragen Sie dann, wie er zurückgehen würde. Ein glaubwürdiger Plan nennt die Bedingungen, die einen Rollback auslösen, die Person, die entscheidet, und wie lange die alte Umgebung verfügbar bleibt. Wenn Nutzer seit der Umschaltung Daten in die neue Umgebung geschrieben haben, fragen Sie, wie diese Daten in die alte zurückkommen. Schwache Pläne übergehen diese Frage.
Unser Artikel über die Migration Hunderter Legacy-Apps zu AWS zeigt, wie diese Schritte in einem großen Bestand zu Runbooks werden.
Bestehen Sie darauf, die Kosten zu sehen, bevor die erste Rechnung kommt
Cloud-Kosten verhalten sich anders als die eines Rechenzentrums. Sie bezahlen, was läuft, auch Testumgebungen, die niemand abgeschaltet hat, Speicher, der immer weiter wächst, und Daten, die aus dem Netz des Anbieters übertragen werden. Verlangen Sie eine Kostenschätzung pro Anwendung mit schriftlich festgehaltenen Annahmen, und fragen Sie, wie der Partner sie in den ersten Monaten mit der tatsächlichen Nutzung abgleichen wird.
Kostentransparenz ist eine Designentscheidung, kein Monatsbericht. Verlangen Sie Tagging-Regeln, die jede Ressource einer Anwendung und einem Verantwortlichen zuordnen, Budgets und Alarme ab dem ersten Tag und eine Überprüfung der Instanzgrößen, sobald die Anwendungen unter echter Last gelaufen sind. Cloud-Server nach der alten Hardware zu dimensionieren ist ein sicherer Weg, für Kapazität zu bezahlen, die niemand nutzt.
Warnsignale, dass ein Migrationsangebot nicht ausgereift ist
Jedes davon kann eine Erklärung haben. Mehrere im selben Angebot bedeuten meist, dass Sie das Risiko selbst entdecken sollen.
- Ein fester Zeitplan, bevor jemand Ihr Inventar gesehen hat
- Eine einzige Migrationsstrategie für alle Anwendungen
- Kein schriftlicher Rollback-Plan oder ein Rollback, der darauf beruht, unter Druck Backups wiederherzustellen
- Cloud-Konten, Infrastruktur-Code oder Pipelines, die dem Partner gehören statt Ihnen
- Kostenschätzungen ohne Annahmen und kein Plan für Tagging oder Budgets
- Wissenstransfer, der für die letzte Woche angesetzt ist
Planen Sie den Wissenstransfer ab der ersten Woche, nicht erst in der letzten
Die Migration endet, der Betrieb der Plattform nicht. Fragen Sie, wie Ihr Team lernen wird, das Gebaute zu betreiben: gemeinsames Arbeiten an echten Aufgaben während der Migration, Runbooks für wiederkehrende Vorgänge und eine Einführung in Monitoring und Alarme für die Menschen, die Rufbereitschaft haben werden.
Verlangen Sie, dass alles von Anfang an in Ihren Konten und Repositories liegt: Infrastruktur-Code, Pipelines, Runbooks und Diagramme. Vereinbaren Sie dann, wie die Übergabe abgenommen wird, zum Beispiel indem Ihr Team eine Anwendung ohne Hilfe des Partners deployt und zurückrollt.
Wir haben im Team mitgearbeitet, das 600+ interne Anwendungen von Crédit Agricole von alten VMs zu AWS migriert hat, und 50+ dieser Migrationen selbst umgesetzt. Wenn Sie eine zweite Meinung zu einem Migrationsangebot möchten oder ein Team, das einen Teil der Arbeit liefert, können unsere Cloud-Infrastruktur-Entwickler diese Fragen mit Ihnen durchgehen.
Das Wichtigste in Kürze
- Fragen Sie, wie das Inventar aufgebaut und geprüft wird, denn jede Schätzung und jeder Wellenplan hängt davon ab.
- Erwarten Sie eine pro Anwendung gewählte Migrationsstrategie, mit Kriterien, deren Anwendung auf Ihre eigenen Systeme Sie sehen können.
- Lassen Sie die Landing Zone als Code definieren, von Ihrem Sicherheitsteam prüfen und in Ihren Konten führen.
- Akzeptieren Sie keinen Umstellungsplan ohne benannten Rollback-Auslöser und ohne Weg, nach der Umschaltung geschriebene Daten zurückzuholen.
- Vereinbaren Sie Tagging, Budgets und die Abnahme der Übergabe, bevor die erste Anwendung umzieht.
FAQ
Sollte der Partner, der unseren Bestand bewertet, ihn auch migrieren?
Das kann er, und oft spart es Zeit, weil das Team, das das Inventar erstellt hat, die Sonderfälle kennt. Kaufen Sie die Bewertung als eigenständiges Ergebnis ein, das Ihnen gehört, damit Sie damit zu einem anderen Partner gehen können, falls das Migrationsangebot Sie nicht überzeugt.
Wie vergleicht man Angebote verschiedener Migrationspartner?
Geben Sie jedem Partner denselben Auszug aus dem Inventar und dieselben Fragen und bitten Sie jeden, seine Kriterien auf dieselben wenigen Anwendungen anzuwenden. Vergleichen Sie die Begründungen, die Rollback-Pläne und die Annahmen hinter den Schätzungen, nicht nur den Gesamtpreis.
Kann unser Team während der Migration weiter Features ausliefern?
Ja, wenn der Plan festlegt, wie. Vereinbaren Sie für jede Anwendung ein Freeze-Fenster für Änderungen, einen Weg, beide Umgebungen während des Umzugs synchron zu halten, und wer Releases freigibt, solange eine Anwendung mitten im Umzug ist.