On-Premise → EU-Cloud-Migration — Engagement-Muster
Wie wir eine Migration von alternder On-Premise-Infrastruktur auf eine EU-Cloud-Plattform (Hetzner, Azure oder AWS) umsetzen — mit Containerisierung und CI/CD.
Illustratives Engagement-Muster. Diese Seite beschreibt typischen Umfang, Phasen und Ergebnisse einer Cloud-Migration, wie wir sie umsetzen. Sie ist keine konkrete Kundenreferenz. Tatsächliche Projekte unterliegen NDAs der Kunden; spezifische Referenzen besprechen wir auf Anfrage unter NDA.
Wann dieses Engagement passt
Eine mittelständische Organisation mit alternder On-Premise-Infrastruktur: Hardware kurz vor End-of-Life, Wochenend-Wartungsfenster, die das Business nicht mehr toleriert, Skalierung über Beschaffung statt über Klicks, eine Backup-Story, die seit achtzehn Monaten niemand wiederhergestellt hat, und ein internes Team, das die meiste Zeit auf Vorfälle reagiert statt die Plattform zu verbessern.
Die typische Ausgangslage
Die Anwendungen selbst sind meist in Ordnung. Das Problem ist das Fundament: physische Server in einem Raum mit einem einzigen Uplink, manuelle Deployment-Skripte, die nur eine Person vollständig versteht, Datenbanken auf den jeweils freien Festplatten und ein Backup-Band, dessen Restore-Fähigkeit unklar ist.
Wie wir das Engagement aufsetzen
- Workload-Inventur und Re-Host- / Re-Platform-Entscheidungen — für jede Anwendung entscheiden wir, ob sie als VM in die Cloud gehoben wird, in Container re-platformiert wird oder vor Ort bleibt, weil der Migrationsaufwand den Nutzen übersteigt.
- Zielplattform-Auswahl — Hetzner (EU) für kostensensitive Workloads, bei denen die Hetzner-Rechenzentren die Datenresidenz erfüllen; Microsoft Azure oder AWS, wenn der Kunde spezifische Plattformdienste benötigt oder bereits Tenant ist. Die Wahl erfolgt pro Workload, nicht firmenweit.
- Containerisierung mit Docker — Anwendungen, die davon profitieren, ziehen in Container, sodass Dev / Test / Prod reproduzierbar sind und Rollbacks sauber funktionieren.
- Kubernetes, wo es sich rechnet — für Workloads, die echtes Autoscaling, Self-Healing oder Rolling Deployments brauchen. Für alles andere ist eine einfachere Container-Runtime ehrlich gegenüber dem tatsächlichen Bedarf.
- CI/CD-Pipelines — automatisierte Builds, Tests und Deployments über GitHub Actions oder Azure DevOps. Deploys hören auf, ein Kalenderereignis zu sein.
- Datenbankmigration — PostgreSQL (oder die Engine, die der Kunde fährt) wandert mit einem getesteten Cutover-Plan und verifizierter Datenintegrität in die Cloud. Das Cutover-Fenster wird angekündigt, nicht improvisiert.
Was eine gut geführte Migration liefert
Infrastruktur, die auf Knopfdruck skaliert statt auf Beschaffung. Deploys, die Routine sind statt Zeremonie. Backups, die getestet sind. Monitoring, das anschlägt, wenn wirklich etwas brennt, und ansonsten ruhig bleibt. Eine Run-Rate-Kostensicht, die transparent ist — im ersten Jahr nicht immer günstiger als On-Premise, aber planbar, steuerbar und an die tatsächliche Nutzung gekoppelt.
Für eine konkrete Einschätzung einer Cloud-Migration in Ihrer Umgebung siehe die Seite Cloud-Infrastruktur-Service oder kontaktieren Sie uns.