What to Expect Before, During, and Afterwards from the Self-Service Migration of a Horizon Cloud on Microsoft Azure Deployment

This page's sections describe what to expect before, during, and afterwards from the self-service migration of a Horizon Cloud on Microsoft Azure deployment to your Horizon Cloud Service - next-gen environment.

The modern architecture of Horizon Cloud Service - next-gen means that some experiences you are currently familiar with will be different after the migration.

Use this page's information along with the information in Before Starting the Self-Service Migration - Prerequisites and Key Things to Think About.

Migration Workflow

The following illustration depicts the overall migration process.

The commit phase is where the scheduled maintenance window takes place, and the system builds out the resources that it cannot pre-build ahead of time.

Workflow diagram of the migration workflow

Before Migration - What to Expect

VMware will send you an email that notifies you that your Horizon Cloud on Microsoft Azure deployment is eligible for the self-service migration process.

You onboard to your next-gen environment that same as if you had no first-gen presence, and configure the AD domain and identity provider in the next-gen environment.

Note: The AD domains that you configure in the next-gen environment must match the ones you have configured for the first-gen pods in your first-gen environment.

Then when VMware enables your onboarded next-gen environment for the migration UI, you will be able to use that UI to schedule the migration.

You will need to ensure the necessary prerequisites have been met to complete the console's Schedule Migration UI and also to avoid failures during the system's activities in the pre-build process and in the migration maintenance window.

Before your scheduled maintenance window commences, a pre-build and copy process occurs (see the next section).

Pre-Build

One of the self-service migration's guiding principles is to limit the activities that need to be done in a maintenance window.

Using a pre-build shortens the amount of time it will take the migration to occur during the maintenance window. This pre-build will not impact your existing pod or user sessions.

The following high-level conceptual diagrams illustrate what happens during the system’s pre-build process.

Note: Please note that these diagrams are to illustrate the pre-build concepts at a high-level. They are not to be used to describe specific network topologies or communications over specific NICs or ports, or networking specifics.

Remember that this migration is an in-place migration, using the first-gen deployment's same Azure subscription, VNet, and subnets. Even though these diagrams depict the environments side-by-side, the self-service migration deploys the Horizon Edge using the first-gen deployment's VNet and subnets.

Also, please note that because these diagrams here are at a high-level, they do not parse out distinctions between apps, single-session desktops, multi-session desktops, images from IMS, images from the older style pre-IMS workflows, and so on.

First the system deploys the next-gen Horizon Edge, using the input you provide in the Schedule Migration UI.
Next, the system takes the first-gen configuration data that is stored at a pod level and in the first-gen control plane, transforms the data to match the next-gen control plane design, and stores the transformed data appropriately.
The system then copies the first-gen deployment's base VMs, published images, and App Volumes related files to the Horizon Edge, and configures the copies for use with the Horizon Edge.
Note: The first-gen deployment's base VMs, published images, and App Volumes related files remain in place until when you later confirm the end-to-end migration is completed.
For each first-gen floating desktop pool, the system creates a test pool in the Horizon Edge. Each test pool contains one desktop VM and mirrors the pool's configuration settings from its first-gen counterpart.
You can use these test pools to pre-validate that the floating desktop pool will behave in line with your expectations, before the pool is fully migrated during the maintenance window.

The pre-build activities end at this point.

Tip: VMware recommends that when you see that the Horizon Edge's Horizon Edge Gateway and Unified Access Gateway instances are up and running, you should configure the necessary DNS entries for their FQDNs. For more details, see Phase 6 - Configure DNS Records for the Infrastructure Created in Self-Service Migration Phase 5.

Commit and Run in the Maintenance Window

When the scheduled maintenance window arrives, the system performs a set of pre-checks. If issues are identified, the system reverts the actions that it took during the pre-build phase.

Reverting the pre-build actions brings the first-gen pod back to its original pre-migration state. In reverting, the system also attempts to bring the next-gen environment back to its state prior to the pre-build actions. However, if you or other of your admins made changes to the next-gen environment in the time period between when the pre-build finished and this reversion happens, the system might be unable to return the next-gen environment back to the state it had prior to the pre-build actions. In that case, please reach out to VMware for guidance.

If the pre-checks pass, the window is committed and remaining automated activities commence.

The system:

Transfers the resources associated with the pod's desktop pools and app pools from the first-gen pod to the next-gen Horizon Edge.
Rebuilds the VMs in floating VDI assignments and farms in the Horizon Edge based on the settings configured in the first-gen pod.
Updates the VMs in the dedicated VDI assignments to point their Horizon Agent configurations to the next-gen control plane.

Concept diagram of the action of transferring management of the resources to the Horizon Edge

During the Maintenance Window

During this maintenance window, end users and admins must not connect to resources.

If any user sessions are lingering or users did not log out, those activities will interrupt those sessions and user data might be lost because during the activities listed above:

VMs that are part of floating VDI assignments or farms will be deleted as the matching pool in the next-gen environment expands.
VMs that are part of dedicated VDI assignments will be rebooted

After the Maintenance Window

See the following sections to understand key things to expect in the migrated deployment, as compared with the first-generation experience.

Administrator Logins

Management access to the Horizon Universal Console is through the Workspace ONE Admin Hub.

New administrator login flow

Log in using https://console.cloud.vmware.com/ (VMware Cloud services), and navigate to My services to locate the Workspace ONE card.
Launch that service to open the Workspace ONE Admin Hub, where the Horizon Cloud Service card resides. Click Manage on that card to launch the Horizon Universal Console.

End User Experience

The general end-user experience of launching a desktop in a next-gen deployment is described in Launch a Desktop.

The URL address that your end users use to access the service is different than the URL used for your first-gen deployment.

The authentication workflow is also different, because in the next-gen service, the end users are required to login using the configured identity provider, rather than the Active Directory domain login workflow used in the first-gen deployment.

As described in Current Key Exclusions and Special Case Scenarios, migration of the end-user desktop preferences set in the Horizon Client for each desktop is currently unsupported in this self-service migration. After the migration, your end users must set those desired preferences again in their clients.