Rehosting und Neubau

Lift-and-Shift oder Neubau: die Entscheidung je Anwendung

Die Entscheidung fällt je Anwendung. Für den größten Teil eines Bestands ist Rehosting richtig, teuer wird es dort, wo eine Anwendung mit schlechtem Lastprofil unverändert in die Cloud gehoben wird.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Zwei IT-Entscheider vergleichen Plattformoptionen an einem großen Bildschirm

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Warum die pauschale Antwort immer falsch ist

In den meisten Häusern stehen sich zwei Lager gegenüber. Das eine will alles zuerst umziehen und danach modernisieren, weil das Rechenzentrum ein Enddatum hat. Das andere will nur noch Cloud-Native bauen und hält Lift-and-Shift für vertane Zeit. Beide Positionen scheitern absehbar. Der erste Weg produziert eine Cloud voller überdimensionierter Maschinen, die niemand mehr anfasst. Der zweite Weg kommt nie über die ersten drei Anwendungen hinaus, während der Vertrag für das Rechenzentrum weiterläuft.

Der Grund liegt in der veränderten Kostenstruktur. Im eigenen Rechenzentrum ist die Hardware bezahlt, eine Maschine mit acht Prozent Auslastung kostet praktisch nichts zusätzlich. In der Cloud kostet dieselbe Maschine rund um die Uhr denselben Betrag wie eine gut ausgelastete, dazu kommen Speicherzugriffe, ausgehender Datenverkehr und Sicherungsstände. Wer eine für die Jahresspitzenlast dimensionierte Umgebung eins zu eins hebt, zahlt für Reserve, die im alten Modell verschenkt war und im neuen abgerechnet wird.

Der dritte Denkfehler betrifft den Neubau. Refactoring wird gern als ein Projekt geplant, an dessen Ende die neue Anwendung steht. In der Realität muss die alte Anwendung weiterlaufen, während die neue entsteht, und beide brauchen dieselben Daten. Deshalb funktioniert der Neubau in Scheiben, bei dem einzelne Funktionen nacheinander herausgelöst und umgeleitet werden. Wer das nicht so plant, bindet über Monate das gesamte Entwicklungsteam und liefert in dieser Zeit nichts Neues für den Fachbereich.

Miniatur-Szene: zwei Plattformen nebeneinander mit unterschiedlichen Cloud-Bausteinen, dazwischen eine Waage

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Von der Inventur zur Entscheidung je Anwendung

01 Anwendungsbestand und technische Abhängigkeiten vollständig erfassen
02 Lastprofil, Lizenzen und Datenmenge je Anwendung messen
03 Fachliche Lebenserwartung mit dem Fachbereich klären
04 Weg je Anwendung festlegen und die Entscheidung begründen
05 Wellen planen: erst risikoarm, dann geschäftskritisch
06 Nach dem Umzug Größen anpassen und Kosten gegenprüfen

Was du mitnimmst

Die sechs Wege und wann sie tragen

Das Modell stammt ursprünglich von Gartner und wurde von AWS als 6R bekannt gemacht, teils erweitert um Relocate für den Umzug ganzer Virtualisierungsumgebungen. Entscheidend ist, dass du es je Anwendung anwendest und nicht auf den Gesamtbestand.

Rehost, der Umzug ohne Umbau

Das Betriebssystem samt Anwendung wandert unverändert auf eine virtuelle Maschine in der Cloud, meist blockweise repliziert und mit kurzer Umschaltung. Das ist der schnellste und risikoärmste Weg und für den größten Teil eines typischen Bestands richtig. Bedingung ist, dass du direkt nach dem Umzug die Maschinengrößen anpasst, sonst wird der Vorteil sofort wieder aufgezehrt.

Replatform, der Umzug mit einem Eingriff

Die Anwendung bleibt, aber ein Baustein darunter wird ersetzt, typischerweise die selbst betriebene Datenbank durch einen verwalteten Dienst oder der Anwendungsserver durch einen Container. Der Aufwand liegt bei Tagen bis wenigen Wochen, der Betriebsgewinn ist erheblich, weil Sicherung, Aktualisierung und Hochverfügbarkeit an den Anbieter übergehen.

