VPS Panel Migration

What VPS Panel Migration does

VPS Panel Migration takes over hypervisor nodes that are currently run by another control panel — Virtualizor, SolusVM2 or Proxmox VE — and brings them under FluxBilling. You supply SSH credentials for the node; FluxBilling installs its agent, registers the node as a VPS cluster, reads what is running, and adopts the virtual machines — which then appear alongside everything else in Virtual Machines. The VMs keep running throughout. Nothing is stopped, restarted or rebuilt, and the old panel stays installed and untouched until you explicitly choose to remove it.

Started with a single node — the master node of the panel you are leaving, in Virtualizor and SolusVM2 terms — it goes further: it reads that panel's own database over SSH, read-only, and brings across the slave nodes it manages, the plans it sells, its hypervisor groups, its IP pools and the owner of every VPS.

Requirements

• The VPS module must be enabled. The page does not appear otherwise.
• An administrator with permission to edit VPS resources.
• Root SSH access to each hypervisor node, by password.
• A free VPS cluster slot in your licence for every node you migrate. Each hypervisor becomes one cluster. If the licence does not cover another cluster, that node stops with a clear message and a link to your License settings; the rest of the run continues.
• For a master-first run: the master node is the one machine of your old panel whose panel database lives on it. A standalone node with no panel database migrates perfectly well — you just do not get the catalogue.

How to reach it

Go to Settings, open the Migration Tools group, and choose VPS Panel Migration. A stepper across the top shows Nodes → (Slaves) → Migration → Results; the Slaves step appears only once slave nodes have been discovered.

Step 1 — Nodes

Pick a Source panel card if you already know it — Virtualizor, SolusVM2 or Proxmox VE — or leave it on Auto-detect. The hint is optional: the agent identifies the panel on each node by itself.

Then list the nodes under Hypervisor nodes. The first row is the master node of the old panel (or your standalone node), and it is labelled as such. For Virtualizor and SolusVM2 that is the node whose panel database lives there; entering only that node is enough to discover the rest of the cluster.

Add node adds a row and stops at 20 nodes per run; the trash icon removes one, and the last remaining row cannot be removed. Start migration stays disabled until every row has a host and a password.

You are not asked for a location or a placement pool, because the source panel already knows both: each hypervisor is filed at the location its own group names, and the groups themselves become placement pools. Anything the panel cannot place is listed on the Results step so you can file it by hand.

What gets installed on a node

The install is deliberately lean, and the page says so before you start. A hypervisor node receives the FluxBilling agent, the virtualisation stack (QEMU/KVM, libvirt and cloud-image tooling) and time synchronisation. No BMC tooling, no network-boot services and no browser tooling are added. On a warm node the install typically takes one to two minutes.

What happens to each node

Nodes are processed two at a time; each node's own pipeline runs in order. The progress step names the stage it is in and explains what that stage is doing.

The page polls for updates while a run is moving, so you can leave it open and watch. Each stage is bounded: the agent has five minutes to come online, the licence wait three minutes, discovery up to thirty minutes, adoption up to an hour. If the panel itself restarts mid-run, nodes caught in flight are marked failed with a retry hint — the jobs already handed to an agent finish on the node, and the per-cluster Imports tab still shows them. Every instruction the panel sends an agent, and how to read one that stalled, is covered in Jobs.

Closing or reloading the tab does not lose the run: reopen the page and it picks the run back up. Passwords are never kept, so a retry asks for them again.

Retrying a node

A failed node shows a Retry node button. You re-enter that node's SSH password and it re-runs inside the same migration run. Two failures have their own explanation and a link to your licence page: the licence does not cover another VPS cluster, and the licence certificate for this cluster had not arrived yet — the second normally clears on a retry a minute later.

Step 2 — Slaves (master-first runs)

If the master node's database lists slave nodes, the run parks and the Slaves step appears with those nodes already filled in — host, port and user prefilled from the panel's own records, along with each node's VPS count and virtualisation type.

• Enter each node's SSH password, or tick Use the same SSH password for all slaves and type it once.
• Only rows with a password are submitted, and the button says how many that is. The rest stay pending and re-surface here after the first batch finishes, so you can migrate a large cluster in waves.
• Skip — master only finishes the run without the slaves. You can migrate them later as an ordinary new run.

