Skip to main content

Veeam v13: Upgrading from v12 on Windows -- Complete Guide

  • March 12, 2026
  • 7 comments
  • 2326 views

eblack
Forum|alt.badge.img+2

 

V13 upgrades cleanly when the VBR server is already cleaned up first. Most delays come from legacy backup-copy jobs, old agent deployments, nested repositories, removed job settings, or unsupported infrastructure that was still tolerated before the upgrade. Check the starting build first, clear blockers before mounting the ISO, and validate backup plus restore behavior afterward.

 

1. Supported starting point

Direct to v13.0.1 only from:

  • v12.3.1 build 12.3.1.1139 or later
  • v12.3.2

If the server is on an earlier v12.3.x build:

  • patch to v12.3.1 build 1139 first

If the server is on v12.2.x or older:

  • stage through v12.3.1 first

2. Installer blockers to clear before the ISO is mounted

These stop the upgrade:

  • backup metadata not upgraded to v12 format
  • legacy backup-copy jobs
  • Veeam Agent for Windows before v6 using LocalDB
  • nested repository paths
  • UNC path still configured in Export VBK
  • File Copy jobs targeting the backup server
  • jobs still using "Transform previous chains into rollbacks"

Do not wait for the installer to discover these during the maintenance window.

3. Platform checks before the window

Verify these before starting:

  • vSphere 7.0 or later
  • Hyper-V on Windows Server 2016 or later
  • SQL Server 2016 or later for the configuration database
  • supported Linux distributions only

Dropped platforms include:

  • vSphere 6.x
  • Hyper-V on Windows Server 2012 / 2012 R2
  • SQL Server 2012 / 2014
  • older Linux combinations such as RHEL 7 and Debian 10

Unsupported managed servers may not block the upgrade. They often show up afterward as broken jobs or unhealthy components.

4. Database and PowerShell checks

Database

  • PostgreSQL 17.6 is bundled for new v13 installs
  • existing SQL Server configuration database upgrades in place
  • if v12 used bundled PostgreSQL 15, v13 installs PostgreSQL 17.6 beside it
  • PostgreSQL 15 can be removed later after validation

PowerShell

  • Veeam PowerShell in v13 requires PowerShell 7
  • Windows PowerShell 5.x will not load the module
  • update scripts and scheduled tasks from powershell.exe to pwsh.exe

5. Pre-upgrade checklist

Before the upgrade:

  • confirm source version
  • run configuration backup and copy the .bco file off the server
  • snapshot the backup server VM
  • stop jobs, restore sessions, and SureBackup sessions
  • disable schedules for the maintenance window
  • clear installer blockers
  • verify managed servers and proxies are still supported
  • verify free disk space
  • confirm port 443 is not already in use
  • install PowerShell 7 if automation depends on Veeam PowerShell

6. Upgrade order

If the wider stack is in use:

  1. Veeam Backup for Microsoft 365
  2. Veeam ONE
  3. Enterprise Manager
  4. VBR server
  5. Remote components

Notes:

  • Veeam ONE v13 can monitor v12 environments
  • Enterprise Manager must be upgraded before VBR
  • use Veeam ONE 13.0.1, not 13.0.0

7. Checks after the upgrade

Do not stop at console login.

Run these checks:

  • confirm version under Help > About
  • run one backup job end to end
  • re-trust managed servers if needed
  • refresh hypervisor inventory
  • perform a test restore
  • run Security and Compliance Analyzer
  • test automation under PowerShell 7

8. Known issues

VeeamBackupRESTSvc timeout

  • common first-start issue
  • raise ServicesPipeTimeout to 300000
  • registry path: HKLM\SYSTEM\CurrentControlSet\Control
  • reboot after change

Console connection delay

  • wait a few minutes after upgrade
  • if still failing, check that Veeam services are running
  • if the error looks like access denied, check remote console version

Port 443 conflict

  • v13 REST service needs port 443
  • if another application owns it, the service will not start

File Copy jobs on multi-NIC servers

  • known v13.0.1 issue
  • symptom: Connection forwarder not registered
  • workaround: disconnect unused NIC or set preferred network in Network Traffic Rules

PowerShell scripts

  • scripts still using Windows PowerShell 5.x will fail
  • move them to PowerShell 7

9. Closeout