Refactor, der echte Umbau

Die Anwendung wird neu geschnitten, um Elastizität, verwaltete Dienste und schnellere Auslieferung wirklich zu nutzen. Das ist der teuerste Weg und lohnt sich nur bei Anwendungen mit hoher fachlicher Änderungsrate, starken Lastschwankungen oder harter Skalierungsanforderung. Für eine Anwendung, die seit Jahren unverändert läuft, ist er wirtschaftlich nicht zu begründen.

Repurchase, der Wechsel auf ein Produkt

Statt die eigene Lösung umzubauen, wird sie durch ein fertiges Angebot ersetzt, klassisch bei Personalwesen, Ticketsystemen, Dokumentenablage oder Zeiterfassung. Der Aufwand verlagert sich damit von der Entwicklung auf Datenübernahme, Prozessanpassung und Schulung der Anwender. Genau diese drei Posten werden in der Kalkulation regelmäßig zu niedrig angesetzt, weil sie nicht in der IT anfallen, sondern im Fachbereich.

Retain, das bewusste Bleiben

Manche Anwendungen bleiben, wo sie sind: weil eine Zertifizierung an einer bestimmten Umgebung hängt, weil die Latenz zu einer Maschine in der Fertigung nicht erlaubt ist, weil ein Vertrag noch drei Jahre läuft oder weil die Ablösung ohnehin beschlossen ist. Retain ist eine gültige Entscheidung, sie muss nur begründet und mit einem Wiedervorlagedatum versehen sein.

Retire, das Abschalten

In fast jedem Bestand lassen sich zwischen zehn und zwanzig Prozent der Systeme ersatzlos abschalten, weil sie durch andere ersetzt wurden, nur noch Berichte für niemanden erzeugen oder seit Jahren keine Anmeldung mehr gesehen haben. Diese Systeme zuerst zu identifizieren, ist der günstigste Teil jeder Migration und verkleinert alle folgenden Schritte.

Tutorial

Von der Inventur bis zur ersten umgeleiteten Funktion

Für den größten Teil eines typischen Bestands ist Rehosting richtig, weil es schnell geht und das Risiko klein hält, teuer wird es nur dort, wo eine Anwendung mit schlechtem Lastprofil unverändert in die Cloud gehoben wird. Weil die Entscheidung je Anwendung fällt, wird hier zuerst der Bestand gemessen, dann werden beide Wege gegengerechnet und der Weg je Anwendung schriftlich festgelegt. Danach folgen sauberes Rehosting mit Testlauf und Rückfallebene sowie Replatform und Neubau in Scheiben.

Schritt 1: Bestand und Abhängigkeiten wirklich messen

Die Entscheidung hängt an Daten, die in keiner Anlagenverwaltung stehen. Sie entstehen erst, wenn du auf den Maschinen nachsiehst.

Was läuft und mit wem spricht es

# Welche Dienste laufen überhaupt noch
systemctl list-units --type=service --state=running --no-pager

# Bestehende Verbindungen samt Gegenstelle und Prozess
ss -tunp state established

# Auslastung über längere Zeit, nicht als Momentaufnahme
sar -u -f /var/log/sysstat/sa15 | tail -20
sar -r -f /var/log/sysstat/sa15 | tail -20

# Wann hat sich zuletzt jemand angemeldet
last -n 20
LANG=C lastlog | grep -v 'Never logged in'   # neuere Distributionen: lastlog2

Die letzte Abfrage ist die wertvollste. Systeme, an denen sich seit Monaten niemand angemeldet hat und die keine Verbindungen halten, sind die ersten Kandidaten für Retire. Jede so abgeschaltete Maschine spart Migrationsaufwand und laufende Kosten.

Dasselbe unter Windows

Get-Service | Where-Object Status -eq 'Running' |
  Select-Object Name, DisplayName | Sort-Object Name

Get-NetTCPConnection -State Established |
  Select-Object LocalPort, RemoteAddress, RemotePort, OwningProcess |
  Sort-Object RemoteAddress

# Installierte Serverrollen als Hinweis auf Abhängigkeiten
Get-WindowsFeature | Where-Object Installed -eq $true |
  Select-Object Name, DisplayName

