Veeam v13: Upgrading from v12 on Windows

Veeam Backup and Replication v13 is a significant release. The jump from v12.3 is straightforward if your environment is clean, but the installer runs a hard configuration check before it allows the upgrade to proceed -- and it stops cold if it finds any of several specific conditions. Some of those conditions have been sitting in environments for years: legacy backup copy job formats, old per-machine metadata, older agent installs with LocalDB, jobs using a removed retention option. You have to fix them first.

This article covers the complete upgrade process on Windows from v12.3.1 to v13.0.1: what the hard blockers actually are (sourced directly from the official Veeam upgrade checklist), what is deprecated vs. discontinued, platform changes, disk space requirements, component upgrade order, the wizard walkthrough, and post-upgrade validation. The known issues section covers the real problems that surface immediately after upgrade and how to resolve them.

1. Upgrade vs. Migration: Know the Difference

Veeam uses these two terms with specific meanings for v13.

If your goal is the Linux Software Appliance, you cannot in-place upgrade to it. You must do a fresh appliance install and restore a configuration backup. That process is covered separately. This guide is the Windows-to-Windows path only.

2. Supported Upgrade Paths

A direct in-place upgrade to v13.0.1 requires v12.3.1 build 12.3.1.1139 or later as the source. This is confirmed by the official Veeam upgrade documentation and Veeam KB4763. If you are below that build, you must reach it first.

3. Upgrade Blockers: Hard Stops

Step 6 of the upgrade wizard -- the Configuration Check -- scans for these conditions. Any hard blocker shows as a red item and the wizard will not continue. Exit, fix the condition, and relaunch the installer. The following list comes directly from the official Veeam upgrade checklist.

Checking Legacy Jobs via PowerShell

4. Deprecated Features

These features continue to function on existing jobs that already use them. They cannot be selected for new jobs. All will be fully removed in v14.

5. Platform and OS Changes

v13 drops support for several platforms. Managed servers running on unsupported OS versions are non-blocking warnings during the upgrade but cause immediate job failures afterward.

Database: PostgreSQL and SQL Server

PostgreSQL 17.6 is bundled and is the default for new v13 installations. SQL Server 2016 through 2025 remains supported. If you are upgrading from v12 with an existing SQL Server configuration database, the installer connects to it and upgrades it in place -- you do not need to migrate to PostgreSQL as part of this upgrade. That migration is optional and documented separately. Note that Veeam has stated SQL Server support will eventually be discontinued post-v13.

If your v12 install used the bundled PostgreSQL 15 instance, v13 installs PostgreSQL 17.6 alongside it and redirects the configuration database to the new instance. PostgreSQL 15 is left installed but unused and can be removed after confirming v13 is healthy.

PowerShell: v7 Now Required

The Veeam PowerShell module in v13 requires PowerShell 7. Windows PowerShell 5.x will no longer load the Veeam module. If you have automation scripts, scheduled tasks, or monitoring integrations using Veeam PowerShell cmdlets under Windows PowerShell 5.x, they will fail after upgrade. Install PowerShell 7 on the backup server and update your script launchers to use pwsh.exe instead of powershell.exe before upgrading.

6. Pre-Upgrade Checklist

• Confirm installed version is v12.3.1 build 12.3.1.1139 or later (Help > About)
• Run a Veeam Configuration Backup and store the .bco file off the backup server
• Take a snapshot of the backup server VM if virtualized -- your rollback option
• Stop all running backup jobs, restore sessions, and SureBackup sessions
• Disable all scheduled jobs to prevent them starting during the upgrade window
• Resolve all hard blockers from Section 3: legacy metadata, legacy copy jobs, old agents with LocalDB, nested repos, UNC export path, File Copy job destinations, rollback-mode jobs
• Identify jobs still using restore-point-based retention and convert to day-based
• Check managed servers and proxies for unsupported OS versions
• Verify vSphere is at 7.0 or later if backing up VMware workloads
• Verify SQL Server is 2016 or later if using SQL Server for the configuration database
• Check all SOBR performance extents have matching immutability settings
• If Veeam Backup for Microsoft 365 is co-installed, upgrade it first
• Install PowerShell 7 on the backup server if you use Veeam PowerShell automation
• Verify disk space: at minimum 55.5 GB -- approximately 50.5 GB (3x ISO size) in the install path, plus 5 GB on the system volume for database operations. The installer calculates the exact minimum dynamically during the configuration check.
• Check for any application already bound to port 443 on the backup server -- v13's REST service requires it
• Download the v13.0.1 ISO: VeeamBackup&Replication_13.0.1.180_20251101.iso (~16 GB). Check for patch releases newer than the base 13.0.1.180 build.