That is the upgrade in practical terms:

  • verify the starting build
  • clear blockers first
  • verify surrounding platform support
  • upgrade in the correct order
  • prove backup and restore behavior afterward

 

7 comments

Chris.Childerhose
Forum|alt.badge.img+21

Great guide Eric as it is always good to know the upgrade path to v13.


  • New Here
  • March 13, 2026

Great article, but my experience did not reflect the statement “If v12 used the bundled PostgreSQL 15 instance, v13 installs PostgreSQL 17.6 alongside it; PostgreSQL 15 is left installed and unused, and can be removed after confirming v13 is healthy”.

On a Windows 2022 VBR server (using bundled PostGresSQL 15), after upgrade from v12 to v13, my PostGres version remained 15, no version 17 was installed.


eblack
Forum|alt.badge.img+2
  • Author
  • Influencer
  • March 13, 2026

Great article, but my experience did not reflect the statement “If v12 used the bundled PostgreSQL 15 instance, v13 installs PostgreSQL 17.6 alongside it; PostgreSQL 15 is left installed and unused, and can be removed after confirming v13 is healthy”.

On a Windows 2022 VBR server (using bundled PostGresSQL 15), after upgrade from v12 to v13, my PostGres version remained 15, no version 17 was installed.

Thanks for the feedback, TechShe. Really appreciate you sharing your real world experience. That PostgreSQL behavior is worth digging into. A couple of questions to help narrow it down: what was your exact v12.3.x build before upgrading, and was the PostgreSQL 15 instance at the default bundled install path? It's possible the upgrade behavior varies depending on build or configuration. I'll verify against the official Veeam docs and update the article if needed.


kciolek
Forum|alt.badge.img+4
  • Influencer
  • March 13, 2026

great article! thanks for sharing the upgrade process


  • Comes here often
  • March 26, 2026

wow, thanks for this great article.

Am I understanding this correctly: that I can upgrade from version 12.3.2.4465 with SQL Server to PostgreSQL version 13 in a single step?
I thought it was necessary to upgrade to PostgreSQL first and then upgrade to v13. 


eblack
Forum|alt.badge.img+2
  • Author
  • Influencer
  • March 26, 2026

wow, thanks for this great article.

Am I understanding this correctly: that I can upgrade from version 12.3.2.4465 with SQL Server to PostgreSQL version 13 in a single step?
I thought it was necessary to upgrade to PostgreSQL first and then upgrade to v13. 


Hey Jan, thanks for reading.

Yes, you’re reading it correctly. Version 12.3.2 qualifies for a direct in place upgrade to v13.0.1. No intermediate steps. KB4763 confirms 12.3.1 build 1139 or later and 12.3.2 are both supported source versions.


On the database side, you do not need to migrate from SQL Server to PostgreSQL as part of the upgrade. The installer connects to your existing SQL Server config DB and upgrades it in place. PostgreSQL 17.6 is the default for new v13 installs, but existing SQL Server deployments (2016 through 2025) are fully supported.
The migration to PostgreSQL is a separate optional process you can do later if you choose to.
So your path is v12.3.2 straight to v13.0.1, keeping SQL Server. One step.
Just make sure you work through the pre upgrade checklist before mounting the ISO, especially the hard blockers in Section 3. Most post upgrade problems trace back to a skipped step there.

 


  • Comes here often
  • April 24, 2026

Great article, but my experience did not reflect the statement “If v12 used the bundled PostgreSQL 15 instance, v13 installs PostgreSQL 17.6 alongside it; PostgreSQL 15 is left installed and unused, and can be removed after confirming v13 is healthy”.

On a Windows 2022 VBR server (using bundled PostGresSQL 15), after upgrade from v12 to v13, my PostGres version remained 15, no version 17 was installed.

Thanks for the feedback, TechShe. Really appreciate you sharing your real world experience. That PostgreSQL behavior is worth digging into. A couple of questions to help narrow it down: what was your exact v12.3.x build before upgrading, and was the PostgreSQL 15 instance at the default bundled install path? It's possible the upgrade behavior varies depending on build or configuration. I'll verify against the official Veeam docs and update the article if needed.

seems I'm having the same issue. I don't see PGSQL 17, installation at standard paths
old VBR v. 12.3.2.3617
new VBR v. 13.0.1.2067