Move a Project

Move a deployed project, with its data, to another server of the same team: for a bigger server, another region, or to retire an old machine. The project keeps its ID, settings, domains and history.

Nothing is deleted from the old server until you confirm that the project works on the new one.

Before you start

• You need the admin or owner role in the team, and you confirm it's you (two-factor or password), as for other sensitive actions.
• The project must be deployed. An undeployed project has no data to copy; clone it onto another server instead.
• The new server must be ready, and the old one reachable, because the data is copied from it.
• The project is unavailable while it moves: its services stop so the copy is consistent. Plan the move for a quiet time. It takes about as long as backing up and restoring all its data.

Start a move

1. Open the project's Settings → General → Move to another server.
2. Choose the new server. Zenavo checks it and shows:
   • whether the server is ready, the team is within its plan, and the server has enough free memory (from each service's memory limit, or its recent use);
   • domain and published TCP/UDP port conflicts with other projects on that server;
   • the data that will be copied;
   • the generated domains that switch automatically, and the DNS records you must change for custom domains.
3. Type the project name and click Move.

The move runs as a job. Its page shows each step and the log.

What happens

Step	What Zenavo does
Check the new server	Confirms it is ready and has room. Nothing has changed yet.
Stop writes	Stops the application services on the old server.
Back up	Dumps PostgreSQL and MySQL databases that have no volume, then stops them, then copies every volume as a .tar archive. Each file's SHA-256 is recorded.
Deploy	Deploys the same images and configuration on the new server with every service stopped. Initialization commands do not run: the data comes from the old server. TLS certificates are copied too, so HTTPS works as soon as traffic arrives.
Restore	Restores each volume into its new, empty volume, then starts the databases that need a dump and restores it.
Start	Starts the services in dependency order, with the instance count they had, and waits for their health checks.
Switch	Points each generated domain at the new server's address and makes it the project's server.

Services that were suspended or stopped before the move stay stopped on the new server.

If something fails

If any step before the switch fails, Zenavo undoes the move: the services start again on the old server exactly as they were, the copy on the new server is deleted, and the job fails with the reason. Your data on the old server is never changed by a move.

If undoing also fails (for example, the old server became unreachable), the move stays open and shows the reason. Click Roll back to retry once the problem is fixed. The copy on the new server is only deleted after the old server runs again.

After the switch

The project now runs on the new server. Its stopped copy, with all its data, stays on the old server. While the move waits for you:

• Custom domains: change their DNS records to the new server's address. The move page shows the exact record (type A or AAAA and the address) for each domain. Until you do, those domains still reach the old server, which is stopped.
• Check the application on the new server: sign-in, background workers, email, webhooks and anything else it depends on.
• Deploys and other project operations are paused, so the move can still be undone exactly.

Then choose one:

• Finish move deletes the stopped copy and its volumes from the old server, and the move's transfer files from Zenavo. After that the project cannot be rolled back to the old server.
• Roll back stops the copy on the new server, points generated domains back, starts the services on the old server with the data they had when the move began, and deletes the new copy. Changes made on the new server since the switch are not copied back. Point custom domains back too if you changed them.

Good to know

• Generated domain records are switched with a new record first and the old one removed after, so the name always resolves. Resolvers may keep the old address for up to five minutes.
• Data that a service keeps outside a volume (in its container) is not copied: it is lost on any restart anyway. Add a volume for data you need.
• The transfer files are the same kind as backups and appear in the project's backups until the move is finished or rolled back.
• Moving to a server of another team is not supported. Clone the project into the other team instead and restore a backup there.
• Every move, finish and rollback is recorded in the team's audit log.

API

Method	Path
GET	/api/projects/{pid}/move	The latest move: status, servers, data, domains, can_finish and can_roll_back
GET	/api/projects/{pid}/move/preflight?server_id=	Check a move without changing anything (admins)
POST	/api/projects/{pid}/move	Start: {server_id, confirmation: "<project name>"} (returns a job)
POST	/api/projects/{pid}/move/finish	Delete the stopped copy from the old server (returns a job)
POST	/api/projects/{pid}/move/rollback	Return to the old server (returns a job)

Starting, finishing and rolling back need step-up: with an API token on an account with two-factor authentication, send a current code in the X-Zenavo-OTP header.