7. Component Upgrade Order

If your environment includes components beyond the backup server, upgrade in this sequence.

8. Running the In-Place Upgrade

9. Post-Upgrade Validation

• Console connects and Help > About shows 13.0.1.x
• All existing backup jobs are listed with correct last-run status
• Run at least one backup job end to end and confirm it completes successfully
• Backup Infrastructure: all repositories show correct status and capacity
• Re-trust managed servers flagged as untrusted: right-click each and select Trust
• Verify managed proxies show updated component versions
• Verify hypervisor connections are intact and current inventory is visible
• Confirm all credentials are present in the Credentials Manager
• Perform a test restore to validate recovery capability
• If Veeam ONE is in use, confirm it connects to the v13 server and generates reports
• Run the Security and Compliance Analyzer under Configuration in the console
• Test any PowerShell automation scripts under PowerShell 7

Re-Trust Managed Servers

After upgrade, proxies, repositories, and mount servers may show as untrusted on first connect. This is expected behavior. Go to Backup Infrastructure, right-click each server with a warning icon, and select Trust. Jobs routing through untrusted servers will fail until this is done.

10. Known Issues and Fixes

VeeamBackupRESTSvc Times Out on First Start

The most widely reported post-upgrade issue. VeeamBackupRESTSvc times out on first start due to heavy initialization load. Windows kills the service before it finishes loading. Other dependent Veeam services may also fail to start as a result. The fix is to increase the Windows service startup timeout:

Console Cannot Connect After Upgrade

If the console fails to connect immediately after upgrade, wait 5 to 10 minutes and retry -- services may still be completing initialization. If the error persists past 10 minutes, check Windows Services and confirm all Veeam services are Running. Apply the ServicesPipeTimeout fix above if services are still stuck in Starting.

A separate registry access error has also been reported: "Access to the registry key 'HKLM\SOFTWARE\Veeam\...\Console' is denied." This indicates a version mismatch between the remote console and the upgraded server. Update the remote console to v13.0.1.

Port 443 Conflict Blocks the REST Service

v13's REST API and Web UI require port 443. If another application is already bound to that port on the backup server, VeeamBackupRESTSvc will fail to bind and will not start. Check for conflicts before upgrading:

File Copy Jobs Fail with NIC Selection Bug

A confirmed bug in v13.0.1 affects File Copy jobs on backup servers with multiple NICs. v13 changed the internal data mover connection model and the service may attempt to use a secondary NIC instead of the primary production interface, causing File Copy jobs to fail with a "Connection forwarder not registered" error -- even when Backup Copy jobs to the same target succeed. The fix is to either disconnect the unused secondary NIC or configure a preferred network under Configuration > Network Traffic Rules in the console.

PowerShell Automation Breaks Under Windows PowerShell 5.x

The Veeam PowerShell module requires PowerShell 7 in v13. Scripts, scheduled tasks, and monitoring integrations running under powershell.exe (Windows PowerShell 5.x) will fail with a module load error after upgrade. Update launchers to use pwsh.exe (PowerShell 7).

PostgreSQL 15 Left Installed After Upgrade

If v12 was using the bundled PostgreSQL 15 instance, v13 installs PostgreSQL 17.6 and points the configuration database at the new instance. PostgreSQL 15 is left installed but unused. Uninstall it from Programs and Features after confirming v13 is operating correctly.

If the Upgrade Fails Completely