Dynamic Memory Throttling Across Heterogeneous Hyper-V Host Generations

Short answer: the migration you describe cannot happen

The premise contains a category error that resolves most of the uncertainty: Hyper-V does not support Quick Migration or Live Migration of a VM across a Generation 1 ↔ Generation 2 boundary. VM generation is a property of the VM configuration, not of the host. A Generation 2 VM can only run on a host that supports Generation 2 (Windows Server 2012 R2 and later), and it remains Generation 2 wherever it goes. There is no "Gen 1 host memory management layer" that a Gen 2 VM's UEFI firmware must reconcile with — the host's hypervisor presents the firmware the VM was created with, and migration is blocked if the target cannot provide it.

So under no conditions does Dynamic Memory throttling "defer or reset" after a Gen 1-to-Gen 2 Quick Migration, because that migration is refused before memory state is ever transferred.

What actually happens in the supported cases

Same generation, different host versions (e.g., 2012 R2 → 2016/2019/2022): This is the realistic mixed-cluster scenario, and it is supported with processor compatibility mode enabled. Dynamic Memory configuration — startup RAM, minimum RAM, maximum RAM, memory buffer percentage, and memory weight — travels with the VM configuration and is preserved. The current allocation is re-evaluated by the Dynamic Memory balancer on the target host; the guest's integration services continue reporting pressure, so throttling resumes rather than restarting from startup RAM. Expect a brief rebalancing period (seconds) as the target host's balancer establishes pressure readings, not a full reset.

Cross-generation movement: The only path is export/import or a conversion workflow (effectively creating a new VM). In that case the Dynamic Memory values come from whatever configuration the new VM is created with — they are not "preserved" through migration because no migration occurred.

Does UEFI firmware version matter?

No — not for memory reservation continuity. The UEFI firmware in a Generation 2 VM governs boot behavior, Secure Boot, and device enumeration. Memory reservation, ballooning, and throttling are negotiated between the hypervisor's Dynamic Memory components and the guest's integration services (the Dynamic Memory VSC/driver inside the guest OS). The guest OS version and its integration services version are what matter for throttling behavior, not the UEFI shell revision.

Version constraints worth checking

Where hosts run different Hyper-V versions, verify that the VM's configured minimum/startup/maximum RAM values are valid on the older host if you may migrate back. Configuration version also gates features: a VM upgraded to a newer configuration version cannot migrate to an older host at all. Check with:

Get-VM | Format-List Name, Generation, Version, MemoryStartup, MemoryMinimum, MemoryMaximum
Get-VMHost | Format-List Name, Version

After a supported Quick Migration, confirm continuity by comparing the Hyper-V Dynamic Memory VM\Guest Visible Physical Memory and balancer pressure counters immediately before and after the move; a continuous trend (rather than a jump back to startup RAM) confirms throttling state carried over.

Interoperability matrices

Microsoft's published guidance covers supported host-version pairs for Live/Quick Migration and the VM configuration versions each host accepts — that is the matrix that applies here, since generation is fixed per VM. If you are seeing an actual migration failure or a memory reset in a same-generation, mixed-version cluster, the one diagnostic detail that would change this recommendation is the exact error or the VM's configuration version (Get-VM | Select Version) on both hosts.