# Lizenzrelevant: Edition und Kerne
Get-CimInstance Win32_OperatingSystem | Select-Object Caption, OSArchitecture
Get-CimInstance Win32_Processor | Select-Object NumberOfCores

Edition und Kernanzahl gehören in die Inventur, weil sie über die Lizenzkosten in der Cloud entscheiden. Bei SQL Server und Windows Server macht die Frage, ob Software Assurance vorliegt, in der Rechnung den größten einzelnen Unterschied.

Für größere Bestände nehmen dir die Anbieterwerkzeuge die Fleißarbeit ab. Auf AWS-Seite übernimmt das für neue Projekte AWS Transform, weil Application Discovery Service seit November 2025 keine neuen Kunden mehr aufnimmt, Azure Migrate stellt dafür eine Erfassungsanwendung in die eigene Umgebung. Beide liefern eine Abhängigkeitskarte, und genau die brauchst du, um Wellen zu schneiden. Der Gesamtablauf einer Migration mit Wellen, Testfenstern und Rückfallebene steht auf der Seite zum Planen einer Cloud-Migration.

Schritt 2: Beide Wege gegenrechnen, bevor du entscheidest

Die Entscheidung ist am Ende wirtschaftlich. Dafür brauchst du drei Zahlen: laufende Kosten nach Rehosting, Umbaukosten und laufende Kosten nach Umbau.

Kosten und Fehldimensionierung sichtbar machen

# Zeitraum: der letzte volle Monat
VON=$(date -d "$(date +%Y-%m-01) -1 month" +%F)
BIS=$(date +%Y-%m-01)

# AWS: Kosten je Dienst für den letzten vollen Monat
aws ce get-cost-and-usage \
  --time-period Start=$VON,End=$BIS \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# AWS: konkrete Vorschläge zur Größenanpassung
aws compute-optimizer get-ec2-instance-recommendations \
  --region eu-central-1 \
  --query 'instanceRecommendations[?finding==`OVER_PROVISIONED`].[instanceName,currentInstanceType,findingReasonCodes]' \
  --output table

# Azure: dasselbe über den Advisor
az advisor recommendation list --category Cost -o table

Diese Auswertung gehört nicht ans Ende der Migration, sondern in die Entscheidungsphase. Wenn du die Zielgrößen schon kennst, rechnest du mit realistischen Beträgen statt mit einer Eins-zu-eins-Übernahme der alten Dimensionierung.

Lizenzvorteil nicht verschenken

# Azure Hybrid Benefit für Windows Server mit Software Assurance
az vm create \
  --resource-group rg-prod \
  --name app01 \
  --image Win2022Datacenter \
  --size Standard_D4s_v5 \
  --license-type Windows_Server

# Bestehende Maschinen nachträglich umstellen
az vm update --resource-group rg-prod --name app01 \
  --set licenseType=Windows_Server

Ein vergessenes --license-type ist einer der teuersten stillen Fehler nach einer Migration, weil die Lizenz dann ein zweites Mal über den Stundenpreis bezahlt wird. Prüf nach jeder Welle, ob alle berechtigten Maschinen umgestellt sind.

Schritt 3: Den Weg je Anwendung festlegen und begründen

Die Zuordnung gehört schriftlich festgehalten, mit Begründung und Wiedervorlagedatum. Sonst wird sie im nächsten Projekt neu diskutiert.

Sechs Wege, sechs Auslöser

