Migrating from the Standalone Veeam Backup for Nutanix AHV Appliance to VBR v13

What You're Actually Migrating From

If you set up Nutanix AHV backups before Veeam v12.2, you went through the standalone Veeam Backup for Nutanix AHV appliance. This was a separate product from VBR. It ran as a Linux-based virtual appliance deployed directly on your AHV cluster, had its own web interface at its own URL, and was managed completely independently from whatever VBR environment you had running for VMware or Hyper-V. Versions 4 through 7 of the product used this appliance model.

Starting with plug-in version 8, Veeam dropped the appliance requirement. The AHV integration moved natively into VBR. Plug-in version 9, which ships with VBR v13, continues that model and adds polish on top. This guide covers the migration from the old appliance world to the new native integration.

There are two paths depending on your situation. If you're upgrading an existing VBR environment that already has the AHV plug-in, you use the in-place upgrade path. If you're moving to a brand new VBR server and want to bring your AHV backups with you, you use the full appliance migration path. Both are covered here.

What You Gain and What Changes

Before the steps, it's worth being clear about what actually changes after this migration, because it affects how you plan and what operational disruptions to expect.

What you gain:

• AHV workloads managed from the same VBR console as everything else. No more separate web interface, no more logging into a different URL to check an AHV job.
• The full VBR feature set for AHV: SOBR support, malware detection, SureBackup, backup copy jobs, and Enterprise Manager reporting all apply to AHV backups now.
• Prism Central support, meaning one connection covers all clusters if PC is in your environment.
• The old appliance VM can be decommissioned, freeing cluster resources.

What changes operationally:

• Existing backup chains created by the old appliance are not automatically imported into VBR. The data is still on your repositories, but VBR doesn't know about it until you explicitly import it. That's a manual step, covered in detail later in this guide.
• Job definitions from the old appliance do not migrate automatically. You'll recreate jobs in VBR after the migration.
• The old appliance's internal database and configuration don't transfer. VBR starts fresh with the infrastructure you point it at.

Before You Start: Version Check and Prerequisites

The upgrade path to plug-in version 9 has specific version requirements that are not optional. Check all of these before doing anything else.

Path A: Upgrade In-Place via the Components Update Wizard

This is the path for most people. You already have VBR running, you have the old AHV plug-in in place, and you're upgrading VBR to v13. The process is largely automated through the Components Update wizard that runs after the main VBR upgrade.

Path B: Full Appliance Migration to a New VBR Server

This path is for situations where you're standing up a new VBR v13 server and want to carry your existing AHV backup infrastructure and backup data across to it. It has more steps than Path A because you're disconnecting the appliance from the old VBR server and reconnecting it to the new one, then importing existing backup chains. None of the individual steps are complicated, but the order matters a lot.

After Migration: Cleanup and Validation

Whether you took Path A or Path B, work through this list before calling the migration done:

• Run at least two full backup job cycles and verify both complete without errors.
• Perform a test restore of at least one VM end-to-end. A file-level restore from an existing restore point is a solid first check. A full VM restore is better.
• Confirm restore points appear correctly in Backups > Disk for all protected VMs.
• If you imported old backups via rescan, verify the imported chains show up correctly and are usable for restore.
• Confirm email notifications are configured and firing on the new server.
• Once you've had clean job runs for at least a week, power down the old appliance VM. After another clean stretch with no issues, delete it from the cluster.

Optional: Switch to Prism Central Deployment

If you were previously connecting to standalone Prism Element clusters and you have Prism Central in your environment, the migration to v13 is a good time to make the switch. Adding Prism Central gives you a single connection that covers all managed clusters instead of maintaining individual cluster entries.

To make the switch after migration: add your Prism Central instance to VBR under Backup Infrastructure > Managed Servers > Add Server > Nutanix AHV and enter the Prism Central address. VBR automatically reconfigures standalone cluster entries that are already managed by that Prism Central instance and converts them to PC-managed connections. Existing jobs continue to work through the new connection. You don't need to remove and re-add standalone entries manually.

Closing Thoughts

This migration is one of those things that sounds bigger than it actually is once you have the version requirements mapped out and the sequence clear in your head. The in-place upgrade path through the Components Update wizard is about as low-friction as a major platform migration gets, assuming you're already on 12.3.1 and plug-in 7.1 or 8. The wizard does the actual work.

The full migration to a new VBR server has more steps, but the steps themselves are not hard. The order is what matters: remove from the old server before connecting to the new one, rescan repositories before recreating jobs, validate restores before you decommission anything. Follow that sequence and it's clean.

The real payoff is what you get after. AHV workloads in VBR natively means they're part of the same protection strategy as everything else you're managing. Same malware detection, same SOBR policies, same SureBackup verification, same reporting in Enterprise Manager. That's what the whole migration is actually for, and it's worth the effort to get there.