Legacy Backup to Azure Backup Migration for Server Estates

No — and no one can, honestly. Each product writes chains only its own software can read, and Azure Backup has no import for them. What we do instead is the parallel run: Azure Backup takes over new recovery points from the cutover date, the legacy product's jobs are disabled but the product stays installed on one host, licensed or in the vendor's read-only mode, and its chains expire on their original retention clock. The decommission schedule lists every chain with its expiry so the legacy licence lapses on a known date rather than being renewed out of fear. The sets that must outlive the product — legal holds, regulatory retention — are restored from the legacy side and backed up again into Azure as on-demand recovery points with retention of up to 99 years, one set at a time, on purpose.

They get a retirement date each, not a vague plan. The inventory records every tape set with what is on it and how long you must keep it. Sets whose retention has already expired are retired at cutover, subject to your data-destruction policy. Sets still inside retention either stay in the safe with a documented read path — the drive, the software version and the licence needed to read them, tested once during the project — or are restored and reprotected into Azure where the read path is fragile or the drive is going. MABS itself does not write to tape, so the library and its maintenance contract end with the last retained set; that date is on the schedule.

For Hyper-V and VMware virtual machines, SQL Server, Exchange, SharePoint and bare-metal recovery, yes: Microsoft Azure Backup Server is the component that talks to vCenter and the Hyper-V hosts, holds fast local recovery points on its disk pool and copies them to the vault. It runs on a domain-joined Windows Server 2019 or 2022 host you provide, physical or virtual, with local disk of roughly twice the protected data. An estate of standalone Windows servers that only needs files, folders and system state protected can skip it entirely and use the MARS agent straight to the vault, and servers already in Azure are protected from the vault with no server in the path. The design says which servers need which, and how many MABS hosts an estate of your size and site count needs.

A new Microsoft Azure Backup Server beside the old one, then the same parallel run as any other product. Microsoft supports no upgrade from DPM to MABS, and MABS V4 installs only on Windows Server 2019 or 2022, so the DPM 2016 host cannot be converted in place. Both the host's operating system and DPM 2016 itself run out of support in the same week — Windows Server 2016 on 12 January 2027 and System Center 2016 Data Protection Manager on 11 January 2027, per Microsoft's product lifecycle. If your calendar cannot close the migration before then, the DPM host is enrolled in Extended Security Updates through Azure Arc for the months it must keep running, at Microsoft's per-core charge on your subscription, and is retired on the date in the decommission schedule.

At the time of writing Microsoft's MABS V4 protection matrix lists Hyper-V hosts on Windows Server 2016, 2019 and 2022; VMware 6.5 through 8.0, backed up agentlessly through vCenter or the ESXi hosts; SQL Server 2017, 2019 and 2022; Exchange 2016 and 2019; SharePoint 2016 and 2019; Windows Server 2016, 2019 and 2022 for files, system state and bare metal; Windows 10 and 11 clients; and Azure Local. VMware virtual machines with pass-through disks, physical raw device mappings or existing snapshots, and the vSphere 8 DataSets feature, are not supported. Anything not on that list — a Windows Server 2025 host, an Exchange Server SE server, a SQL Server 2016 instance — is checked against Microsoft's current matrix during design and protected at VM level, through the MARS agent, or after an upgrade that is sequenced first.

Linux virtual machines on Hyper-V or VMware are protected at host level through Azure Backup Server, and Linux virtual machines in Azure through native Azure VM backup, with pre- and post-snapshot scripts where application consistency matters. The MARS agent is Windows-only, so a physical Linux server has no Azure Backup path of its own; it is flagged in the design with its options — virtualize it, protect it with a tool it supports, or keep it on the legacy product until its own migration — rather than left out of the inventory and discovered on the day it needs a restore.

