Migrating VBR from SQL Server to PostgreSQL on Windows
This migration is not a live database conversion.
Veeam handles it through a configuration backup and restore cycle. You back up the existing VBR configuration, then restore it in Migrate mode to a PostgreSQL instance. The server stays in place. Jobs, infrastructure, schedules, credentials, and settings come across. The change is under the hood: VBR stops using SQL Server and starts using PostgreSQL instead.
That matters now for two reasons. PostgreSQL became the default database for new VBR installs, and it is the only supported database option for the Linux Software Appliance. If the end goal is the appliance, or if the only reason SQL Server still exists in the environment is to satisfy VBR, this is the path that gets you off that dependency.
When you need to do it, and when you can wait
There is one case where this is not optional: moving to the Linux Software Appliance. That platform is PostgreSQL-only, so a Windows VBR server sitting on SQL Server has to be moved first.
Outside of that, the decision is more practical.
If there is a dedicated SQL Server in the environment doing nothing except hosting the VBR configuration database, the migration usually makes sense. That is one less SQL instance to patch, monitor, and justify.
If the server is still on the bundled SQL Express instance and staying on Windows, you can delay it. SQL Express is still workable while the database stays under the size limit. That said, the long-term direction is obvious enough that I would treat the migration as "not urgent yet," not "never needed."
What you need before starting
The first requirement is a PostgreSQL instance that VBR can reach.
On Windows, that can be a local PostgreSQL install or a remote one. If PostgreSQL is already in place, make sure the account you plan to use has enough rights to create a database during the migration. Also confirm the PostgreSQL side is using UTF-8 in the expected places, because Veeam expects that and does not do anything clever to work around bad defaults.
The second requirement is simpler but more important: the current VBR server needs to be healthy before you touch anything. Open the console. Make sure the existing configuration is clean. Do not start a database migration from an instance that is already behaving strangely and assume the new engine will somehow improve your luck.
And before the migration window starts, get the backup server fully idle. Not "mostly done." Idle. No backup jobs, no restore sessions, no tape activity hanging around in the background.
Step 1: stop and disable everything first
This is not glamorous, but it matters.
Stop anything currently running. Disable the schedules. Check restore activity too, not just backup jobs. If tape is in use, make sure that side is quiet as well. Then give the server a few minutes. Some sessions clean up after the visible part of the job is already done, and this is not the time to race them.
Step 2: take a fresh configuration backup
Do not rely on an older one just because it exists.
Go into the VBR configuration backup settings, confirm it is enabled and writing to a valid repository, and run Backup Now. You want the freshest possible snapshot of the current configuration before switching database engines.
If the configuration backup is encrypted, make sure the password is actually known and available before you move on. That becomes relevant in the restore wizard, and this is not the moment to discover nobody wrote it down.
Step 3: use the restore wizard in Migrate mode
This is the fork in the road that matters.
When you open the Configuration Restore wizard, do not choose Restore. Choose Migrate. The normal restore path does not switch database engines. Migrate is the option that tells Veeam to take the configuration backup and rehome it onto PostgreSQL.
Point the wizard at the backup you just created. Enter the PostgreSQL server, port, target database name, and account credentials. If the database does not exist yet, that is fine. Veeam can create it during the process. Local PostgreSQL on the VBR server is fine too, in which case localhost is usually the right answer rather than overthinking the hostname.
Once you start it, let it run.
Do not close the console. Do not restart services manually because something looks quiet for a minute. This is one of those workflows where impatience buys you extra work.
If the migration gets interrupted, the fix is not guesswork. Reopen the console and run the wizard again from the beginning with the same configuration backup.
Step 4: handle Enterprise Manager key activation if it applies
This only matters in a narrower set of environments, but it matters a lot there.
If Enterprise Manager is in the picture and encrypted restore workflows depend on it, the key association can break when the configuration database moves. The VBR server still exists from EM’s point of view, but the key relationship is no longer where it was.
The fix is in Enterprise Manager’s key management area: reactivate the keyset there before somebody discovers the problem during an encrypted restore. If Enterprise Manager is not being used, or encrypted restore through EM is not part of the environment, skip this and keep moving.
Step 5: treat validation as part of the migration, not cleanup
Once VBR reconnects on PostgreSQL, the job is not done.
First, re-check configuration backup and make sure it can run successfully against the new database. That is the fastest confirmation that VBR is not just open, but healthy enough to protect itself again.
Then walk the infrastructure view. Proxies, repositories, managed servers, all of it. If something looks off, rescan it before assuming the migration broke the world. Internal certificates can be regenerated during the process, and some components simply need their stored trust refreshed.
There is also a behavior that surprises people the first time: repositories on the VBR server itself may look empty immediately after the move. That does not mean the backup files disappeared. Re-add the repository at the same path and let Veeam rescan it. The files are still there.
After the infrastructure looks normal, re-enable jobs. Then run one. End to end. Before handing the server back to its normal schedule.
PostgreSQL tuning matters if you built PostgreSQL yourself
If PostgreSQL was installed manually rather than laid down by Veeam in a supported default way, do not assume the stock config is a good match for VBR.
That is where the PostgreSQL tuning command comes in. Veeam provides a PowerShell cmdlet that generates recommended settings for the hardware the server is actually using. That output is the thing to review and apply, not random example values from the internet. If Veeam installed and configured PostgreSQL for you, this is usually already handled. If you built the PostgreSQL side yourself, I would not skip it.
Enterprise Manager migration is separate
One more thing that is easy to misunderstand: migrating VBR’s database does not automatically mean Enterprise Manager has to move at the same time.
In v13, they do not have to share the same engine. VBR can move to PostgreSQL while Enterprise Manager remains on SQL Server. If Enterprise Manager is going to be migrated too, that is its own procedure.
And if both an Enterprise Manager upgrade and an EM database migration are planned, do them in the right order: upgrade first, then move the engine. Trying to collapse those into one event is how simple projects become irritating ones.
The usual problems are predictable
Most of the common failure cases are not mysterious.
If PostgreSQL rejects the connection during the wizard, check the simple things first: service state, port, connection rules, and whether using localhost locally works better than the hostname you thought was cleaner.
If local repositories look empty afterward, that is usually just the known rescan behavior.
If encrypted restores through Enterprise Manager fail, go back to the key activation step.
If the migration stops midway, assume either activity was still running or the database connection dropped, then rerun the restore wizard from the beginning instead of improvising.
If infrastructure components show warnings, rescan them and refresh the trust relationship.
And if PostgreSQL itself was quietly disabled on the box from a prior install, start there before you lose time blaming Veeam.
Final thoughts
The actual engine migration is usually simpler than people expect.
The bigger risk is doing it casually.
I would treat this as a short controlled change: get the server fully idle, take a fresh encrypted configuration backup, use the wizard in Migrate mode, validate infrastructure and configuration backup afterward, and run a real job before calling it done.
That is the difference between "the database engine changed" and "the VBR server is actually healthy on PostgreSQL now."
