PaaS exit checklist: migrate applications safely

Moving an application away from Vercel, Heroku, Railway, Render, Fly.io or another PaaS? WZ-IT designs and delivers a PaaS and cloud exit from EUR 1,990 excluding VAT. For unclear dependencies and target options, use the PaaS Exit Review from EUR 1,490 excluding VAT.

A PaaS exit checklist prevents a cloud migration from being reduced to the repository and a container. Managed platforms perform many tasks invisibly: builds, certificates, environment variables, restarts, internal DNS, persistent data, logs and scaling. On the target, each function must be retained, replaced or explicitly excluded.

This checklist applies to Vercel, Railway, Render, Fly.io, Heroku, Netlify and similar platforms. Source-specific export methods differ, but the review gates remain largely the same.

Contents

• 1. Record objective and reason
• 2. Inventory applications and platform resources
• 3. Define target architecture and ownership
• 4. Make build and runtime portable
• 5. Plan data and persistence separately
• 6. Secrets, networking and integrations
• 7. Rebuild delivery and environments
• 8. Accept operations before cutover
• 9. Cutover and rollback
• 10. Retire the source safely

1. Record objective and reason

A PaaS exit needs a measurable objective. Common reasons include:

• make cost and scaling behaviour more predictable
• control infrastructure and data paths
• reduce platform lock-in
• separate development and production more clearly
• hand operations to an accountable service provider
• use private or European infrastructure
• consolidate several fragmented platforms
• professionalise application, backend and delivery together

The reason sets priorities. A cost-driven move may support a simple target platform. A regulatory or operations-driven exit often requires additional separation, documentation and recovery evidence.

2. Inventory applications and platform resources

Application

• repository and owner
• framework, language and runtime version
• package manager, lockfiles and private registries
• build and start commands
• container, buildpack or platform-specific build
• health checks and restart behaviour
• horizontal state and session behaviour

Platform

• services, workers and process groups
• cron jobs, queues and event handlers
• domains, redirects and TLS
• environment variables and secrets
• internal service names and private networks
• volumes, databases and object storage
• regions, replicas and scaling rules
• logs, metrics, traces and alerting

Organisation

• technical and business owners
• access to provider, DNS, repository and third parties
• maintenance window and business hours
• recovery objectives and accepted downtime
• current contracts, licences and cancellation periods

The output is a dependency map, not a loose list. Every production user journey should be traceable to runtime, data and external services.

3. Define target architecture and ownership

Choose the target for the requirement instead of reproducing every source detail.

Define RPO and RTO before implementation:

• RPO: maximum accepted data loss
• RTO: maximum accepted recovery duration

These objectives determine backups, replication, redundancy and cutover. Adding them later may require a different architecture.

4. Make build and runtime portable

• build is reproducible from a versioned commit
• lockfiles and required build tools exist
• private dependencies and registry access are documented
• runtime version and system libraries are fixed
• start command and ports are explicit
• health check tests real readiness
• important data is not written to an ephemeral filesystem
• configuration and secrets are not baked into the image
• graceful shutdown and restart are tested
• resource demand is measured under representative load

An OCI-compatible container image is a common portability unit, but not a complete operating model. Data, networking, secrets, deployment and recovery remain separate layers.

5. Plan data and persistence separately

Document one migration path per data source:

A pre-migration backup is necessary but does not replace rollback. Once the target accepts writes, decide how those records are handled if traffic returns to the source.

6. Secrets, networking and integrations

• secrets are inventoried without copying them into project documents
• target secrets are injected securely and rotated where needed
• internal hostnames are adapted to the target
• firewall and outbound connections are defined
• webhooks, OAuth redirects and callbacks are updated
• DNS TTL is reduced in time for cutover
• email delivery and sender authentication are tested
• partners receive new stable outbound IPs in advance
• administrative access uses a controlled private path

Environment variables separate configuration from code, but they are not automatically a secure secret system. Permissions, auditability, rotation and separation between staging and production still matter.

7. Rebuild delivery and environments

Establish the intended developer workflow before cutover:

• push or merge triggers the intended build
• tests and security controls run before deployment
• staging has separate variables and data access
• production uses the agreed approval
• the health check determines successful rollout
• failed releases can be rolled back technically
• database migrations are versioned and coordinated with the release
• preview environments have no uncontrolled production access

The platform change should not block development. The team keeps working in the repository while the target platform runs the defined build and deployment path.

8. Accept operations before cutover

• proactive monitoring is active
• relevant logs are centralised and protected
• errors and capacity limits produce actionable alerts
• backup jobs cover every persistent layer
• a representative restore is tested or firmly scheduled
• updates, maintenance windows and restarts are governed
• certificates and domains renew correctly
• contacts and escalation are documented
• service levels and exclusions are understandable
• operating documentation matches the actual environment

An application is not production-ready merely because its home page responds. Background jobs, backups, alerting and recovery belong in acceptance.

9. Cutover and rollback

A cutover runbook contains:

1. earliest start and latest decision point
2. owners for application, data, DNS and acceptance
3. write boundary or replication status
4. final data reconciliation
5. switching domains, variables and webhooks
6. technical and business smoke tests
7. observation period and acceptance criteria
8. explicit go/no-go decision
9. reversal and treatment of new target data
10. communication to affected teams

Rollback is not improvised. Test it technically before migration and give it a time window after which the source is no longer considered a reliable production target.

10. Retire the source safely

After successful cutover:

• wait for the rollback window
• retain final exports and required evidence
• remove old domains, webhooks and keys
• rotate secrets used on both platforms
• delete data under agreed retention rules
• cancel plans, add-ons and platform resources
• review billing and provider access
• update documentation and asset inventory

Do not delete the source account until ownership, data export and billing have been checked.

For specific platforms, migrating Vercel to Coolify or Hetzner and migrating Railway, Render or Fly.io add source-specific objects to this checklist.

Sources

• Open Container Initiative: Image Specification
• The Twelve-Factor App: Config
• Docker: Building best practices
• OpenTelemetry: Observability primer