You can correct a prefilled host if the node answers SSH on a different address; the run accepts it as an extra node.

Step 3 — Results

The results step is a report of everything the run brought across, headed by a one-line verdict — completed, finished with errors, or failed.

• Per node: the stage it reached, how many VMs were adopted, and a link to open the cluster it created. A node that adopted nothing says so rather than showing a zero.
• Flagged VMs — machines that were discovered but deliberately not adopted, each with its reason. Adopt them by hand later, or leave them on the old panel.
• Hypervisor groups — how many placement pools were created from the panel's groups, how many were updated, and how many clusters were assigned or moved. Nodes the panel could not place are listed by name as filed at your default location, which matters because location is what address allocation and the order form filter on. See Groups & Migration Pools for what a group then decides.
• Plans — how many were created and how many were skipped because a plan of that name already existed or the source record was incomplete. Existing plans are never modified. What a plan holds and where it is edited afterwards is covered in VPS Plans.
• Subnets — IP pools imported into IPAM: subnets created, addresses created, and addresses linked to the VM already using them. Pools that already existed are reused unchanged and counted separately. IPv6 pools, and anything whose network could not be derived, are reported as not imported. Where the source panel's own data disagrees about a range, that range is listed for you to check before you allocate from it.
• Client matches — VMs whose owner in the old panel matches an existing client here, grouped by e-mail address. Nothing is linked automatically; you link a VM to a service from the cluster page.
• IP pools reported by the panel — name, gateway, netmask and range, shown for reference against what was actually imported.
• Remove old panel — a collapsed section under each completed node. See Removing the old panel below; nothing here runs on its own.

If the first node carried no readable panel database, a note says so plainly: plans, groups, IP ranges and owners were not imported, but the VMs themselves migrated normally. Start another migration clears the screen for a fresh run.

Note: Adopted VMs keep running and stay unsold until you link them to a billing service. Adoption gives you the machine; linking gives it an owner and an invoice. Proxmox VMs run in compatibility mode at first and convert to the native virtualisation format at their next power cycle.

What the wizard never does

• It never restarts a VM. Discovery is read-only, and adoption does not power-cycle anything.
• It never writes to the old panel's database. The panel-database read is a plain read.
• It never removes the old panel on its own. That is a separate action you start per node, with a typed confirmation.
• It never keeps your SSH passwords in the wizard. They are held only until the agent record is written — stored the same way any agent install stores them — and are never written into the run's saved state or its logs. That is why a retry asks again.
• It never invents placement. Location and pool come from the source panel, or the node is filed at your default location and reported.

Finishing the takeover

Adoption is not the end of a migration. Two more things usually stand between an adopted estate and switching the old panel off, and both live in the Finish the takeover panel underneath the wizard. Both are preview-first and re-runnable, and neither touches a hypervisor, a price or a due date. A Re-check button refreshes both previews.

VMs on shared clusters

If this panel sells machines that live on hypervisors it does not own, this section claims them. Four counters summarise it: how many unowned VMs were seen on the owning panel, how many are exact identifier matches, how many match on address only, and how many are in conflict. A short evidence list shows the first few. If this panel owns its own hypervisors, the section says so and there is nothing to do.

• Claim the exact matches in one click.
• Address-only matches are deliberately not claimed by default and have to be included explicitly with a second, separate button, because an address recycled from one customer to the next looks exactly like a genuine match — and a wrong claim hands someone power, console and reinstall over another customer's machine. Check those individually.

Claiming the exact matches can also happen on its own: the VPS module has a setting, off unless you switch it on, that claims exact identifier matches every few minutes. When it is on, the panel says so here, and this list normally holds only what that automation refuses to decide — address-only matches and conflicts. That setting, and the rest of the module-wide behaviour, is in VPS Settings; the arrangement where two panels share hardware is described in Panel Links.

Services still on the old panel's plugin

The cutover: live services whose provisioning still dispatches to the old panel's plugin are moved onto the native VPS module. The panel counts how many plugin-backed services there are, how many are ready to move, and how many are blocked, with the reason for each. Moving a service changes which module handles its lifecycle — nothing about the machine, its price or its renewal date changes.

The per-cluster Imports tab

