We use a few cookies to run the site and understand how it's used. No tracking. No ads. View our cookie policy

Migrate Veeam Backup & Replication to a New Windows Server

Home  ➔  Guides   ➔   Backups   ➔   Migrate Veeam Backup & Replication to a New Windows Server

Outcome first: keep every job, key, and schedule intact

This guide shows you how to move Veeam Backup & Replication to a new Windows server without losing configuration, credentials, or restore points. You will use an encrypted configuration backup, restore it on the new server, then verify and resume protection. Calm, predictable, safe.

What you will get by the end

• A clean handover to a new Veeam server with all jobs and repositories preserved.

• Stored credentials and encryption keys carried over via an encrypted config backup.

• Repositories re-discovered and restore points remapped without rework.

• A quick validation restore so you know recovery is ready before you re-enable schedules.

• A simple fallback plan if storage paths or permissions differ on the new host.

Deployment choices

All-in-one

Single VBR server with local repositories. Simple, fast, minimal moving parts. Best for small estates or where the repository paths can match on the new host.

Distributed

Separate VBR server, proxies, WAN accelerators, and remote repositories. Scale and flexibility. Confirm each component is reachable and re-authenticated after the restore. Keep names, IPs, and paths consistent where possible.

Prerequisites

• Old VBR server: all jobs disabled and idle.

• Encrypted configuration backup created and accessible.

• New Windows server sized per Veeam guidance, with VBR installed (same or newer build).

• Matching repository paths or a plan to remap and rescan.

• Admin rights on both servers; service account credentials to hand.

• Maintenance window agreed; users informed.

Install / Core setup

1) On the old server, disable all backup and copy job schedules. Wait for running tasks to finish.

2) Export any custom registry settings you rely on for tuning.

3) Create a Veeam Configuration Backup and enable encryption (set a strong password). Run “Backup now”.

[Screenshot: Configuration Backup settings with “Enable backup file encryption” ticked — save as veeam-configuration-backup-settings.png]

4) If replacing storage, copy backup files to the new server. Keep drive letters and folder paths the same where possible.

5) On the new server, install Veeam Backup & Replication. Use default local database (PostgreSQL) or your SQL instance. Do not create jobs.

Immutable repository (Linux hardened)

Why it matters

Ransomware often targets backups. A hardened Linux repository with immutability blocks alteration and deletion, even with stolen admin credentials.

Prepare Linux

Deploy a supported Linux distro. Format XFS with reflink. Mount to a stable path (for example /repo01). Lock down SSH and sudo.

Add as Managed Server

Add the Linux host in Veeam using single-use credentials. Veeam will drop and secure the transport service accounts.

Create Hardened Repo

Create a new repository on the mount path. Enable immutability for an agreed window (for example 14–30 days). Allow fast cloning. Size concurrency tasks sensibly. Keep 10–20% free space headroom.

[Screenshot: New Hardened Repository wizard showing immutability days - save as veeam-hardened-repo-immutability.png]

Proxies & WAN Accelerators

Proxies

Place close to source data. As a rule of thumb, 1–2 tasks per CPU core. Choose the best transport mode per platform (hot-add, NBD, or direct SAN).

WAN Accelerators

Use for inter-site copy jobs. Size the global cache generously on both source and target. Open required ports. Avoid double encryption on slow links.

Add your hypervisors

VMware vSphere

Add vCenter rather than standalone hosts so inventory follows vMotions and DRS. Use a dedicated service account with least privilege.

Microsoft Hyper-V

Add hosts, clusters, or SCVMM. Confirm VSS integration and permissions. Check mobility for CSVs.

Proxmox VE

Protect via agents for now. Use application-aware processing on Windows and pre/post scripts on Linux where needed.

Jobs that protect you

Backup Jobs

Select objects. Choose hardened repository or approved storage. Set retention and GFS. Enable application-aware processing. Schedule outside production hours.

Backup Copy Jobs

Copy from backups, not VMs. Use periodic or immediate modes. Send to offsite or immutable targets. Pair with WAN accelerators for narrow links.

Backups talk to VMs. Copy Jobs talk to backups.

Step-by-step migration

1) Old server: disable schedules and confirm no active tasks.

2) Old server: run an encrypted Configuration Backup. Record the password. Note the .bco location.

[Screenshot: Successful config backup job session - save as veeam-config-backup-session.png]

3) Optional: copy backup chains to the new repository paths. Keep letters and folders identical if you can.

4) New server: install VBR and open the console.

5) New server: Menu > Configuration Backup > Restore > choose “Migrate”. Browse to your .bco file. Enter the encryption password. Start restore.

[Screenshot: Configuration Restore wizard with “Migrate” selected - save as veeam-config-restore-migrate.png]

6) After restore, let Veeam rescan infrastructure. Re-add repositories if paths differ. Remap jobs if prompted.

7) Import any custom registry settings and scripts. Re-enter single-use credentials for hardened repos.

8) Test a restore: file-level or a small VM to a sandbox. Confirm you can read the existing chain.

9) Re-enable schedules. Monitor the first cycles. Then decommission the old server.

Recovery mindset

Test what you plan to use. Do an Instant VM Recovery dry-run. Prove file-level recovery on a key workload. Schedule monthly drills so everyone knows the path back to green.

Frequently solved problems

• Jobs show missing repository after restore: re-add the repository with the exact path. Use Rescan, then Remap if asked.

• Credentials missing: the config backup was not encrypted. Recreate with encryption and repeat the restore.

• ReFS copy consumes full size: plan space or use Backup Move after migration.

• Hardened repo prompts for password: re-enter single-use credentials by design.

• Slow first runs: warm the proxy cache. Check concurrent tasks and repository limits.

Quick reference checklists

Sizing

• Proxy tasks ≈ CPU cores × 1–2. Reserve headroom for OS and AV.

• Repository IOPS for your daily change rate. Keep 10–20% free space.

• WAN cache sized for your copy job footprint.

Job design

• Group workloads by RTO/RPO. Apply app-aware where needed. Use GFS for monthlies. Copy offsite or to immutable storage.

Security

• Immutability on. Offsite copy enabled. Least-privilege accounts. Encrypted config backup scheduled and tested.