--- title: "Cloud-Migration" canonical: https://wavect.io/de/services/cloud-migration/ language: de description: "Workloads in die Cloud, zwischen Providern oder zurück ins Self-Hosting umziehen: mit Inventar, Infrastructure as Code und geprobter Umstellung samt Rückweg." image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- 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. DER AUFTRAG ## Wissen, was läuft. Als Code neu aufbauen. Den Wechsel proben. 1. **Inventar** Workloads, Daten, Abhängigkeiten und ihre Verantwortlichen. 2. **Ziel als Code bauen** Eine geprüfte, reproduzierbare Umgebung, die sich übergeben lässt. 3. **Proben und umstellen** Migrationswellen mit Prüfungen und einer Rollback-Verantwortung. 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](/de/services/cloud-security/) besser. Kontrollen in Build- und Release-Pipeline gehören zu [DevSecOps](/de/services/devsecops/). Muss die Anwendung selbst ihre Architektur ändern, plane das als [Legacy-Modernisierung](/de/services/legacy-modernization/). 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. 1. **Assessment und Plan** - Du erhältst das Inventar, Zieloptionen mit Abwägungen, einen Wellenplan und eine Kostenschätzung samt Annahmen. 2. **Aufbau und Migration** - Du erhältst den Infrastruktur-Code, migrierte Workloads und ein Prüfprotokoll je Umstellung. 3. **Ü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](/de/services/software-takeover/#operational-independence) bei der [Software-Übernahme](/de/services/software-takeover/) an. Deren bestehende Voraussetzungen und Bedingungen gelten. Die laufende Pflege der Anwendung nach dem Umzug ist [Software-Wartung](/de/services/software-maintenance/). // 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. ### [Hyperstate AI](/de/case-studies/hyperstate-ai/) - **Status:** Eingestellt - **Ergebnis:** GPU-Monolith - → Microservices - **Zusammenfassung:** GPU-lastigen Monolithen in orchestrierte Services zerlegt und selbst gehostete ML-Bibliotheken durch skalierbare Alternativen … - **Stack:** Python, Django, OpenAI API ### [Twinsoft AI](/de/case-studies/twinsoft-ai/) - **Status:** Live - **Ergebnis:** 2 Wochen - Zum verkaufbaren MVP - **Zusammenfassung:** Vibe-coded Prototyp auf enterprise-pilotbereit gebracht. Keine Abkürzungen. - **Stack:** Python, Flask, LLMs ### [IKB](/de/case-studies/ikb/) - **Status:** Live - **Ergebnis:** Komplett - Plattformübergabe - **Zusammenfassung:** Smart-City-IoT für Innsbruck: LoRaWAN-Infrastruktur erweitert und skaliert, Multi-Vendor-Geräte evaluiert und integriert, die … - **Stack:** 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](/de/services/cloud-security/). ## Der passende nächste Schritt - [Die Umgebung härten, die du behältst](/de/services/cloud-security/) - [Build- und Release-Weg absichern](/de/services/devsecops/) - [Die Anwendungsarchitektur verändern](/de/services/legacy-modernization/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" } ] } ``` ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/de/services/cloud-migration/#service", "@type": "Service", "areaServed": [ { "@type": "Country", "name": "Austria" }, { "@type": "Place", "name": "Worldwide" } ], "category": "Sicherheit & Betrieb", "dateModified": "2026-10-30", "description": "Workloads in die Cloud, zwischen Providern oder zurück ins Self-Hosting umziehen: mit Inventar, Infrastructure as Code und geprobter Umstellung samt Rückweg.", "name": "Cloud-Migration", "provider": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "serviceType": "Cloud-Migration", "url": "https://wavect.io/de/services/cloud-migration/" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/services/overview/", "name": "Leistungen", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/services/overview/#security", "name": "Sicherheit & Betrieb", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/services/cloud-migration/", "name": "Cloud-Migration", "position": 4 } ] }, { "@id": "https://wavect.io/de/services/cloud-migration/#webpage", "@type": "WebPage", "dateModified": "2026-10-30", "description": "Workloads in die Cloud, zwischen Providern oder zurück ins Self-Hosting umziehen: mit Inventar, Infrastructure as Code und geprobter Umstellung samt Rückweg.", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "mainEntity": { "@id": "https://wavect.io/de/services/cloud-migration/#service" }, "name": "Cloud-Migration", "url": "https://wavect.io/de/services/cloud-migration/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Mit welchen Cloud-Providern arbeitet ihr?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Verursacht die Migration Ausfallzeit?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Könnt ihr uns aus der Cloud herausholen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Senkt die Migration unsere Rechnung?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Wer betreibt die Umgebung nach der Migration?" } ], "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".faq-question", ".faq-answer" ] } } ```