Three layers, set in the design and verified in the drills. Soft delete is on by default for every new vault: a deleted backup is held for 14 days at no charge, extendable to 180, and can be undeleted. An immutable vault blocks any operation that would remove a recovery point before its retention ends; it starts in the reversible 'enabled' state and moves to 'locked' — permanent, irreversible — only on your written instruction. Multi-user authorization puts a Resource Guard in front of the dangerous operations, so stopping protection, shortening retention or disabling soft delete needs approval from an identity in a different subscription or tenant that the backup administrators do not hold. Backup data is encrypted at rest with Microsoft-managed keys or your own, and the MABS and MARS passphrases are escrowed to your key store, because a passphrase nobody can find is the same as no backup.

Class by class, in a table you sign. Azure Backup policies express daily, weekly, monthly and yearly retention — up to 9,999 days for daily points and 99 years for yearly ones — so a grandfather-father-son rotation translates directly and an odd rule, such as 'keep month-end forever', becomes a yearly or on-demand point with the retention it needs. Nothing is shortened without your written decision. Legal holds are listed individually: each one is either restored from the legacy product and reprotected into Azure with the retention the hold requires, or retained on the legacy side with a documented read path and an expiry, decided with your compliance owner. Locked immutability is available for the classes that must be provably undeletable.

We calculate it from your measured bandwidth and the protected volume rather than assuming, and the answer is in the design before anything is built. Where the WAN cannot seed the estate inside the calendar, the initial backups go to Azure on an Azure Data Box — 7.2 TB per Data Box Disk, 80 TB per Data Box — or through Azure Import/Export on your own disks, with Microsoft's logistics and charges and a lead time we order in week 1. Two constraints from Microsoft's documentation: Data Box does not ship across borders, and system state backups cannot be seeded offline. After seeding, daily traffic is the change rate, which is usually a fraction of the initial volume.

You do, on your own subscription, and the cost model tells you what to expect before you commit. Azure Backup bills a monthly fee per protected instance in size bands plus the backup storage actually consumed, priced by redundancy — geo-redundant costs more than locally redundant — and by how long retention keeps points around; soft delete is free for the default 14 days and billed beyond it, and an Azure Data Box or restore egress is charged when used. No dollar figures appear on this page because they are Microsoft's list prices and change; the model uses the prices on the day, states every assumption, and sits beside your legacy contract cost so the comparison is against what you really pay. Microsoft's meters are the bill of record.

The estimate on this page is $120 per protected server plus a $2,950 engagement fee — an estate of 50 servers works out to $8,950, one of 100 to $14,950 — confirmed as a written fixed quote after the scoping call, and per our standard terms you pay after you approve delivery. Above 500 servers, or where the design needs vaults in several regions or several MABS hosts across sites, we quote per estate because server count stops predicting the work. Under about 25 servers with no incumbent product to retire, the per-server setup page is the cheaper and more honest option, and we will say so on the call. Microsoft's charges and the legacy vendor's are separate from our fee in every case.

The setup page installs Azure Backup for a handful of servers and proves a restore; it does not inventory an incumbent product, map retention rules, size a MABS design for Hyper-V or VMware, run two products in parallel, retire tapes or schedule a licence to lapse. This page exists because an estate with a backup product to leave needs those things, and pricing them per server without the engagement fee would misprice the work. If your estate is small and has nothing to retire, use the setup page; if it has a contract expiring and a DPM host on Windows Server 2016, you are on the right page.

No, and we will not let the two blur. Backup answers whether you can get the data back; Azure Backup's tightest recovery-point frequency is every four hours for Azure VMs, twice a day from MABS and three times a day from the MARS agent, and a restore takes as long as a restore takes. Disaster recovery answers whether the business keeps running while you restore, which needs a continuously replicated copy that can boot in Azure in minutes — that is Azure Site Recovery, a separate implementation that complements backup. Many estates need both; the design says which servers need the second layer and why.

Your team, with the runbooks, or ours. The handover covers the daily report in Azure Business Continuity Center, what a failed-job alert means and what to do about it, how to restore each workload class, and the decommission schedule with its dates. Estates that want someone watching the jobs and running periodic restore tests use our Managed Backup and Backup-Restore service; those that want the whole Azure estate operated use Azure Resource Monitoring and Maintenance. Both are deliberately separate so the migration stands on its own and you choose who operates what.