STACKIT-MIGRATIONS-ASSESSMENT
STACKIT-Migrations-Assessment
Bevor Budgets freigegeben werden, muss die Leitung wissen, was der Wechsel umfasst. Ein StackToIT-Assessment beantwortet das aus Ihrem Infrastrukturcode: jede Ressource, ihr STACKIT-Ziel, der Aufwand und die nötigen Entscheidungen.
Was Ihr Assessment beantwortet
Was umzieht und wie
Jede Migrationseinheit mit Klasse, STACKIT-Ziel und Begründung, vom direkten Umzug bis zu Diensten, die ein Redesign brauchen.
Was es erfordert
Ein geordneter Ausführungsplan mit Voraussetzungen, Datenumzug, Cutover und Prüfschritten.
Was entschieden werden muss
Ein Entscheidungsregister mit Verantwortlichen: die Architekturfragen, die der Code nicht beantwortet, früh benannt.
Ihr Assessment-Paket
Geliefert als Dateien: lesbar im Browser, versionierbar in Git und maschinenlesbar für Ihre eigenen Werkzeuge.
- index.html
- Das vollständige Assessment, Einheit für Einheit, offline in jedem Browser
- executive/
- Zusammenfassung und Entscheidungen für die Leitung
- architecture/
- Diagramme der aktuellen und der Zielarchitektur
- terraform/
- STACKIT-Terraform für das Ziel
- migration/
- Migrationsplan und Arbeitspakete
- execution/
- Geordneter Ausführungsplan mit Prüfschritten
- financial/
- Bepreiste Kostenpositionen aus öffentlichen Preislisten
- engineering/
- Architektenbericht, Befunde und Nachweiskette
- assessment.json
- Jedes Ergebnis in strukturierter, maschinenlesbarer Form
So läuft ein Projekt ab
Umfang
Wir vereinbaren eine Umgebung: Terraform oder OpenTofu von AWS, Azure, Google Cloud, Huawei Cloud, Alibaba Cloud oder Oracle Cloud, oder einen VMware-RVTools-Export.
Lauf
Sie führen StackToIT auf Ihrem eigenen Rechner aus. Ihr Code bleibt bei Ihnen, und es werden keine Cloud-Zugangsdaten benötigt.
Prüfung
Ihre Architekten arbeiten das Paket durch und beantwortet die offenen Entscheidungen. Der nächste Lauf liest die Antworten ein.
Entscheidung
Die Leitung erhält einen Migrationsumfang auf Basis von Engineering-Fakten, bereit für Budget und Planung.
Was ein echtes Assessment enthält
Aus dem veröffentlichten Lauf zum AWS Retail Store: fünf Services auf Amazon ECS mit Aurora, DynamoDB, OpenSearch, ElastiCache und Amazon MQ.
Quelle gelesen
105 Dateien und 23 Modulaufrufe, davon 13 Registry-Module, aufgelöst zu 282 Ressourcen und 44 Migrationseinheiten.
Klassifiziert
34 Einheiten sind Reconfigure, 9 Replatform und 1 Redesign. Jede trägt ein STACKIT-Ziel, eine Konfidenz und eine Begründung.
Entworfen
Von 52 Einheiten, die der Entwurf betrachtet hat, wurden 38 zu STACKIT-Terraform, 11 brauchen auf STACKIT keine Ressource und 3 sind manuelle Arbeit.
Geplant
331 Planschritte, davon 57 durch OpenTofu oder ein Skript ausgeführt. 96 Schritte betreffen Cutover, Prüfung und Stilllegung.
Gefragt
16 zu treffende Entscheidungen, jeweils mit einer benannten verantwortlichen Rolle und Optionen zur Auswahl.
Wer was bearbeitet
Das Paket weist Arbeit Rollen zu, sodass ein Lenkungskreis vor dem Pilotprojekt sieht, wer was beantworten muss.
45 Arbeitspakete
Verantwortlich sind Network Architect (11), Platform Architect (10), Security Architect (7), Data Architect (7), Identity Architect (6), Migration Owner (3) und Storage Architect (1).
Neun Phasen
Prepare, Foundation, Platform, Security, Workload, Data, Cutover, Verify und Decommission: Jedes Team sieht seinen Anteil und dessen Platz in der Reihenfolge.
112 Entscheidungseinträge
Jeder nennt die Rolle, die ihn beantwortet: Network Architect 34, Platform Architect 27, Identity Architect 21, Security Architect 19, Data Architect 6. Fünf nennen keine Rolle.
Bewiesen an einer echten AWS-Umgebung
Die AWS Retail Store Sample App, ein öffentliches Terraform-Projekt von AWS, von StackToIT bewertet und vollständig veröffentlicht, genau so, wie der Lauf es geschrieben hat.
Fallstudie ansehen (Englisch)- 282
- Terraform-Ressourcendefinitionen analysiert
- 44
- Migrationseinheiten identifiziert
- 38
- Zieleinheiten erzeugt, von 52 betrachteten
- 331
- Planschritte erstellt
Fragen aus der Leitung
Was umfasst ein STACKIT-Migrations-Assessment?
Jede Ressource klassifiziert und STACKIT zugeordnet, Diagramme der Zielarchitektur, STACKIT-Terraform, einen Ausführungsplan, bepreiste Kostenpositionen und ein Entscheidungsregister.
Müssen wir unseren Code teilen?
Nein. StackToIT läuft auf Ihrem eigenen Rechner, liest Ihre Dateien lokal und braucht keine Cloud-Zugangsdaten. Sie bestimmen, was Sie mit uns teilen.
Welche Umgebungen lassen sich bewerten?
Terraform- und OpenTofu-Umgebungen von AWS, Microsoft Azure, Google Cloud, Huawei Cloud, Alibaba Cloud und Oracle Cloud sowie VMware-Umgebungen, die mit RVTools exportiert wurden.
Ändert das Assessment etwas in unserer Cloud?
Nein. StackToIT liest und schreibt Dateien. Es erstellt, ändert und löscht nichts in einer Cloud und überträgt keine Daten. Jeden Schritt führt eine Person, OpenTofu oder ein Skript aus, das Sie selbst starten.
Woran erkennen wir, dass das Paket vollständig ist?
stacktoit verify prüft das Paket gegen sein Manifest. Für den Retail-Store-Lauf meldete es 145 Dateien, die nach Größe und SHA-256 übereinstimmen, und 7 von 7 bestandene Prüfungen.
Welche Schritte können sofort starten?
Das Paket gibt das für jeden Schritt an. Im Retail-Store-Lauf sind 48 der 57 automatisierten Schritte frei von Entscheidungen und manuellen Voraussetzungen. Sie warten nur auf Werte wie project_id, die Sie liefern.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.