PaaS-Exit-Checkliste: Anwendungen kontrolliert migrieren
Timo Wevelsiep•Aktualisiert: 30.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
Sie möchten eine Anwendung aus Vercel, Heroku, Railway, Render, Fly.io oder einer anderen PaaS lösen? WZ-IT plant und realisiert den PaaS- und Cloud Exit ab 1.990 Euro netto. Für noch unklare Abhängigkeiten und Zieloptionen gibt es den PaaS Exit Review ab 1.490 Euro netto.
Eine PaaS-Exit-Checkliste verhindert, dass eine Cloud-Migration auf Repository und Container reduziert wird. Verwaltete Plattformen übernehmen viele Aufgaben unsichtbar: Builds, Zertifikate, Umgebungsvariablen, Neustarts, interne DNS-Namen, persistente Daten, Logs und Skalierung. Im Ziel müssen diese Funktionen bewusst erhalten, ersetzt oder ausgeschlossen werden.
Die Checkliste gilt für Vercel, Railway, Render, Fly.io, Heroku, Netlify und vergleichbare Plattformen. Quellspezifische Exportwege unterscheiden sich, die Review-Gates bleiben jedoch weitgehend gleich.
Inhalt
- 1. Ziel und Anlass festhalten
- 2. Anwendungen und Plattformressourcen erfassen
- 3. Zielarchitektur und Verantwortung festlegen
- 4. Build und Runtime portabel machen
- 5. Daten und Persistenz getrennt planen
- 6. Secrets, Netzwerk und Integrationen
- 7. Delivery und Umgebungen neu aufbauen
- 8. Betrieb vor dem Cutover abnehmen
- 9. Cutover und Rückfall
- 10. Quelle kontrolliert abschalten
1. Ziel und Anlass festhalten
Ein PaaS Exit sollte ein messbares Ziel haben. Typische Gründe sind:
- Kosten und Skalierungsverhalten besser planbar machen
- Infrastruktur und Datenwege kontrollieren
- einen Plattform-Lock-in reduzieren
- Entwicklungs- und Produktivumgebungen klarer trennen
- Betrieb an einen verantwortlichen Dienstleister übergeben
- eigene oder europäische Infrastruktur verwenden
- mehrere verstreute Plattformen konsolidieren
- Anwendung, Backend und Delivery gemeinsam professionalisieren
Aus dem Anlass folgen Prioritäten. Ein reiner Kostenwechsel kann eine einfache Zielplattform rechtfertigen. Ein regulatorisch oder betrieblich motivierter Exit benötigt häufig zusätzliche Trennung, Dokumentation und Recovery-Nachweise.
2. Anwendungen und Plattformressourcen erfassen
Anwendung
- Repository und Eigentümer
- Framework, Sprache und Runtime-Version
- Paketmanager, Lockfiles und private Registries
- Build- und Startkommando
- Container, Buildpacks oder plattformspezifischer Build
- Health Checks und Restart-Verhalten
- horizontaler Zustand und Session-Verhalten
Plattform
- Services, Worker und Prozessgruppen
- Cronjobs, Queues und Event-Handler
- Domains, Redirects und TLS
- Environment Variables und Secrets
- interne Service-Namen und private Netze
- Volumes, Datenbanken und Object Storage
- Regionen, Replikate und Skalierungsregeln
- Logs, Metriken, Traces und Alarmierung
Organisation
- technische und fachliche Verantwortliche
- Zugänge zu Provider, DNS, Repository und Drittanbietern
- Wartungsfenster und Geschäftszeiten
- Recovery-Ziele und akzeptierte Ausfallzeit
- bestehende Verträge, Lizenzen und Kündigungsfristen
Das Ergebnis ist keine lose Liste, sondern eine Abhängigkeitskarte. Jeder produktive Nutzerweg muss zu Runtime, Daten und externen Diensten zurückverfolgt werden können.
3. Zielarchitektur und Verantwortung festlegen
Die Zielplattform wird nach Bedarf gewählt, nicht nach dem Wunsch, das Quellsystem exakt nachzubauen.
| Zielmodell | Typischer Einsatz | Zu klären |
|---|---|---|
| Docker Compose | wenige stabile Services auf einem System | Wiederanlauf, Updates, Secrets, Backup |
| Coolify | Git-basierte Apps mit Plattformoberfläche | Hosts, Plattformbetrieb, Persistenz, Monitoring |
| Kubernetes | mehrere Nodes, Teams und Plattformstandards | Clusterbetrieb, Netzwerk, Storage, Policies |
| Managed Infrastruktur | Betrieb soll ausgelagert werden | Scope, Service Level, Zugriff und Verantwortungsgrenze |
| Hybrid | einzelne Cloud-Dienste bleiben vorerst bestehen | Datenwege, Kosten, Latenz und Übergangsplan |
Vor der Umsetzung werden RPO und RTO definiert:
- RPO: maximal akzeptierter Datenverlust
- RTO: maximal akzeptierte Wiederherstellungszeit
Diese Ziele bestimmen Backup, Replikation, Redundanz und Cutover-Verfahren. Sie lassen sich nicht erst nach dem Aufbau ergänzen, ohne die Architektur möglicherweise zu verändern.
4. Build und Runtime portabel machen
- Build läuft aus einem versionierten Commit reproduzierbar
- Lockfiles und benötigte Build-Tools sind vorhanden
- private Dependencies und Registry-Zugänge sind dokumentiert
- Runtime-Version und Systembibliotheken sind festgelegt
- Startkommando und Ports sind explizit
- Health Check prüft echte Betriebsfähigkeit
- Anwendung schreibt keine wichtigen Daten in ein flüchtiges Dateisystem
- Konfiguration und Secrets liegen nicht im Image
- Graceful Shutdown und Neustart sind getestet
- Ressourcenbedarf unter realistischer Last ist gemessen
Ein OCI-kompatibles Container-Image ist ein verbreiteter Portabilitätsbaustein, aber kein vollständiges Betriebsmodell. Daten, Netz, Secrets, Deployment und Wiederherstellung bleiben separate Ebenen.
5. Daten und Persistenz getrennt planen
Für jede Datenquelle wird ein eigener Migrationsweg dokumentiert:
| Datentyp | Möglicher Weg | Abnahme |
|---|---|---|
| relationale Datenbank | Dump/Restore oder Replikation | Zeilen, Constraints, Sequenzen, fachliche Tests |
| Volume-Dateien | konsistenter Export und Dateisync | Anzahl, Größe, Rechte, Prüfsummen |
| Object Storage | API- oder S3-kompatibler Transfer | Objekte, Metadaten, Sichtbarkeit, Prüfsummen |
| Cache | meist neu aufbauen | Warmup und korrektes Ablaufverhalten |
| Queue | abarbeiten, pausieren oder kontrolliert übertragen | keine verlorenen oder doppelten Jobs |
| Suchindex | neu erzeugen oder exportieren | Dokumentzahl und repräsentative Suchen |
Ein Backup vor der Migration ist notwendig, ersetzt aber nicht den Rückfallplan. Sobald die Zielumgebung neue Schreibvorgänge annimmt, muss geklärt sein, wie diese Daten bei einem Rückfall behandelt werden.
6. Secrets, Netzwerk und Integrationen
- Secrets sind vollständig inventarisiert, aber nicht in Projektdokumente kopiert
- Ziel-Secrets werden sicher eingespielt und bei Bedarf rotiert
- interne Hostnamen werden auf das Zielmodell angepasst
- Firewall und ausgehende Verbindungen sind definiert
- Webhooks, OAuth-Redirects und Callback-URLs werden aktualisiert
- DNS-TTL wird rechtzeitig vor dem Cutover reduziert
- E-Mail-Versand und Absenderauthentifizierung sind getestet
- feste ausgehende IPs werden Partnern vorab gemeldet
- administrative Zugriffe verwenden einen kontrollierten privaten Weg
Umgebungsvariablen trennen Konfiguration vom Code, sind aber nicht automatisch ein sicheres Secret-System. Zugriffsrechte, Protokollierung, Rotation und Trennung zwischen Staging und Produktion bleiben notwendig.
7. Delivery und Umgebungen neu aufbauen
Der gewünschte Entwicklerablauf wird vor dem Cutover hergestellt:
- Push oder Merge löst den vorgesehenen Build aus
- Tests und Sicherheitsprüfungen laufen vor der Bereitstellung
- Staging besitzt eigene Variablen und Datenzugriffe
- Produktion benötigt die vereinbarte Freigabe
- Health Check entscheidet über erfolgreichen Rollout
- fehlerhafte Releases lassen sich technisch zurücksetzen
- Datenbankmigrationen sind versioniert und mit dem Release koordiniert
- Preview-Umgebungen erhalten keine unkontrollierten Produktionszugänge
Der Plattformwechsel soll die Weiterentwicklung nicht blockieren. Das Team arbeitet weiter im Repository; die Zielplattform übernimmt den definierten Build- und Deploymentpfad.
8. Betrieb vor dem Cutover abnehmen
- proaktives Monitoring ist aktiv
- relevante Logs sind zentral verfügbar und geschützt
- Fehler und Kapazitätsgrenzen lösen verwertbare Alarme aus
- Backupjobs laufen für alle persistenten Ebenen
- ein repräsentativer Restore wurde getestet oder verbindlich geplant
- Updates, Wartungsfenster und Neustarts sind geregelt
- Zertifikate und Domains werden erneuert
- Ansprechpartner und Eskalation sind dokumentiert
- Service Level und Ausschlüsse sind nachvollziehbar
- Betriebsdokumentation entspricht der tatsächlich gebauten Umgebung
Eine Anwendung ist nicht produktionsbereit, nur weil die Startseite antwortet. Hintergrundjobs, Datensicherung, Alarmierung und Wiederanlauf gehören zur Abnahme.
9. Cutover und Rückfall
Ein Cutover-Runbook enthält:
- frühesten Start und spätesten Entscheidungspunkt
- Verantwortliche für Anwendung, Daten, DNS und Freigabe
- Schreibgrenze oder Replikationsstatus
- finalen Datenabgleich
- Umschaltung von Domains, Variablen und Webhooks
- technische und fachliche Smoke Tests
- Beobachtungszeit und Abnahmekriterien
- eindeutige Go-/No-Go-Entscheidung
- Rückschaltung und Behandlung neuer Zieldaten
- Kommunikation an betroffene Teams
Der Rückfall wird nicht improvisiert. Er wird vor der Migration technisch geprüft und besitzt ein Zeitfenster, nach dessen Ende die Quelle nicht mehr als verlässliches Produktionsziel gilt.
10. Quelle kontrolliert abschalten
Nach erfolgreichem Cutover bleiben folgende Aufgaben:
- Rückfallfenster abwarten
- letzte Exporte und erforderliche Nachweise sichern
- alte Domains, Webhooks und Schlüssel entfernen
- Secrets rotieren, die auf beiden Plattformen verwendet wurden
- Daten gemäß vereinbarten Fristen löschen
- Pläne, Add-ons und Plattformressourcen kündigen
- Kostenkontrolle und Providerzugänge prüfen
- Dokumentation und Asset-Übersicht aktualisieren
Der Quellaccount wird nicht gelöscht, bevor Eigentum, Datenexport und Abrechnung geprüft sind.
Für konkrete Plattformen ergänzen Vercel zu Coolify oder Hetzner migrieren und Railway, Render oder Fly.io migrieren diese Checkliste um die jeweiligen Quellobjekte.
Quellen
Lieber betreiben lassen?
Sie möchten PaaS & Cloud Exit nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
PaaS-Migration einordnen
Beschreiben Sie Quelle, Anwendung und gewünschtes Ziel. Wir prüfen den Migrationsweg für Runtime, Daten, Delivery und anschließenden Betrieb.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Ein PaaS Exit ist die kontrollierte Verlagerung einer Anwendung aus einer verwalteten Plattform in ein anderes Betriebsmodell. Neben dem Code werden Runtime, Konfiguration, Daten, Storage, Jobs, Netzwerk, Delivery und Betriebsprozesse berücksichtigt.
Nicht zwingend. Das Ziel kann selbst betrieben, durch einen Dienstleister gemanagt oder hybrid aufgebaut werden. Entscheidend sind Kontrolle, Portabilität und eine klar vereinbarte Betriebsverantwortung.
Typische Quellen sind Vercel, Railway, Render, Fly.io, Heroku und Netlify. Ob und wie eine Anwendung migriert werden kann, hängt von den tatsächlich genutzten Laufzeiten, Datenprodukten und Plattformfunktionen ab.
Nein. Ein gestufter Exit kann Risiken reduzieren. Anwendung, Datenbank, Storage oder weitere Dienste können getrennt migriert werden, sofern Datenwege, Latenz, Sicherheit und Übergangsverantwortung klar sind.
Der Plan benennt Entscheidungspunkt, Verantwortliche, unveränderte Quelle, Umgang mit neuen Schreibvorgängen, DNS-Rückschaltung, Wiederherstellung und Kriterien für Abbruch oder Fortsetzung.
Die PaaS- und Cloud-Migration beginnt bei 1.990 Euro netto. Die Angabe ist ein Einstiegspreis, kein pauschaler Festumfang. Quellen, Services, Daten, Zielarchitektur, Ausfallzeit und Betriebsanforderungen bestimmen das Angebot.
