Migration
Moving is mostly a database and a DNS record.
The application itself is already in Git. What takes the time is the data, the environment variables, and the ten minutes of overlap where both are live.
Migrations get postponed because they are imagined as a project. For a normal web application on a normal platform they are closer to an afternoon: the code is already in a repository, the environment variables are a list you can read, and the database moves with the standard tools it came with.
What genuinely needs planning is the cutover — the window where the old platform and the new one are both live, and writes must land in exactly one of them.
- Comes across as-is
- The repository, the Dockerfile, the build command, the environment variables
- Has to be recreated
- Managed database instances, persistent volumes, cron schedules, custom domains
- The careful part
- The cutover window — where writes go while DNS propagates
- Typical database import
- Minutes for anything under a few gigabytes, using pg_dump or the equivalent
Do it before you need to
The worst time to move platforms is during an outage on the platform you are leaving, which is unfortunately when most people start. A migration performed calmly on a Tuesday takes an afternoon; the same migration performed while production is down takes the same afternoon and costs a great deal more.
If you are reading this during an incident: bring the application up on the new platform first and leave DNS alone. Having somewhere to point is worth more than pointing at it immediately.
Guides in this section
- Railway DownCheck whether Railway is actually down or the fault is yours, keep the site up while it is, and see what moving off involves once the incident is over.
Read next
- From a Git repository to productionGit repository to production with Dockup: create a service, choose Nixpacks or Dockerfile, configure health checks, deploy, verify, and roll back.
- The managed PostgreSQL guideManaged PostgreSQL on Dockup: create a database, connect a service securely, inspect size and logs, back up data, restore safely, and add read-only users.
- Custom domains and automatic TLSCustom domain and automatic TLS on Dockup: add DNS, verify ownership, issue HTTPS, expose extra ports, validate cutover, and troubleshoot safely.
- Environment variables and secretsEnvironment variables and secrets on Dockup: set, import, mask, rotate, and redeploy configuration safely for services and autonomous agents.
Questions this page gets asked
How long does a migration take?
An afternoon for a normal application: the code deploys from the same repository, the environment variables are copied, and a database under a few gigabytes imports in minutes. The cutover itself is a DNS change.
Will there be downtime?
Not necessarily. Bring the application up on Dockup first and leave the old one serving. Once the new one is answering correctly, move DNS — the overlap is what avoids the gap.
What about my database?
It moves with the standard tools. Dockup provisions the engine and version you are already on, and you import with pg_dump, mysqldump or mongodump as appropriate.
Start on the free plan.
Ten dollars of infrastructure credit is already there, and no card is required.