Was wir aufbauen
- Cloud-Foundations. Ein Multi-Account-Setup (AWS Organizations, GCP-Folder oder Azure Management Groups) mit SSO, Guardrails und zentralem Logging. Warum das vom ersten Tag an zählt (auf Englisch).
- Networking. VPCs, private Subnetze, VPN oder Direct Connect zu allem, was on-prem bleibt, und ausgehender Traffic, der nicht still und leise ein Vermögen kostet.
- Passende Compute-Lösung. Managed Container (ECS, Cloud Run), Kubernetes, wenn es sich lohnt, oder schlichte VMs, wenn das die richtige Antwort ist.
- Daten. Managed-Datenbanken, ein Cutover per Replikation, damit die Downtime bei Minuten bleibt, und Backups, die vor dem Go-live getestet sind.
- Pipelines. CI/CD, das einmal baut und dasselbe Artefakt nach Staging und Production bringt.
- Alles in Terraform. Dokumentiert, per Pull Request reviewt und an Ihr Team übergeben.
So läuft eine Migration ab
- Bestandsaufnahme. Jeder Server, jede Datenbank, jeder Cronjob, jeder DNS-Eintrag und jede Drittanbieter-Abhängigkeit, jeweils mit einem Verantwortlichen.
- Zielarchitektur. Region (Frankfurt, Mailand oder die neue Athens Local Zone für latenzkritische Workloads), Compute-Wahl, Datenplan und eine Kostenschätzung.
- Foundations und Pipelines. Aufgebaut und getestet, bevor auch nur ein Request aus Production umzieht.
- Generalprobe. Ein kompletter Probelauf des Cutovers in Staging, mit Zeitmessung und Rollback-Plan.
- Cutover. Daten vorab repliziert, DNS mit niedrigen TTLs umgestellt, die alte Umgebung bleibt warm, bis Sie sich sicher sind.
- Die ersten 30 Tage. Kosten-Guardrails, Alerts und Right-Sizing, sobald echter Traffic zeigt, was Sie wirklich brauchen.
Die vollständige Checkliste, mit der wir arbeiten, finden Sie in unserer Cloud-Migrations-Checkliste (auf Englisch).
Für wen es gedacht ist
- Unternehmen, die auf einem VPS, bei einem klassischen Hosting-Anbieter oder auf eigenen Servern laufen und an Grenzen stoßen.
- Teams, die Heroku-artige Plattformen wegen der Kosten oder fehlender Kontrolle verlassen wollen.
- Startups vor dem Produktlaunch, die das Fundament richtig legen wollen, bevor der erste Kunde kommt, und nicht erst nach dem ersten Incident.
Häufige Fragen
Wie lange dauert eine Cloud-Migration?
Eine kleine Anwendung mit einer Datenbank dauert meist ein paar Wochen. Ein Unternehmen mit mehreren Services, Umgebungen und Integrationen braucht typischerweise zwei bis sechs Monate. Nach der Bestandsaufnahme haben Sie einen realistischen Zeitplan, bevor Sie sich festlegen.
Gibt es Downtime?
Wir planen mit Minuten, nicht mit Stunden. Datenbanken werden vorab repliziert und DNS wird mit niedrigen TTLs umgestellt, das Cutover-Fenster ist also kurz und geprobt. Manche Altsysteme brauchen ein Wartungsfenster; das sagen wir Ihnen vorher.
In welche Cloud sollten wir wechseln?
Für die meisten Startups ist AWS die naheliegende Wahl, aber GCP und Azure haben in bestimmten Fällen die Nase vorn, etwa bei datenintensiven Produkten oder in Unternehmen, die stark auf Microsoft setzen. Unser Vergleich AWS vs. GCP vs. Azure (auf Englisch) zeigt die Abwägungen.
Brauchen wir Kubernetes?
Oft nicht. Für eine Handvoll Services sind Managed Container wie ECS oder Cloud Run günstiger und einfacher zu betreiben. Kubernetes empfehlen wir, wenn Sie viele Services, Plattform-Teams oder Multi-Cloud-Anforderungen haben. Mehr dazu unter Kubernetes-Beratung.
Bleiben unsere Daten in der EU?
Ja. Wir setzen standardmäßig auf EU-Regionen und dokumentieren, wo jedes Datum und jedes Log liegt. Das hilft auch bei DSGVO und NIS2.