Migrate Master Virtualizor The Right Way

Step-by-step guide to migrate master Virtualizor safely. Avoid common mistakes, fix localhost issues, and move your master the right way. Our 24/7 Virtualizor Live Support Team is always here to help you.

If you’re searching for migrate master Virtualizor, chances are something already went wrong, or you want to avoid breaking a live cluster. Good news: you’re in the right place.

Many admins follow random forum advice, dump databases, import them, and then panic when Virtualizor creates a ghost “localhost” server they can’t edit. VPS nodes go offline. Storage configs vanish. I’ve seen this happen more than once, and yes, it’s fixable. More importantly, it’s preventable.

Let’s walk through the correct way to migrate master Virtualizor, explain why it fails for many users, and show what actually works.

First, Understand This Clearly

The official migrate master Virtualizor script works ONLY for Master-only panels.

If your old server was both Master + Slave, database export/import will break the cluster structure. That’s exactly how you end up with:

• A locked “localhost” server
• VPS nodes marked offline
• Duplicate storage entries
• Uneditable server records

Now let’s do it properly.

Correct Way to Migrate a Master-Only Virtualizor Server

Prepare the New Server

Install OS on the new server and install Master-only Virtualizor panel. Do not add slaves yet.

Export Database from Old Master

Run this on the old master:

/usr/local/emps/bin/php /usr/local/virtualizor/scripts/migrate_master.php export

You’ll be asked to enter the slave server ID that will become the new master.

Once done, Virtualizor exports the database here:

/var/virtualizor/virtualizor_migrate_master.sql.gz

Copy the Database to New Master

scp -P PORT /var/virtualizor/virtualizor_migrate_master.sql.gz root@NEW_SERVER_IP:/var/virtualizor/

Import Database on New Master

/usr/local/emps/bin/php /usr/local/virtualizor/scripts/migrate_master.php import

At this point, your slave becomes the new master.

Important Post-Migration Tasks

• Update Master IP in WHMCS / Blesta
• Update license IP in Virtualizor client center
• Move custom templates:
• /var/virtualizor/
• /vz/template/cache/ (OpenVZ)

This is where most guides stop, and where problems start later.

Why Migration Fails for Many Users

Here’s the real issue.

Admins often:

• First, move all VPS servers first
• Then create a manual database backup
• After that import it into a fresh server

Result? Virtualizor thinks it’s a brand-new cluster and creates a new localhost server internally. Since server IDs don’t match, nothing lines up. That’s not a MySQL bug. It’s a misuse of the migration process.

The migrate master Virtualizor guide is not designed for mixed Master+Slave setups.

The Simple Alternative (Works 90% of the Time)

If you had one server and want a new master:

1.  First, install Virtualizor on the new server

2. Then add the old server as a slave

3. Remove slaves from the old master

4. Promote the new server naturally

No database export. No ghost localhost. No downtime nightmares.

Master-Only VPS Migration

If your master runs inside a VPS:

• First, take an immediate DB backup
• Then install Master-only panel on a new VPS
• Restore the database
• Move universal.php from old to new:
• Path: /usr/local/virtualizor/universal.php
• Update $dbpass carefully
• Finally, update new master IP in universal.php on all slaves

Then shut down the old master VPS.

Conclusion

If you want migrate master Virtualizor to succeed, follow the right method for your setup, not a generic copy-paste guide. Most failures happen because users rush database imports without understanding cluster roles.