Migrate an environment to another provider

Overview

Virtuozzo PaaS at Elastx reaches end of life 2026-12-31. If you want to stay on the same platform technology, your environment can be moved to another provider in the Virtuozzo Cloud Union. This guide uses beebyte (Sweden) as the target, but the steps are the same for any Virtuozzo/Jelastic installation.

The move is manual: you create a new environment at the target and copy files, configuration files and databases across yourself over SSH. Treat it as a rebuild rather than a lift-and-shift. It is a good opportunity to land on current engine versions and clean out what you no longer need.

Do not delete anything at Elastx until the target environment is verified and serving traffic.

Before you start

1. Create the target account. Sign up through Elastx’s beebyte referral link and check that the account’s quotas cover your topology: cloudlets, disk, and number of environments.
2. Upload your public SSH key under Account Settings > SSH Keys on both platforms. You need it in steps 2 and 3.
3. Know what you are recreating. Keep the Elastx dashboard open next to the target’s; it is your reference throughout. Besides the topology and the data, this is set up again by hand at the target:
   • Public IPv4/IPv6 addresses — the target gets new ones
   • Custom domains, their DNS records, and SSL certificates
   • Auto Horizontal Scaling triggers
   • Environment variables, cron jobs, and per-node firewall rules
   • Database users, grants, and passwords
   • Marketplace add-ons
   • Outgoing mail setup, and any third-party allow-list that names your current IP

Step 1: create the environment at beebyte

1. Log in at app.paas.beebyte.io and click New Environment.
2. In the topology wizard, build the same layout as at Elastx: node types, node counts and cloudlet limits. Pick current engine versions where your application supports them.
3. Click Create. You get an email with the new hostname and the generated node credentials.
4. Set up Auto Horizontal Scaling again and install the Marketplace add-ons you had.

Step 2: move application and configuration files

Both platforms expose an SSH gateway on port 3022:

Connect as <node-id>-<user-id> to go straight to a node. The node ID is shown in the dashboard next to each container, and the user ID is your account ID at that provider. With only <user-id> the gateway opens an interactive menu where you pick the environment and node yourself. From a machine with access to both, per node:

ssh -p 3022 <source-node-id>-<elastx-user-id>@gate.jelastic.elastx.net \
  "tar czf - -C /var/www/webroot ROOT" > webroot.tar.gz

cat webroot.tar.gz | ssh -p 3022 <target-node-id>-<beebyte-user-id>@gate.paas.beebyte.io \
  "tar xzf - -C /var/www/webroot"

To skip the local copy, run it node to node instead: open Web SSH on the target node, run ssh-keygen, add the resulting public key under Account Settings > SSH Keys at Elastx, and pull straight from the source:

ssh -p 3022 <source-node-id>-<elastx-user-id>@gate.jelastic.elastx.net \
  "tar czf - -C /var/www/webroot ROOT" | tar xzf - -C /var/www/webroot

Copy configuration files the same way. These are the files you have changed through the Configuration Manager (the wrench on each node), for example:

ssh -p 3022 <source-node-id>-<elastx-user-id>@gate.jelastic.elastx.net \
  "tar czf - -C / etc/nginx/conf.d etc/php.ini" > config.tar.gz

Copy individual files rather than whole system directories, and compare them with the target’s defaults before you unpack: a newer engine version may not accept an old config file as is.

Note down when you start the first copy. At cutover you copy again, but only the files that changed after that point. rsync is not installed on every node and cannot be added, so use the --newer-mtime option of tar instead:

ssh -p 3022 <source-node-id>-<elastx-user-id>@gate.jelastic.elastx.net \
  "tar czf - --newer-mtime='<YYYY-MM-DD HH:MM>' -C /var/www/webroot ROOT" \
  | ssh -p 3022 <target-node-id>-<beebyte-user-id>@gate.paas.beebyte.io "tar xzf - -C /var/www/webroot"

This does not remove files at the target that were deleted at the source. If that matters, compare the two file lists (find /var/www/webroot -type f | sort) and remove the extra files by hand.

If you prefer a sync tool, run one on your own machine that works over SFTP, such as rclone sync or lftp mirror. These need nothing installed on the nodes, but all data passes through your machine. The file manager behind the configuration wrench in either dashboard works for small jobs.

The Elastx guides for copying files and copying a SQL database use mount points between environments, which only works within one platform. They do not apply here.

Step 3: move databases

Dump at the source, restore at the target. For MySQL/MariaDB over the SSH gateway:

ssh -p 3022 <source-db-id>-<elastx-user-id>@gate.jelastic.elastx.net \
  "mysqldump -u <user> -p<password> --single-transaction --routines --triggers \
   --databases <db1> <db2>" | gzip > dump.sql.gz

zcat dump.sql.gz | ssh -p 3022 <target-db-id>-<beebyte-user-id>@gate.paas.beebyte.io \
  "mysql -u <user> -p<password>"

Use pg_dump -Fc/pg_restore for PostgreSQL and mongodump/mongorestore for MongoDB. Recreate database users and grants separately — they are not always part of the dump. phpMyAdmin’s export/import is an option for small databases, but gets fragile above a few hundred megabytes.

Step 4: reapply configuration

Work through the list in Before you start. In your application and in the configuration files copied in step 2, update everything that references the old hostnames, IP addresses or database credentials. Restart the affected nodes so the configuration takes effect.

Step 5: cutover

1. Lower the DNS TTL on the affected records to 300 seconds at least 24 to 48 hours ahead, so a rollback is fast.
2. Test on the target’s own hostname first: <env>.sekd1.beebyteapp.io.
3. Re-sync the delta immediately before the switch — the delta copy from step 2 and a fresh database dump — ideally with the source in maintenance or read-only mode so nothing is written after the final dump.
4. Attach custom domains and certificates at the target, then switch DNS.
5. Update anything IP-bound: third-party allow-lists, payment providers, SMTP relays, monitoring.
6. Keep the Elastx environment stopped but not deleted until you are confident.

After the migration

• Delete the source environment. Removing running environments is a prerequisite for closing the Elastx PaaS account.
• If you discover a gap after the EOL date: Elastx disables the service but stores customer data for a further 180 days before permanent removal, and you can request a copy. See the EOL FAQ.

Checklist

• Target account created, quotas sufficient
• SSH keys uploaded on both platforms
• Environment created at the target with matching topology
• Add-ons, Auto Horizontal Scaling, env vars, cron and firewall rules recreated
• Application files and configuration files copied
• Databases copied, users and grants recreated
• Connection strings and config updated for new hostnames, IPs and credentials
• Application tested on <env>.sekd1.beebyteapp.io
• DNS TTL lowered
• Final delta sync done with the source in maintenance mode
• Domains and certificates attached at the target, DNS switched
• Third-party IP allow-lists updated
• Source environment kept intact until verified, then removed

Need help?

Elastx offers consultative assistance with migration scoping and design — contact support@elastx.se. For questions about the target platform, contact the receiving provider.