Weg	Was passiert	Wann er richtig ist	Typischer Fallstrick
Rehost	Maschine wird unverändert repliziert und umgeschaltet	Stabile Anwendung, Enddatum für das Rechenzentrum, wenig Änderungsbedarf	Alte Dimensionierung wird mit übernommen und nie korrigiert
Replatform	Ein Baustein wird ersetzt, meist die Datenbank oder der Anwendungsserver	Selbst betriebene Datenbank, hoher Pflegeaufwand, stabile Anwendung darüber	Zeichensatz, Sortierreihenfolge und Verfahren verhalten sich im verwalteten Dienst anders
Refactor	Anwendung wird neu geschnitten und auf verwaltete Dienste gesetzt	Hohe fachliche Änderungsrate, starke Lastschwankungen, echter Skalierungsbedarf	Wird als ein großes Projekt geplant statt in Scheiben
Repurchase	Eigene Lösung wird durch ein fertiges Produkt ersetzt	Standardfunktion ohne Wettbewerbsvorteil, etwa Ticket, Personal, Zeiterfassung	Datenübernahme und Prozessanpassung werden unterschätzt
Retain	Anwendung bleibt bewusst im eigenen Rechenzentrum	Zertifizierung, Latenz zur Fertigung, laufender Vertrag, geplante Ablösung	Ohne Wiedervorlagedatum wird aus bewusstem Bleiben stilles Vergessen
Retire	Anwendung wird ersatzlos abgeschaltet	Keine Anmeldung seit Monaten, Funktion anderweitig abgedeckt	Niemand traut sich, weil die Zuständigkeit unklar ist

Fünf Fragen, die die Zuordnung entscheiden

Wie oft wurde diese Anwendung in den letzten zwei Jahren fachlich geändert?Ohne Änderungsrate gibt es keinen Nutzen aus schnellerer Auslieferung, und damit fällt das stärkste Argument für einen Neubau weg.
Wie stark schwankt die Last über Tag, Woche und Jahr?Elastizität ist der wirtschaftliche Hebel der Cloud. Bei gleichmäßiger Grundlast trägt ein Umbau seine Kosten nicht.
Welche Lizenzen hängen dran und gilt Software Assurance?Datenbank- und Betriebssystemlizenzen können die laufenden Kosten verdoppeln oder halbieren. Diese Zahl verschiebt die Entscheidung häufiger als jede technische Überlegung.
Wie viele Daten liegen an und wer greift von wo darauf zu?Große Datenmengen mit vielen externen Zugriffen erzeugen laufende Kosten für ausgehenden Verkehr, die im Angebot selten auftauchen.
Wie lange soll die Anwendung fachlich noch leben?Steht die Ablösung in achtzehn Monaten fest, ist jeder Umbau verlorenes Geld, und selbst ein Umzug muss begründet werden.
Wer ist fachlich zuständig und kann Ausfallzeiten freigeben?Ohne benannte Ansprechperson gibt es kein Testfenster und keine Abnahme. Genau daran scheitern Wellen häufiger als an der Technik.

Schritt 4: Rehosting sauber durchziehen

Der Umzug selbst ist bei beiden großen Anbietern ein blockweise replizierender Dienst mit Testlauf und kurzer Umschaltung. Der Testlauf ist der wichtige Teil.

AWS Application Migration Service

# Replizierende Quellsysteme anzeigen
aws mgn describe-source-servers --region eu-central-1 \
  --query 'items[].[sourceServerID,sourceProperties.identificationHints.hostname,dataReplicationInfo.dataReplicationState]' \
  --output table

# Testinstanz starten, ohne die Quelle anzufassen
aws mgn start-test --source-server-ids s-1234567890abcdef0

# Erst nach erfolgreichem Test und Abnahme umschalten
aws mgn start-cutover --source-server-ids s-1234567890abcdef0

# Nach Freigabe die Replikation beenden
aws mgn finalize-cutover --source-server-id s-1234567890abcdef0

Zwischen Test und Umschaltung läuft die Replikation weiter, die Quelle bleibt unangetastet. Genau deshalb ist der Testlauf kostenlos im Risiko und teuer nur in der Rechenzeit. Führ ihn für jede Maschine durch, nicht stichprobenartig.

Azure Migrate mit PowerShell

# Erfasste Server aus dem Projekt holen
Get-AzMigrateDiscoveredServer -ResourceGroupName rg-migrate `
  -ProjectName migrate-prod | Select-Object DisplayName, Name

$server = Get-AzMigrateDiscoveredServer -ResourceGroupName rg-migrate `
  -ProjectName migrate-prod -DisplayName app01

