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 rather than rebuild on Elastx IaaS/CaaS, your environment can be moved to another provider in the Virtuozzo Cloud Union. This guide uses beebyte (app.paas.beebyte.io, Sweden) as the target, but the procedure is the same for any Virtuozzo/Jelastic installation.

There are two routes:

Plan for route B as your baseline and treat route A as the shortcut. Do not delete anything at Elastx until the target environment is verified and serving traffic.

Before you start

1. Check the platform versions

An exported environment can only be imported into an installation of the same or a higher platform version.

The target is newer than the source, so this direction is allowed. Versions change — confirm the current numbers on the Virtuozzo Cloud Union partner pages before you start, and re-check if the migration is planned for a later date.

2. Inventory the environment

Write down everything that is not application data, because most of it does not travel with an export and has to be recreated by hand at the target:

• Node types and counts, cloudlet limits per node, and which nodes are scaled horizontally
• Public IPv4/IPv6 addresses (these are not transferred — the target gets new ones)
• Custom domains and their DNS records, plus current TTLs
• SSL certificates (built-in Let’s Encrypt add-on vs. custom certificates)
• Environment variables, cron jobs, and firewall rules per node
• Files edited through the Configuration Manager (nginx.conf, php.ini, server.xml, …)
• Database users, grants, and passwords
• Add-ons installed from the Marketplace
• Outgoing mail setup, and anything that depends on the current source IP being allow-listed by a third party

3. Create the target account

Register at beebyte (or your chosen provider) and confirm the quotas on the new account are large enough for the topology you are about to import — cloudlet limits, disk, and number of environments.

Route A: native Environment Export / Import

Known caveat for exports from Elastx

Virtuozzo’s own documentation states that the export/import feature requires the source platform to have port 7979 reachable, and it explicitly names Elastx as an installation whose exported environments therefore may not be importable elsewhere:

For the Environment Export / Import feature to work properly, the initial hosting provider platform (i.e., you are exporting the environment from) should have the 7979 port opened […] Thus, depending on a particular provider’s configurations, exported environments from some of our partners’ platforms (Elastx and Everdata in particular) can’t be imported to other PaaS installations.

— Environment Export, Virtuozzo docs

The manifest itself contains links to the archives holding your private data; it is those downloads that need port 7979 during import. Consequences:

• A topology-only export is still portable, and is useful as a blueprint even if the data transfer is blocked.
• Before committing to route A, test it with a small throwaway environment: export it with all options ticked, import it at the target, and confirm the data actually arrives.
• If the import fails on fetching data, contact support@elastx.se and ask whether port 7979 can be opened for your migration window, and use route B meanwhile.

Export at Elastx

1. The environment must be in Running status.
2. In the dashboard, click Settings for the environment you want to move.
3. Go to the Export section and click Export.
4. In the Environment Export dialog, tick all three options for a fully identical copy:
   • Topology Settings — node layout and configuration (mandatory, always on)
   • Private Data — application files and database contents
   • Configuration Files — everything reachable via Configuration Manager, plus GIT/SVN project settings (repository URLs, credentials, attached private SSH keys)
5. Click Export and wait. Note what will not come along:
   • Data from Elastic VPS, Maven, Docker and Windows-based containers is not exported. These nodes appear in the imported topology but are created from scratch — reconfigure them manually.
   • Exporting an NGINX node (load balancer or application server) briefly stops and restarts that node to take a dump. Do this outside peak hours.
6. When the export finishes, a new entry appears under Exported Environment Copies, named after the export date/time. Click it to download the .json manifest, or right-click to copy a direct URL to it. You also get an email with a link to the list.

Exported copies are stored in your disk space and are billed like any other storage. Delete them with the red cross button once the migration is done.

Import at beebyte

1. Log in to the target dashboard (app.paas.beebyte.io) and click Import at the top.
2. Choose a tab:
   • Local File — browse to the .json you downloaded
   • URL — paste the direct manifest URL you copied at Elastx
   • JPS — the built-in editor, if you need to hand-edit the manifest first
