Replacing Bv1: a six-step runbook

Step 1: take inventory

This Azure Resource Graph query lists every Bv1 VM in the subscriptions you can read. Second-generation sizes end in _v2 and are not included.

resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend size = tostring(properties.hardwareProfile.vmSize)
| where size matches regex @'(?i)^standard_b[0-9]+[a-z]*$'
| summarize vms = count() by size, location, subscriptionId
| order by vms desc

Add operating system, purpose and owner to the list. Some VMs will turn out to be candidates for decommissioning.

Step 2: evaluate the credit history

B VMs bank CPU credits while running below their baseline and spend them above it. Once credits run out, Azure throttles the VM to its baseline. Azure Monitor shows this through the “CPU Credits Remaining” and “CPU Credits Consumed” metrics.

Look at 30 days. VMs that regularly hit zero belong on a D size with fixed performance. VMs that barely touch their credits often fit a smaller target.

Step 3: choose the target size by memory

The options are Bsv2 with Intel processors, Basv2 with AMD EPYC and Bpsv2 with Arm64, the last one in practice only for Linux with Arm builds. Bsv2 and Basv2 support generation 1 and 2 and accelerated networking, but not ephemeral OS disks.

The names are misleading. A first-generation B2s has 2 vCPUs and 4 GiB, the B2s_v2 has 8 GiB. Mapping by memory:

• B2s (4 GiB): B2ls_v2 or B2als_v2, 30 percent baseline
• B2ms (8 GiB): B2s_v2 or B2as_v2, 40 percent baseline
• B4ms (16 GiB): B4s_v2 or B4as_v2, 40 percent baseline
• B1ls, B1s, B1ms: no single-vCPU successor. The smallest size is B2ts_v2 with 1 GiB and 20 percent. On Windows the second vCPU also raises the licence share in the VM price.

Step 4: decide the migration path

Bv1 sizes have a local temporary disk, the successors do not. For Linux, Azure allows resizing between both variants as long as neither swap nor application data lives on the temporary disk.

For Windows it is not allowed. Azure rejects the resize, stating that changing between resource disk and non-resource disk sizes is not permitted. The documented path:

• Move the page file from D: to C: and restart the VM.
• Take a snapshot of the OS disk.
• Create a new VM in the target size from the snapshot.

Step 5: follow-up work on the new VM

For Azure the new VM is a new resource. Check and set again:

• Backup protection. Recovery points of the old VM stay with the old backup item.
• Site Recovery replication.
• Extensions, the monitoring agent and data collection rule associations.
• Tags, VM-level role assignments, Defender settings.
• Network interface: after deleting the old VM, attach the existing NIC to the new one and the private IP address stays.
• Never run old and new VM on the network at the same time with the same system state. Identical computer name and domain identity otherwise cause sign-in failures.

Step 6: pilot, waves, clean-up

• Pilot with a non-critical Windows VM, including backup and a restore test.
• Plan waves by dependencies, not by size.
• Buy reservations or a savings plan only once the target state is measured.
• Delete old disks and snapshots after a fixed period.

More on this: Bv1 reservations: questions and answers for finance and FinOps

Division of work

The cost and migration analysis delivers steps 1 to 4 as a table per VM: inventory, credit evaluation, target size and migration path, plus the cost calculation. Steps 5 and 6 are carried out by your team or your service provider.