# Replikation einrichten
New-AzMigrateServerReplication -MachineId $server.Id `
  -LicenseType WindowsServer `
  -TargetResourceGroupId $zielRg `
  -TargetNetworkId $zielVnet `
  -TargetSubnetName snet-app `
  -TargetVMName app01 `
  -DiskType Standard_LRS `
  -OSDiskID $server.Disk[0].Uuid

# Testmigration, danach wieder aufräumen
$ziel = Get-AzMigrateServerReplication -DiscoveredMachineId $server.Id
Start-AzMigrateTestMigration -InputObject $ziel -TestNetworkID $testVnet
Stop-AzMigrateTestMigration  -InputObject $ziel

-LicenseType WindowsServer aktiviert den Lizenzvorteil direkt beim Umzug. Wer das erst später nachzieht, zahlt in der Zwischenzeit doppelt, und die Zwischenzeit dauert erfahrungsgemäß Monate.

Schritt 5: Replatform als Mittelweg, Neubau in Scheiben

Zwischen Umzug und Neubau liegt der Weg, der in der Praxis am häufigsten das beste Verhältnis liefert: ein Baustein wird ersetzt, der Rest bleibt.

Datenbank in einen verwalteten Dienst überführen

az postgres flexible-server create \
  --resource-group rg-daten-prod \
  --name pg-shop-prod \
  --location germanywestcentral \
  --tier GeneralPurpose \
  --sku-name Standard_D4ds_v5 \
  --version 16 \
  --storage-size 256 \
  --high-availability ZoneRedundant \
  --public-access None

# Erstübernahme, danach laufender Abgleich bis zur Umschaltung
pg_dump --format=custom --no-owner --dbname="$QUELLE" --file=shop.dump
pg_restore --no-owner --dbname="$ZIEL" shop.dump

Für den laufenden Abgleich bis zur Umschaltung nutzt du logische Replikation oder den Migrationsdienst von Azure Database for PostgreSQL. Der Schnitt liegt dort, wo die Anwendung kurz angehalten wird, damit der letzte Stand vollständig übernommen ist.

Neubau in Scheiben: eine Funktion umleiten

# Neue Zielgruppe für den herausgelösten Dienst
aws elbv2 create-target-group \
  --name tg-bestellungen-neu \
  --protocol HTTP --port 8080 --vpc-id vpc-0a1b2c3d \
  --health-check-path /gesund

# Nur einen Pfad auf den Neubau leiten, alles andere bleibt
aws elbv2 create-rule \
  --listener-arn "$LISTENER" \
  --priority 10 \
  --conditions Field=path-pattern,Values='/api/bestellungen/*' \
  --actions Type=forward,TargetGroupArn="$NEU"

# Zurücknehmen ist ein einziger Befehl
aws elbv2 delete-rule --rule-arn "$REGEL"

Das ist das Strangler-Fig-Muster: Ein Pfad nach dem anderen wandert auf die neue Anwendung, der Monolith bleibt so lange stehen, bis der letzte Pfad umgeleitet ist. Der Rückweg besteht jeweils aus dem Löschen einer Regel, und das ist der Grund für die geringe Risikohöhe.

Der entscheidende Punkt beim Neubau ist der Schnitt, nicht die Technik. Welche Funktion sich sauber herauslösen lässt und welche zu tief in gemeinsamen Datenbeständen hängt, klärst du am besten vor dem ersten Umbau, sonst entstehen zwei Anwendungen, die sich dieselben Tabellen teilen. Die Kriterien dafür stehen unter Monolith oder Microservices, die Frage nach der Laufzeitumgebung für die neuen Teile behandelt Serverless oder Container.

Passende Kurse

Kurse zu Cloud-Migration und Modernisierung bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Du buchst sie in Präsenz oder Live-Online, auf Wunsch kommen sie auch als Inhouse-Schulung zu deinem Team.

Migrating to AWS 3 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs Architecting on AWS 3 Tage Präsenz nächster Termin 27.01.2027 Zum Kurs Advanced Architecting on AWS 3 Tage Präsenz nächster Termin 09.12.2026 Zum Kurs Vom Monolith zum Cloud Native System 2 Tage Präsenz nächster Termin 10.12.2026 Zum Kurs Legacy Java EE zu Cloud Native Spring Boot 2 Tage Präsenz nächster Termin 07.01.2027 Zum Kurs

Weitere Kurse aus diesem Bereich

Unverbindlich beraten lassen Alle AWS-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest AWS Cloud Practitioner Quiz Bereite dich auf die AWS CLF-C02 Prüfung vor. Teste dein Wissen zu EC2, S3, IAM, VPC und Cloud-Konzepten. Quiz starten

Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.

Rückmeldung aus dem Kurs „Ansible Kompaktkurs“

Gut zu wissen

Häufige Fragen zu Cloud-Migration und Modernisierung

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

Frag uns direkt

Ist Lift-and-Shift verlorene Zeit?

Nein, solange danach etwas passiert. Rehosting löst genau ein Problem, nämlich den Standort, und das schnell und mit geringem Risiko. Wenn ein Vertrag für das Rechenzentrum ausläuft oder Hardware am Ende ihrer Lebensdauer steht, ist das der richtige Weg für den größten Teil des Bestands. Verlorene Zeit wird daraus erst, wenn die Anwendungen anschließend unverändert in der alten Dimensionierung weiterlaufen. Plan deshalb die Größenanpassung und den Umbau der Test- und Abnahmeumgebungen als festen Bestandteil ein, nicht als späteren Wunsch.

Ab wann rechnet sich ein Neubau gegenüber dem Rehosting?

Der Umbau muss seine Kosten aus einem von zwei Töpfen zurückholen: aus gesparten Betriebskosten oder aus schnellerer fachlicher Lieferung. Der erste Topf füllt sich nur bei stark schwankender Last, weil dann Elastizität wirklich Geld spart. Der zweite Topf füllt sich nur, wenn an der Anwendung regelmäßig fachlich gearbeitet wird. Trifft keines von beidem zu, ist Rehosting oder Replatform die wirtschaftlich richtige Antwort, auch wenn die Architektur unschön bleibt. Als Faustregel gilt: unter zwei größeren fachlichen Änderungen im Jahr trägt kein Neubau.

Was ist Replatform genau und wann lohnt es sich?

Replatform bedeutet, dass die Anwendung selbst unverändert bleibt, aber ein Baustein darunter durch einen verwalteten Dienst ersetzt wird. Der häufigste Fall ist die selbst betriebene Datenbank, die zu einem verwalteten Datenbankdienst wandert. Damit gehen Sicherung, Aktualisierung, Fehlerbehebung und Hochverfügbarkeit an den Anbieter über, und das ist meist der größte einzelne Betriebsgewinn einer Migration. Der Aufwand liegt bei Tagen bis wenigen Wochen. Achte auf Zeichensatz, Sortierreihenfolge, gespeicherte Prozeduren und Erweiterungen, denn dort verhalten sich verwaltete Dienste anders als die eigene Installation.

Wie erkenne ich Anwendungen, die abgeschaltet werden können?

Drei Signale reichen für eine erste Liste: Seit Monaten hat sich niemand angemeldet, es bestehen keine dauerhaften Netzverbindungen zu anderen Systemen, und im Ticketsystem gibt es keine Vorgänge mehr dazu. In fast jedem Bestand fallen so zehn bis zwanzig Prozent der Systeme auf. Für die Abschaltung brauchst du dann eine benannte fachliche Zuständigkeit und ein definiertes Vorgehen: erst vom Netz trennen, vier Wochen beobachten, sichern, dann löschen. Jedes so entfernte System spart Migrationsaufwand, Lizenzen und laufende Kosten gleichzeitig.

Welche Rolle spielen Lizenzen bei dieser Entscheidung?

Eine größere, als die meisten Projekte einplanen. Bei Windows Server und SQL Server entscheidet die Frage, ob Software Assurance vorliegt, über einen erheblichen Teil der laufenden Kosten, weil vorhandene Lizenzen sonst über den Stundenpreis ein zweites Mal bezahlt werden. Bei Datenbanken kommt hinzu, dass die Lizenzbedingungen bei Nutzung fremder Cloud-Anbieter von den eigenen abweichen können. Klär die Lizenzlage deshalb vor der Zuordnung je Anwendung, nicht danach. In vielen Fällen kippt sie die Entscheidung von Rehost auf Replatform, weil ein quelloffener verwalteter Dienst schlicht günstiger ist.

Quellen

Zuletzt geprüft am 05. Oktober 2026.

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.