AWS Amplify, Cloudflare und DigitalOcean App Platform 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.
Ihre Plattform ist nicht Vercel, Railway, Render, Fly.io, Heroku oder Netlify? WZ-IT ordnet auch andere Quellen im PaaS Exit Review ab 1.490 Euro netto ein und setzt klar abgegrenzte PaaS-Migrationen ab 1.990 Euro netto um.
Ein PaaS Exit aus AWS Amplify, Cloudflare Pages oder Workers und DigitalOcean App Platform benötigt eine quellspezifische Betrachtung. Der gleiche Begriff "Anwendung" kann eine statische Website, einen Container-Service oder ein verteiltes System aus Edge-Code, Identität, APIs und Datenprodukten meinen.
AWS Amplify: Hosting oder gekoppelter AWS-Stack?
Bei Amplify wird zuerst zwischen Webhosting und Backend-Ressourcen unterschieden. Zu erfassen sind:
- Repository, Branches, Build Specification und Artefakte
- Umgebungsvariablen und Secrets
- Domains, Redirects und Rewrites
- serverseitige Framework-Funktionen
- Authentifizierung, beispielsweise über Cognito
- APIs, beispielsweise AppSync oder API Gateway
- Functions, Storage und weitere angebundene AWS-Dienste
- Preview- und Produktionsumgebungen
- Logs, Monitoring und Datenwege
Eine statische Amplify-Anwendung kann häufig auf einen reproduzierbaren Build und eine neue Webauslieferung reduziert werden. Nutzt sie Auth, APIs, Functions oder Storage, wird die Migration zu einer Entkopplung mehrerer AWS-Dienste. Dann ist ein gestufter Wechsel meist kontrollierbarer als ein gleichzeitiger Austausch aller Komponenten.
Cloudflare Pages: statische Auslieferung plus Plattformfunktionen
Bei Cloudflare Pages werden Build, statische Assets, Domains, Redirects und Pages Functions aufgenommen. Verwendete Bindings zu KV, D1, R2, Queues oder anderen Cloudflare-Produkten bestimmen, ob ein einfacher Hostingwechsel möglich ist.
Statische Inhalte lassen sich typischerweise exportieren und über einen Webserver oder Object Storage ausliefern. Pages Functions müssen dagegen als API-Routen, Anwendungslogik oder getrennte Dienste portiert werden. Cache- und Edge-Verhalten wird im Ziel bewusst neu bewertet.
Cloudflare Workers: häufig ein Replatforming
Cloudflare Workers laufen nicht wie ein gewöhnlicher dauerhaft gestarteter Container. Die Runtime, Request-APIs, Bindings, Standortverteilung und Zeitgrenzen unterscheiden sich von klassischen Serverprozessen. Deshalb beginnt die Planung bei Verhalten und Daten:
| Workers-Ebene | Zu klärende Zielabbildung |
|---|---|
| Fetch Handler | API-Service, Anwendungsroute oder Gateway |
| KV | Cache, Key-Value-Datenbank oder Konfigurationsspeicher |
| Durable Objects | zustandsbehafteter Dienst mit explizitem Konsistenzmodell |
| D1 | relationale Zieldatenbank und kompatibles Schema |
| R2 | Object Storage und angepasste Zugangsdaten |
| Queues | Message Broker, Worker und Retry-Modell |
| Cron Triggers | Scheduler und beobachtbarer Job |
| Edge-Verteilung | zentrale, regionale oder erneut verteilte Architektur |
Eine Migration kann Codeänderungen erfordern. Ein OCI-Container allein ersetzt keine Workers-Plattform, wenn die Anwendung Bindings, Edge-Latenz oder zustandsbehaftete Plattformprimitive nutzt.
DigitalOcean App Platform: klassische PaaS-Migration
DigitalOcean App Platform ähnelt in vielen Fällen Railway oder Render. Inventarisiert werden:
- Web Services, Worker, Jobs und statische Komponenten
- Git-Quellen, Container-Images und Build-Einstellungen
- Umgebungsvariablen und Secrets
- interne und öffentliche Endpunkte
- Domains, Routing und Health Checks
- Managed Databases und Caches
- Spaces oder andere persistente Datenwege
- Regionen, Skalierung und Deployment-Regeln
Git- und imagebasierte Dienste können häufig auf Coolify oder Docker übertragen werden. Datenprodukte, Storage und private Verbindungen werden als eigene Migrationsstrecken behandelt.
Zielplattform und Infrastruktur getrennt entscheiden
Coolify, Docker und Kubernetes beschreiben die Plattformebene. Deutsche oder europäische Provider, kundeneigene Server und On-Premises-Systeme beschreiben den Betriebsort. Die Entscheidungen werden getrennt getroffen:
- Welche Runtime und Orchestrierung benötigt die Anwendung?
- Welche Daten- und Plattformdienste müssen ersetzt werden?
- Welche Verfügbarkeit und Skalierung sind erforderlich?
- Wo soll die Infrastruktur betrieben werden?
- Wer verantwortet Updates, Monitoring, Backups und Incidents?
Diese Trennung verhindert, dass ein Providerwechsel mit einer unpassenden Zielarchitektur verwechselt wird.
Wann der PaaS Exit Review der richtige Einstieg ist
Der direkte Migrationsweg passt zu klar abgegrenzten Anwendungen. Ein Review ist sinnvoll, wenn:
- mehrere AWS- oder Cloudflare-Dienste gekoppelt sind
- Edge- oder Serverless-Code auf eine andere Runtime wechseln muss
- Datenquellen und Schreibwege nicht vollständig bekannt sind
- mehrere Zielmodelle verglichen werden sollen
- Ausfallzeit, Sicherheit oder Compliance besondere Planung verlangen
Das Ergebnis ist eine Abhängigkeitskarte mit Zieloption, Risiken, Reihenfolge, Cutover- und Rückfalllogik.
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
Nur wenn Amplify tatsächlich auf Build und Webauslieferung begrenzt ist. Cognito, AppSync, Lambda, Storage, Hosting-Regeln und weitere AWS-Dienste machen daraus eine gekoppelte AWS-Architektur, die schrittweise entkoppelt werden muss.
Nicht automatisch. Workers verwenden eine andere Laufzeit und Plattform-APIs als ein klassischer Node.js-Server. Code, Bindings, KV, Durable Objects, Queues, D1, R2 und Edge-Annahmen müssen funktional auf eine Zielarchitektur übertragen werden.
Git- oder containerbasierte Webservices und Worker sind häufig gut portierbar. Managed Databases, Spaces, interne Dienste, Jobs, Domains und plattformspezifische Build- oder Skalierungseinstellungen müssen dennoch einzeln geprüft werden.
Ein PaaS Exit Review ist sinnvoll, wenn mehrere Plattformdienste gekoppelt sind, die Zielarchitektur offen ist, Edge- oder Serverless-Code angepasst werden muss oder Daten und Ausfallfenster den direkten Wechsel riskant machen.