Everything the wizard automates is also available one cluster at a time, and this is where you go for the steps that come after a migration. Open VPS, choose a cluster, and select the Imports tab. It is also the place to import a node you added by hand rather than through the wizard.

Discovery and adoption

Pick the source panel and press Start Discovery (the cluster's agent has to be online). Discovery inventories the node's panel, domains, storage and bridges, read-only — nothing changes until you adopt. When it finishes you get a Review discovered VMs table of every VM found — name, state, resources, disks and IP addresses — where you map each one and select what to adopt. VMs the importer flags cannot be adopted and are shown with their reason. Adoption never restarts a VM; while it runs, the old panel's services on that node are disabled, which is reversible.

Some things are read but deliberately not carried over, and the review step says so plainly: backups, HA/corosync configuration, Ceph/RBD disks, SDN configuration and per-VM firewall rules are dropped. Plan for those separately.

Import IP pools into IPAM

After adoption, this card previews the old panel's IP pools and creates subnets and addresses from them, linking addresses already in use to the VM using them. Nothing existing is modified: a subnet already in IPAM is reused as-is. Press Preview to see, per pool, how many addresses are in use, free and reserved, how many are already known here, which ranges overlap something you already have, and which were untagged on the old panel and will get a bookkeeping VLAN so they can be allocated. Only IPv4 pools are importable. Tick the subnets you want, decide with Allow new orders to allocate from these subnets whether they go straight into circulation, and import.

Panel catalogue, service links and node names

A panel read covers every hypervisor that panel owns, not just this cluster, and it feeds three optional follow-ups. All three are off by default, and opening the screen changes nothing — the counts are computed either way. Tick what you want and press Apply to this platform.

• Create the plans this panel has and this platform does not — create-only. A plan whose name already exists is left exactly as you left it, ceilings included. The preview lists each plan with whether its ceilings will be enforced or merely recorded.
• Match imported VPS addresses against active services and link them — only an unambiguous single-address, single-service match is ever linked. Everything else is listed for you to do by hand, in four groups: already linked, needs review (the addresses agree but the owner e-mail and the client do not), conflicts (more than one candidate on one side), and no matching service. Read the list before committing: a link makes that machine belong to that invoice, and gives the service's owner power, console and reinstall over it.
• Rename each matched cluster to the name the source panel gives that hypervisor — cluster names appear in alerts, deploy logs, tickets, the pool screen and every lookup you do by name, so this changes all of them at once. Nothing about the hypervisor, its guests or its agent moves. Where two nodes want one name, or a name is already taken, neither side is renamed. Clusters the wizard created are already named from the panel, so this mostly matters for clusters you built by hand.

Linking and renaming each ask for a final confirmation naming the counts before anything is written.

Removing the old panel

The last step, and the only destructive one. It is per node, it is never automatic, and it requires you to type the cluster name to confirm. It is offered both on the wizard's Results step under each completed node and here on the cluster's Imports tab.

1. An escrow archive of the old panel's database and configuration is taken on the node first. Its path is shown when the job finishes — keep it.
2. The panel is then removed from the node.

Warning: Two things are worth reading before you confirm. If the host filters traffic with rules that nothing on disk restores, removal is refused until you tick an explicit acknowledgement, because removing the panel would leave that host with no firewall at all after the next reboot — including whatever was filtering your guests' console ports. The current rule set is captured in the escrow archive either way, but you need a replacement ready. And a Proxmox node cannot have its panel removed while VMs are still in compatibility mode: power-cycle them to convert first.

Suggested order for a full migration

1. Migrate the old panel's master node first and let it discover the cluster.
2. Supply the slave passwords, in waves if the cluster is large.
3. Check the Results step: flagged VMs, groups, plans, subnets and client matches.
4. Import the IP pools into IPAM and check for overlaps before allocating anything new.
5. Link adopted VMs to their billing services — by hand, or with the address-matching preview after reading it carefully.
6. Run the cutover so live services stop dispatching to the old panel's plugin.
7. Watch a full renewal and a provisioning action land correctly.
8. Only then, per node, take the escrow archive and remove the old panel.

Troubleshooting

Related

WHMCS Migration, EasyDCIM Migration, VPS Hosting Overview, Clusters, Virtual Machines, IPAM, Locations, Services, Local Agents, License.