Migrating between App Platforms is usually less about source code and more about build assumptions, environment variables, service topology, persistent data, domains, and release behavior.
Raff Apps supports Git deployments, buildpacks, Dockerfiles, existing images, Docker Compose imports, custom domains, managed service bindings, workers, scheduled jobs, persistent volumes, preview environments, and immutable rollback revisions.
Inventory the current platform
Record the repository, branch, build method, runtime, start command, variables, secrets, services, workers, scheduled jobs, databases, storage, volumes, domains, DNS, health checks, scaling, and deployment triggers.
Identify provider-specific dependencies
Look for provider manifests, internal hostnames, add-on URLs, deployment hooks, proprietary variables, filesystem assumptions, and CLI workflows.
Classify each dependency as portable, replace, remove, or retain externally.
Lock the build
Use dependency lock files, an explicit runtime version, and clear build/start commands. If the source platform relies on automatic detection, verify the target detects the same runtime.
Recreate configuration safely
Inventory non-secret variables, secrets, and provider-generated bindings. Do not paste production credentials into migration documents. Recreate secrets in the target platform's configuration layer.
Map service types
Typical mappings are web service to web service, worker to worker, cron to scheduled job, one-off task to one-off run, managed database to managed/external database, and persistent disk to persistent volume.
Migrate data separately
Application deployment and data migration are different cutovers. Databases, object storage, and persistent volumes need explicit migration and validation.
Deploy before moving traffic
Use the target platform URL first. Verify build, startup, variables, database connectivity, workers, uploads, scheduled jobs, and health checks before changing DNS.
Prevent duplicate workers and schedules
During overlap, two platforms may run simultaneously. Decide which side owns cron jobs, queues, billing jobs, and outbound messages.
Plan domain cutover and rollback
Lower DNS TTL where useful, verify target HTTPS, record old DNS, define rollback, then change only required records. Keep the source platform available until the rollback window closes.
Provider-specific inventory
For Heroku, record Procfile, buildpacks, Config Vars, add-ons, dyno process types, and Scheduler.
For Railway, record service variables, service references, volumes, private networking, and deployment triggers.
For Render, record Web Services, Background Workers, Cron Jobs, disks, environment groups, private services, and Blueprint configuration.
Migration checklist
Before migration:
- current topology inventoried;
- provider-specific dependencies identified;
- build is reproducible;
- secrets inventoried safely;
- services mapped;
- data migration planned;
- duplicate workers/cron prevented;
- target URL tested;
- custom domain verified;
- rollback defined.
Before decommission:
- production traffic stable;
- data consistent;
- workers/jobs correct;
- rollback window closed;
- source exports retained;
- source platform no longer receives required traffic.
Frequently asked questions
What is the hardest part of App Platform migration?
Usually persistent data, provider-specific services, environment configuration, and traffic cutover.
Should I move the database at the same time?
Only when needed. Keeping the existing database temporarily can reduce migration scope.
When should I change DNS?
After the target deployment passes application and dependency validation.
When should I delete the old platform?
After the rollback window closes and no required dependency remains.
Can Docker reduce platform lock-in?
It can improve build/runtime portability, but data, domains, secrets, volumes, and provider APIs can still create migration work.
