Cloud-Migration

Cloud-Migration mit geprobter Umstellung und Rückweg.

Bei einem Infrastruktur-Umzug geht es vor allem um das, was niemand aufgeschrieben hat: versteckte Abhängigkeiten, Daten, die sich schwer bewegen lassen, und Kosten, die ihre Form ändern. Wir erfassen, was läuft, entwerfen das Ziel, schreiben es als Code und proben Umstellung und Rollback, bevor die Produktion umzieht.

Cloud-Migration abgrenzen →

KURZ ERKLÄRT

Cloud-Migration bringt vereinbarte Workloads in eine Cloud, zwischen Providern oder hinaus auf selbst betriebene Infrastruktur. Der Auftrag umfasst Inventar, Zielarchitektur, Infrastructure as Code, eine geprobte Umstellung mit Rollback und Transparenz darüber, was das neue Setup kostet.

Passt für

Teams, die von händisch verwalteten Servern auf ein reproduzierbares Setup wechseln
Unternehmen, die den Provider wechseln oder Workloads aus Kosten- oder Kontrollgründen zurück ins Self-Hosting holen

Eine andere Leistung passt besser

Die Härtung einer Umgebung, die du behalten willst
Ein Neubau der Anwendung während des Umzugs

Erst klären, warum du umziehst, dann wohin

Kosten, Kontrolle, Datenstandort, ein auslaufender Vertrag oder eine Plattform, die nicht mehr passt: alles gute Gründe, und jeder verändert das Ziel. Ein Umzug kann in eine Cloud führen, zwischen Providern oder hinaus auf eigene Server. Ist deine bestehende Umgebung grundsätzlich in Ordnung und braucht nur sichere Zugänge und Wiederherstellung, passt Cloud Security besser. Kontrollen in Build- und Release-Pipeline gehören zu DevSecOps. Muss die Anwendung selbst ihre Architektur ändern, plane das als Legacy-Modernisierung. Eine Migration, die nebenbei die Anwendung neu schreibt, verdoppelt das Risiko jedes Schritts.

Aus dem, was heute läuft, ein Ziel machen, das sich neu aufbauen lässt

Provider und Plattform klären wir beim Scoping. Einen universellen Multi-Cloud-Service setzen wir nicht voraus.

Inventar und Abhängigkeiten

Workloads, Datenspeicher, DNS, Zertifikate, geplante Jobs, externe Integrationen, IP-Allowlists und die jeweils Verantwortlichen.

Zielarchitektur

Je Workload Managed Services, Container, virtuelle Maschinen oder eigene Server wählen und die Abwägung zu Kosten, Lock-in und Betriebsaufwand festhalten.

Infrastructure as Code

Die Zielumgebung in versioniertem Code beschreiben (zum Beispiel Terraform oder OpenTofu), damit sie geprüft, neu aufgebaut und übergeben werden kann.

Kostentransparenz

Ressourcen taggen, Budgets und Alerts setzen und die erwartete Rechnung mit dem alten Setup vergleichen. Eine Schätzung bleibt eine Schätzung, bis echter Traffic läuft.

Umstellung und Rollback proben

Jede Migrationswelle hat einen Plan für Datenübertragung oder Synchronisation, DNS- und Zertifikatsschritte, bei Bedarf einen Änderungsstopp, Prüfungen, die zeigen, dass die neue Umgebung korrekt ausliefert, und einen Rollback-Auslöser mit benannter Verantwortung. Daten, die nach der Umstellung geschrieben werden, fließen nicht unbedingt automatisch zurück. Der Plan hält deshalb fest, wie lange ein Rollback möglich bleibt und was er kostet. Ausfallfenster, falls nötig, werden vorab vereinbart.

Illustrative Abnahme: ein geprobter Wechsel auf einer Staging-Kopie

Auf einer Staging-Kopie folgt das Team dem Umstellungs-Runbook, lenkt den Traffic auf die neue Umgebung, führt die vereinbarten Funktions- und Datenprüfungen aus und schaltet dann zurück. Das Protokoll nennt Runbook-Version, Dauer, Datenprüfungen, gefundene Probleme und Grenzen. Das illustriert einen Abnahmetest, kein Kundenresultat und kein Versprechen ohne Ausfallzeit.

Planen, in Wellen migrieren, übergeben

Umfang und Angebot vereinbaren wir je Phase vor Beginn. Der laufende Betrieb ist eine eigene Verantwortung, keine stillschweigende Verlängerung der Migration.

