Skip to main content
Moving doesn’t require rewriting the application. The safe order is: bring up a copy, move the configuration and data, test, and only then move the traffic.

Check the code

The port comes from PORT and the server listens on 0.0.0.0.
Secrets are read from environment variables, not from the code.
The start command doesn’t depend on a Procfile or a host-specific file.
Nothing writes important data only to local disk that another host was backing up for you.
A Procfile like web: node server.js becomes START=node server.js in vertracloud.config; a build step becomes BUILD=.

Step by step

1

Deploy a copy

Upload a .zip, import the repository from GitHub or run vertra deploy. Keep the old host live and don’t touch DNS yet.
2

Copy the environment variables

Recreate them in Config, leaving out PORT and HOST, which the platform sets. It’s a good moment to rotate secrets instead of copying them.
3

Move the database

Create the database, then export and import with the engine’s own tools: pg_dump/pg_restore, mongodump/mongorestore, mysqldump. For Redis, recreate the keys you need or let caches warm up again. Connect with TLS as shown in Connect a database.
4

Test the copy

Use the *.vertraweb.app address and exercise the flows that matter while watching the Logs tab.
5

Move the traffic

Put the old application in read-only or maintenance mode, run a final data sync, then point the DNS at Vertra Cloud with a custom domain.
6

Retire the old host

Keep it for a few days as a fallback, then shut it down.
Lower the TTL of your DNS record to a few minutes a day before the switch, so the change (or a rollback) propagates quickly.