3. Click Import. The confirmation window shows the source platform and export date. Fill in:
   • Environment — the domain name of the new environment
   • Display Name — optional alias
   • Region — if the provider offers several
4. Click Import and wait for the environment to be created and configured. You can minimize the window; it continues in the background.
5. Check your email at the target provider for the new hostname and the generated node credentials — these are new, the old passwords do not follow.

If the import fails, open Import > JPS > View Logs at the target for the error.

Route B: manual rebuild and data migration

Use the exported .json as the blueprint even if you cannot import it — it is readable JSON and describes the full topology.

1. Recreate the topology

Build the same node layout in the target’s topology wizard: same engines and same or newer engine versions (PHP, Java, Node, database), same cloudlet limits, same horizontal scaling. Install the same Marketplace add-ons.

2. Move application files

Both platforms expose an SSH gateway on port 3022, so you can copy directly between them:

Upload your public SSH key under Account Settings > SSH Keys on both platforms, then either pull the data down to a workstation and push it up, or copy node-to-node:

# From a machine with access to both, per node:
ssh -p 3022 <source-node-uid>@gate.jelastic.elastx.net \
  "tar czf - -C /var/www/webroot ROOT" > webroot.tar.gz

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

The node UID is shown in the dashboard next to each container (it is also the SSH username). rsync -az -e 'ssh -p 3022' works too and is better for repeated syncs — run it once up front and again at cutover to catch the delta.

Alternatively, use the Web SSH terminal and the file manager behind the configuration wrench in either dashboard. Note that the Elastx guides for copying files and copying a SQL database use mount points between environments — that only works within one platform, not across providers.

3. Move databases

Dump at the source, restore at the target. Over the SSH gateway, for MySQL/MariaDB:

ssh -p 3022 <db-node-uid>@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-uid>@gate.paas.beebyte.io \
  "mysql -u <user> -p<password>"

Use pg_dump/pg_restore for PostgreSQL and mongodump/mongorestore for MongoDB. Recreate database users and grants separately — they are not always part of the dump. For small databases phpMyAdmin’s export/import works, but it is fragile above a few hundred megabytes; prefer the CLI.

4. Reapply configuration

Node passwords, IPs, and hostnames all change. Go through the inventory from step 2 and reapply: Configuration Manager files, environment variables, cron jobs, firewall rules, SSL certificates, and any connection strings or config files in your application that reference the old hostnames, IPs, or database credentials.

Cutover

1. Lower DNS TTL on the affected records to 300 seconds at least 24–48 hours before the switch, so a rollback is fast.
2. Test on the target’s own hostname first (<env>.paas.beebyte.io), with the application fully configured.
3. Re-sync the delta: run the file rsync and a fresh database dump immediately before the switch, ideally with the source application in read-only or maintenance 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, and monitoring all need the new public IP.
6. Keep the Elastx environment running — stopped, but not deleted — until you are confident. Virtuozzo’s documentation recommends the same: do not delete the original of an exported environment until the copy is verified at the target.

After the migration

• Delete the exported copies at Elastx to stop paying for their storage.
• Stop and then delete the source environment once you are done. Removing running environments is also 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 an additional 180 days before permanent removal, and you can request a copy. See the EOL FAQ.

Checklist

• Target platform version is same or higher than Elastx’s
• Target account created with sufficient quotas
• Environment inventory documented (IPs, domains, certs, env vars, cron, firewall, grants)
• Route A validated with a throwaway environment, or route B chosen
• SSH keys uploaded on both platforms
• Topology recreated / imported and verified
• Files migrated
• Databases migrated, users and grants recreated
• Configuration and connection strings updated for new hostnames/IPs/credentials
• Application tested on the target hostname
• DNS TTL lowered
• Final delta sync done with source in maintenance mode
• Domains and SSL attached at target, DNS switched
• Third-party IP allow-lists updated
• Source environment kept intact until verified, then removed
• Exported copies deleted

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.