Assessment und Plan
Du erhältst das Inventar, Zieloptionen mit Abwägungen, einen Wellenplan und eine Kostenschätzung samt Annahmen.
Aufbau und Migration
Du erhältst den Infrastruktur-Code, migrierte Workloads und ein Prüfprotokoll je Umstellung.
Übergabe
Du erhältst Runbooks, das Zugriffsmodell und Kostenberichte. Wer danach was betreibt, wird ausdrücklich vereinbart; Wavect bietet kein 24/7-Betriebszentrum und kein Uptime-SLA.

Rechnungen, Architektur und eine Person mitbringen, die Änderungen freigibt

Wir brauchen zuerst Lesezugriff auf Accounts und Hosting, Architekturnotizen, aktuelle Rechnungen, Datenmengen, Anforderungen an den Datenstandort, mögliche Wartungsfenster und eine Person, die Produktionsänderungen freigeben darf. Folgt der Umzug auf eine Anbieterübergabe, sieh dir die Übung zur operativen Unabhängigkeit bei der Software-Übernahme an. Deren bestehende Voraussetzungen und Bedingungen gelten. Die laufende Pflege der Anwendung nach dem Umzug ist Software-Wartung.

// beweise

Infrastruktur-Umzüge in bestehender Engineering-Arbeit

Hyperstate AI dokumentiert den Umzug eines händisch deployten, GPU-lastigen Einzelservers auf dockerisierte, orchestrierte Services und den Ersatz selbst betriebener, rechenintensiver Bibliotheken durch gehostete Alternativen. Twinsoft AI dokumentiert Terraform-Infrastruktur, parallel zu einem pilotfähigen Neuaufbau. IKB dokumentiert die Erweiterung des Kubernetes-Clusters, auf dem ChirpStack läuft, als Teil der Engineering-Arbeit innerhalb des IKB-Aufbaus, mit vollständiger Übergabe an das IKB-Team. Keiner dieser Fälle ist ein kompletter Rechenzentrumsumzug von Provider zu Provider; es ist benachbarte Infrastrukturarbeit, kein Versprechen desselben Ergebnisses.

GPU-Monolith → Microservices

GPU-lastigen Monolithen in orchestrierte Services zerlegt und selbst gehostete ML-Bibliotheken durch skalierbare Alternativen …

Python Django OpenAI API

2 Wochen Zum verkaufbaren MVP

Vibe-coded Prototyp auf enterprise-pilotbereit gebracht. Keine Abkürzungen.

Python Flask LLMs

Komplett Plattformübergabe

Smart-City-IoT für Innsbruck: LoRaWAN-Infrastruktur erweitert und skaliert, Multi-Vendor-Geräte evaluiert und integriert, die …

Kubernetes LoRaWAN Docker

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.

Fragen vor dem Start

Mit welchen Cloud-Providern arbeitet ihr?

Provider, Architektur und nötige Expertise klären wir vor dem Angebot. Häufige Ziele sind AWS, Google Cloud, Azure und Hetzner oder selbst betriebenes Docker und Kubernetes. Der schriftliche Umfang nennt die abgedeckten Umgebungen.

Verursacht die Migration Ausfallzeit?

Der Plan hält sie so kurz, wie es die Daten zulassen. Jedes Fenster wird vorab vereinbart und an einer Kopie geprobt. Null Ausfallzeit versprechen wir nicht für jedes System.

Könnt ihr uns aus der Cloud herausholen?

Ja. Eigene Server können sich aus Kosten- oder Kontrollgründen lohnen. Der Plan wägt das gegen den Betriebsaufwand ab, den dein Team übernimmt, etwa Patches, Backups und Hardware.

Senkt die Migration unsere Rechnung?

Nicht automatisch. Wir schätzen die neuen Kosten aus dem Inventar und richten Budgets und Berichte ein, damit du die echte Rechnung siehst, sobald Traffic läuft. Einsparungen sind ein Ziel, das geprüft wird, kein Versprechen.

Wer betreibt die Umgebung nach der Migration?

Das wird vor der Umstellung vereinbart. Dein Team, dein bestehender Provider oder Wavect in einem vereinbarten Umfang. Die Härtung der neuen Umgebung ist ein Auftrag für Cloud Security.

Cloud-Migration abgrenzen

Beschreibe, wo deine Workloads heute laufen, wohin sie sollen und warum. Zugangsdaten und vertrauliche Systemdetails gehören nicht in die erste Anfrage.