Migrate AWS Amplify, Cloudflare and DigitalOcean App Platform
Timo Wevelsiep•Updated: 30.08.2026Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual consulting.
Is your source not Vercel, Railway, Render, Fly.io, Heroku or Netlify? WZ-IT assesses other sources in a PaaS Exit Review from EUR 1,490 excluding VAT and implements clearly bounded PaaS migrations from EUR 1,990 excluding VAT.
A PaaS exit from AWS Amplify, Cloudflare Pages or Workers, and DigitalOcean App Platform needs source-specific analysis. The same term, "application", may describe a static website, a container service or a distributed system of edge code, identity, APIs and data products.
AWS Amplify: hosting or a coupled AWS stack?
First separate web hosting from backend resources. Capture:
- repository, branches, build specification and artifacts
- environment variables and secrets
- domains, redirects and rewrites
- server-side framework capabilities
- authentication, for example through Cognito
- APIs, for example AppSync or API Gateway
- functions, storage and connected AWS services
- preview and production environments
- logs, monitoring and data paths
A static Amplify application can often become a reproducible build with new web delivery. Auth, APIs, functions or storage turn the move into the separation of several AWS services. A phased transition is normally easier to control than replacing every component simultaneously.
Cloudflare Pages: static delivery plus platform capabilities
For Cloudflare Pages, capture builds, static assets, domains, redirects and Pages Functions. Bindings to KV, D1, R2, Queues or other Cloudflare products determine whether a simple hosting change is possible.
Static content can typically be exported and served through a web server or object storage. Pages Functions need porting into API routes, application logic or separate services. Reassess cache and edge behaviour deliberately on the target.
Cloudflare Workers: frequently a replatforming project
Cloudflare Workers do not run like a conventional persistent container. Runtime, request APIs, bindings, geographic distribution and limits differ from classic server processes. Planning therefore starts with behaviour and data:
| Workers layer | Target mapping to determine |
|---|---|
| Fetch handler | API service, application route or gateway |
| KV | cache, key-value database or configuration store |
| Durable Objects | stateful service with an explicit consistency model |
| D1 | relational target database and compatible schema |
| R2 | object storage and changed credentials |
| Queues | message broker, worker and retry model |
| Cron Triggers | scheduler and observable job |
| Edge distribution | central, regional or newly distributed architecture |
Migration may require code changes. An OCI container alone does not replace the Workers platform where the application uses bindings, edge latency or stateful platform primitives.
DigitalOcean App Platform: a conventional PaaS migration
DigitalOcean App Platform often resembles Railway or Render. Inventory:
- web services, workers, jobs and static components
- Git sources, container images and build settings
- environment variables and secrets
- internal and public endpoints
- domains, routing and health checks
- managed databases and caches
- Spaces or other persistent data paths
- regions, scaling and deployment rules
Git- and image-based services can often move to Coolify or Docker. Treat data products, storage and private connections as separate migration paths.
Decide platform and infrastructure separately
Coolify, Docker and Kubernetes describe the platform layer. German or European providers, customer servers and on-premises systems describe the operating location. Make these decisions separately:
- Which runtime and orchestration does the application need?
- Which data and platform services need replacement?
- Which availability and scaling objectives apply?
- Where should the infrastructure run?
- Who owns updates, monitoring, backups and incidents?
This separation avoids mistaking a provider change for a suitable target architecture.
When the PaaS Exit Review is the right entry
A direct migration suits a clearly bounded application. Use a review where:
- several AWS or Cloudflare services are coupled
- edge or serverless code changes runtime
- data sources and write paths are incomplete
- several target models need comparison
- outage, security or compliance requires additional planning
The result is a dependency map with a recommended target, risks, sequence, cutover and rollback logic.
Sources
Rather have it operated?
You'd rather not run PaaS & Cloud Exit yourself? WZ-IT handles setup, operations and maintenance - privacy-focused from Germany.
Enquiry
Assess a PaaS migration
Describe the source, application and intended target. We assess the migration path for runtime, data, delivery and ongoing operations.
Frequently Asked Questions
Answers to the most important questions
Only when Amplify is actually limited to build and web delivery. Cognito, AppSync, Lambda, storage, hosting rules and other AWS services create a coupled AWS architecture that needs gradual separation.
Not automatically. Workers use a different runtime and platform APIs from a conventional Node.js server. Code, bindings, KV, Durable Objects, Queues, D1, R2 and edge assumptions need functional target mappings.
Git- or container-based web services and workers are often portable. Managed databases, Spaces, internal services, jobs, domains and platform-specific build or scaling settings still require individual assessment.
A PaaS Exit Review is useful when several platform services are coupled, the target is open, edge or serverless code needs adaptation, or data and outage windows make a direct move risky.
