This article is intentionally for one specific scenario: upgrading an existing Windows-based Veeam Backup & Replication installation from v12.x to v13—including the issues that can come up in real-world upgrades.
I already wrote a general blog post about patches/upgrades that serves as a guideline for practically all Veeam updates (pre-checks, order of operations, typical pitfalls, rollback strategy, change window, etc.). That guidance is still fully valid.
What about the VSA (Veeam Software/Server Appliance)?
If you can/want to move directly to the VSA, the best approach is usually a greenfield installation: deploy a new VSA and rebuild your jobs step by step according to current best practices. This is not only the cleanest migration path, but also a great opportunity to remove legacy baggage and review/update your configuration in detail — aligned with best practices and your specific use cases.
There is also a migration path from Windows (e.g., 12.3) to VSA 13.0.1, but it comes with limitations and is typically handled as a project planned and accompanied by a partner plus Veeam Support (clarify scope/limitations should be evaluated up front). Entry point/FAQ:
- Veeam KB – Veeam Backup & Replication Platform Migration Guide
https://veeam.com/kb4800 - Migrations Support registration:
https://go.veeam.com/vsa-conversion
In general, the VSA is great (lifecycle, hardening and deployment become easier), but (as of today) there can be relevant limitations depending on architecture/use case (e.g., tape use cases, storage/plugins/auth specifics, licensing/deployment models). That’s why Windows-based VBR v13 is still desired and valid in many customer environments — and that’s exactly what this article is about.
Important points before and during the v12 → v13 upgrade (Windows VBR)
1. Deprecated features
Check whether your environment depends on any of these features and decide early how you want to handle it. Details are in my blog post here.
- Restore point–based retention
- Reversed incremental backup mode
- Single-storage backup format
- Active Directory–based authentication for new Veeam Cloud Connect tenants
2. Discontinued Features
Check whether your environment depends on any of these features and decide early how you want to handle it. Details are in my blog post here.
- Universal Application-Item Recovery wizard (U-AIR)
- Restore by double-clicking VBK/VBM in Windows Explorer
- Burning Recovery Media to CD/DVD/BD
3. Network port changes
Veeam v13 introduces port changes (more than 200 changes). Compared to a previous configuration, a lot of ports have changed. In a greenfield installation, you typically won’t notice this much because you’re defining and requesting all required firewall openings anyway. During an upgrade, however, it becomes obvious immediately: existing firewall rules may have worked historically, but can cause issues after the upgrade. There’s no way around it — you need to review the details. There is also an overview per product/application (table with product names and URLs further down).
Many ports are replaced by the standardized ports 443/9443. The classic Data Mover port range 2500–3300 is also replaced in many cases by the new single port 6162. There are also a lot of other Port changes.
I also took the time to create a large table with all port changes, including markers (new ports, ports no longer used, changed ports), plus an overview of firewall ADD and DELETE policies, sorted by application/use case.
You can find it here: https://docs.google.com/spreadsheets/d/1vPEdJ1h6QgBBJYuUdLcVyDsO2KvaUEyCiuV3xITWZw0/edit?usp=sharing
Hope you like it, it was a lot of work and took some time (and no I tried AI, but it didn’t help and it did to many failures).
4. Check the VBR proxy role after a major upgrade
In a fresh installation, the VBR server often automatically gets the proxy role. In mid-sized/large environments this is often intentionally disabled/removed so that “Automatic Selection” does not use the backup server itself as a proxy and put too much load on the central backup server.
Upgrade pitfall: after a major upgrade, make sure to check whether VBR became an active proxy again—and if so, disable/remove it again as needed.
5. Certificates: v12 self-signed certificate without Basic Constraints
The v12 self-signed certificate does not include the “Basic Constraints” extension. For certain connections (vSphere, Nutanix AHV, Red Hat Virtualization, Oracle Linux Virtualization, …) this can cause the following error because the extension is required in v13:
The issuer certificate does not have a Basic Constraints extension. (Parameter ‚issuerCertificate‘) (System.ArgumentException)
The fix is straightforward: generate a new self-signed certificate for VBR that includes this extension. See KB:
https://www.veeam.com/kb4687
Main Menu –> Options –> Security –> Self-signed „Install…“ –> Generate a new certificate –> Complete the Wizard
After creating it, you need to reboot the VBR server. Then start the console and choose “Trust this server” → Yes.
6. Remote Components
If VBR components on remote servers (proxies/repos/gateways etc.) were not upgraded, jobs can fail after the upgrade. After upgrading VBR, verify this and trigger the upgrades manually if needed.
7. Wrong Fingerprint
If you see errors like “Unknown fingerprint” after the upgrade: upgrade the agent/plug-in to v13 first so the fingerprint matches the new server identity.
8. Using “File to Tape” as a second copy of backup data
Do you use “File to Tape” jobs to write files from a “Managed Server” to tape—maybe even backup files from a repository as a separate tape copy?
The second scenario is not best practice, and v13 includes an architectural change that no longer allows this approach. Managed servers can only be used for VM/image-level backups. In v13, a File to Tape job requires “Unstructured Data” as the source.
If you need an additional backup copy, configure Backup to Tape instead, or add the Windows server as a Windows Server.
IMPORTANT: In version 13.0.1 it is not possible to copy Veeam Plug-ins for Enterprise Applications to tape via Backup to Tape at the moment.
9. VHR – “Failed to open deployer Service Management Port”
This error can occur if the Veeam Installer/Deployer service on the Linux Hardened Repository is missing or could not be updated. During an upgrade the service may have been removed, and Veeam can’t reinstall it without Single-Use Credentials (one-time credentials).
To fix it you need the Single-Use Credentials for the Linux Hardened Repository:
- VBR Console zu Backup Infrastructure > Managed Servers
- Right click on Linux-Server: Properties –> Finish
- This triggers installation/upgrade of the missing Deployer and Transport services.
If the wizard can’t install the service, open a support case to install the service manually.
10. VHR – “Failed to open deployer Service Management Port”
„Failed to start Agent: Veeam data mover service installed on 192.168.1.42 is out of date“
This means the Transport/Data Mover service (veeamtransport) was not upgraded correctly.
- First, remove all remnants of the old transport service::
https://www.veeam.com/kb4298 - Then add the Linux server again under Managed Servers—using Single-Use Credentials.
- After reinstalling, verify that the transport service is running.
- Also make sure the new port 6162 is open between the Veeam server and the repository.
11. Unsupported Guest OS for VBR v13.0.1
Supported operating systems were revised. As a result, there are operating systems that were supported in v12 but are no longer supported in v13.
12. Unmanaged plug-ins are not converted to managed plug-ins during the upgrade
Unmanaged plug-ins cannot be automatically converted into managed plug-ins by Veeam. You need to take action yourself: uninstall the unmanaged plug-in from the target server and then onboard the workload via a managed-mode installation.
13. Veeam ONE shows VBR as “unhealthy” after upgrade
After upgrading VBR to 13.0.1, Veeam ONE may show the VBR server as “Unhealthy”.
Failed to validate Veeam ONE server certificate: Certificate chain contains errors during Veeam Analytic Service Installation.
When upgrading to Veeam ONE 13.0.1, a new internal certificate is created. Existing VBR servers still trust the old certificate. As a result, certificate validation fails when the Veeam Analytics Service tries to connect / install / initialize.
Fix: push the “new Veeam ONE certificate” to the monitored VBR servers:
1. Log on to the Veeam ONE server
2. Start the Veeam ONE Monitor Client
3. Click the gear icon (top right)
4. Select “Configuration”
5. Open the “Maintenance” tab
6. Select “Repair”
This distributes the new certificate to all monitored VBR servers and restarts the required services.
14. Backup collection exceeded the Maximum Timeout
In very large environments, the Veeam ONE data collection timeout (20 minutes) can be exceeded. See Veeam forum: https://forums.veeam.com/monitoring-f5/veeam-one-data-collection-timeout-increase-t101838.html
The timeout can be increased via a support case.
15. Veeam ONE 13: Port 2805 direction change
See also item “3. Network port changes”. You must implement all port changes — this applies here as well. Ports/connections changed.
In v12, the Veeam ONE server initiated the connection to VBR. In v13, the connection is initiated from VBR to Veeam ONE on port 2805.
Sources:
Upgrade Checklist, incl. deprecated/discontinued):
https://helpcenter.veeam.com/docs/vbr/userguide/upgrade_vbr_byb.html
Veeam KB – Veeam Backup & Replication Platform Migration Guide
https://veeam.com/kb4800
Migrations Support Registrierung:
https://go.veeam.com/vsa-conversion
Veeam forum thread to Deprecated and Discontinued Features:
https://forums.veeam.com/veeam-backup-replication-f2/deprecated-and-discontinued-features-for-our-2025-release-t97087.html
All Port Changes Documentation Links – sort by Product
