Home / Nerdio Academy – Enterprise / Blogs - Enterprise / How to Automatically Migrate From WVD Classic (non-ARM) to WVD ARM

How to Automatically Migrate From WVD Classic (non-ARM) to WVD ARM

Bas van Kaam
Bas van KaamField CTO - EMEA
0 comments
Enterprise
November 03, 2020Articles

Throughout the last couple of months we have been getting a lot of questions on how to migrate existing Classic, Non-ARM (a.k.a. Fall or v1) WVD deployments to the new WVD ARM model (a.k.a. Spring or v2). Many of our customers have active WVD Tenants (part of old model), which they want to keep using and manage with Nerdio without needing to rebuild from scratch, reassign users, and so on. Well, with Manager for WVD you can; fully automated and broken down into a two-step migration process.

As you may or may not know, Microsoft is working on something similar and has been for months. The public preview is to be expected in January 2021. More information can be found here.

 

Associate Existing WVD Deployments

First of all, I want to highlight that when Nerdio Manager for WVD is installed any existing WVD deployments can be onboarded and managed with Manager for WVD within a few mouse-clicks. All you need to do is link the Resource Group and Network (vNet) where your existing WVD machines are deployed into -- that’s it. Next, you do a refresh on the Tenants or Workspaces page and you’ll see your virtual machines appear.

The only thing left is to “associate” these machines with Manager for WVD and you are done.

The above applies to both existing Tenants as well as Workspaces – old and new.

Since Tenants (and Workspaces) do not natively support autoscaling, at least not in the advanced way that Nerdio offers, we also built in the ability to auto-convert your static hostpool into a dynamic hostpool (within seconds), meaning it will be able to leverage the unique and advanced autoscaling and (auto) recovery options as part of Nerdio Manager for WVD.

This can be done before or after you migrate your Tenants over to Workspaces.

 

How to Migrate

It’s a two-step process. Each step can be performed separately or at the same time – all fully automated, of course. See the image below as well.

Step one consists of:

  • Selecting the hostpool you want to migrate.
  • Choosing a destination Workspace.
  • Filling in a new hostpool name. Existing name is filled in by default.
  • Choosing what to do with existing user assignments; copy them over, move, or don’t copy or move them at all.

This is how the hostpool metadata is migrated from old to new, non-disruptive, and fast.

 

Phase two consists of:

  • Migrating existing host VMs along with all hostpool settings.
  • Selecting how many VMs are allowed to be processed (migrated) at the same time, including the allowed number of failures before aborting the migration process.
  • Setting a schedule; select your time-zone, followed by a time window. If not scheduled, migration will begin immediately.
  • Informing (message) any active users/sessions on the VM’s being migrated so that they can save their work and log off timely.

NMW Migrate Option

As you can see in the above example, all this is straightforward to configure and execute.

 

The Two-Step Advantage

Like I mentioned, the above steps can be performed in parallel. Though, being able to handle these tasks separately has some advantages. Allow me to explain.

One option is to migrate your assignments and virtual machines at the same time, scheduled at will, etc. However, if the migration of your virtual machine fails, whatever the reason may be, the VMs won’t be reverted back to their original state.

Even though this almost never happens, it might sound risky.

Well, yes and no.

Yes, because if they get “stuck” for whatever reason, you’ll have to rebuild your VMs (or in some cases, retry). No, because the rebuilding of your VMs can be done fully automated. Next to that, during step one you already created a new hostpool including your user assignments.

Re-building the virtual machines can be done via our autoscaling engine using the same image. 20 minutes later, give or take, you’ll have your VMs back up and running with a fresh install.

So, you see, the risk of a failed migration is minimal to none.

Of course, if you would like to rebuild your virtual machines with a different (new or updated) image, that’s possible as well.

 

TIP: Once migrated, make sure to use the correct URL when using the web (HTML5) client.

 

Old non-ARM URL

New ARM URL

 

The above is just one example of how Nerdio makes managing, maintaining, and optimizing new and existing WVD deployments as easy, efficient, and effective as possible without any deep technical knowledge of the underlying Azure platform, PowerShell, or otherwise.

 

Bas van Kaam

Nerdio Field CTO, EMEA/UK