When your next-gen environment is enabled for you, you can initiate self-service migration of a Horizon Cloud on Microsoft Azure deployment located in the first generation Horizon Cloud control plane to Horizon Cloud Service - next-gen.

Note: At the time of this writing, first-gen environments where the pod fleet consists entirely of VMware Horizon 8 pods, the Connection Server type of pods, are not included in this self-service migration process or in this accompanying migration guide. Their migration process is different from Horizon Cloud on Microsoft Azure pods. To obtain information about migrating Horizon 8 pods, please reach out to your VMware Horizon 8 representative.

Where to Begin

Choose one of the links below to read, depending on how much of the migration process you have completed on your own or with the Horizon Migration team.

Attention: Self-service migration for Horizon Cloud Service on Microsoft Azure pods is a progressive rollout, done in waves by the Horizon Migration team. When eligible, you'll receive direct communication from Horizon Migration Communications.
What if I don't have an email from Horizon Migration Team?
Review the current eligibility criteria at Exclusions and Special Case Scenarios for Migration. Eligibility for enablement is based on specific factors. These factors evolve over time, making for a progressive rollout.
Table 1. Getting started
When... Do next
You've received an email from the Horizon Migration team about migration to next-gen, but...
  • Haven't had an introduction to the process.
  • Haven't done initial onboarding to next-gen.
  1. Watch: Tech Zone video Horizon Cloud Service first-gen to next-gen
  2. Do: Fulfill the prerequisites described in this guide
  3. Do: Confirm with the migration team that your next-gen environment is ready for your initial onboarding and complete those initial onboarding steps
After you've done initial onboarding to next-gen and you see the Migration UI, but...
  • Haven't configured the identity provider for next-gen.
  • Haven't paired your first-gen tenant with next-gen.
  1. Watch the first half of Tech Zone video: Scheduling a Horizon Cloud on Microsoft Azure pod migration.
  2. Do: Configure the identity provider.
  3. Do: Pair tenants.
After configuring the identity provider and pairing, but...
  • Haven't scheduled the maintenance window for a pod yet.
  1. Watch the second half of Tech Zone video: Scheduling a Horizon Cloud on Microsoft Azure pod migration.
  2. Do: Schedule maintenance window.
After the maintenance window is scheduled, but before that date arrives.
  1. Review: See the information about what happens during the pre-build phase.
  2. Do: Configure DNS records when you see that the new Unified Access Gateway instances are listed in the next-gen UI.
  3. Do: Use the pre-built test pools to pre-validate behavior.

    For each first-gen floating desktop pool, the system creates a test pool of one desktop in the Horizon Edge which mirrors the pool's configuration settings from its first-gen counterpart. You can use these test pools to pre-validate that each floating desktop pool will behave in line with your expectations.

Just prior to the migration maintenance time until the maintenance period is over. Review: See the information about what happens during the maintenance window.
Right after the maintenance period. Do: Perform post-migration activities
After performing the post-migration activities.
  1. Do: Finalize that migration.
  2. Do: Verify the private endpoint configuration for the App Volumes applications storage account, and configure if needed.
  3. If you have additional pods, plan for migrating the next pod.
Note: The terms Horizon Cloud on Microsoft Azure deployments and Horizon Cloud refer to the first generation of Horizon Cloud Service and that generation's cloud control plane. Other terms, such as v1 and first-gen, refer to the first generation of Horizon Cloud Service. The next generation of the service and control plane has the official name Horizon Cloud Service - next-gen and the abbreviated term next-gen.

Phase 1 - Initial Onboarding to Horizon Cloud Service - next-gen Environment

In this phase, you complete the initial onboarding steps in the next-gen environment. Those steps are almost the same as the steps when doing a brand new, greenfield deployment in the next-gen environment.

Note: If you have previously onboarded to your next-gen environment, you can skip this phase. When initial onboarding is complete, whenever you log in to the next-gen console, if the Migration page is not immediately displayed, you can click on the console's Migration entry in the left-hand navigation to display the page.

Perform the onboarding steps described in the page VMware Horizon Cloud Service - next-gen Deployment and Onboarding, through the step of selecting your Horizon Cloud region.

Organization Selection

At the onboarding workflow step where the UI flow asks you to select an existing organization or create a new one, specify the organization you decided on by following the guidance as described in Determine the Cloud Services Organization to Use.

Cloud Region Selection

After the organization , the region-selection UI appears.

Important: Once you select and save a region in this step, it cannot be changed later.

If you want to ensure that your control plane metadata remains in the same geographic region as was used for your first-gen tenant, then select the same geographic region that corresponds to your first-gen tenant's region.

The following screenshot illustrates the region-selection step with United States selected.


Screenshot of the control plane region selection UI for Horizon Cloud Services next-gen

You can match your next-gen region selection to the region that you used for your first-gen tenant. Doing so provides a way to identify which first-gen control plane region you're using. To match your next-gen region selection to the region that you used for your first-gen tenant, log in to the first-gen Horizon Universal Console, and after completing the authentication flow as described in Authentication to a Horizon Cloud Environment, examine the regional DNS name that appears in the browser's address field.

Note: This table is intended to list the supported first-gen regions and their next-gen counterparts. Over time, Horizon Cloud Service - next-gen might support additional regions. Such regions will not be added to this table, because they would not have a first-gen counterpart.
First-gen Regional Name Matching Next-gen Region Selection
cloud.horizon.vmware.com United States
cloud-eu-central-1.horizon.vmware.com Ireland
cloud-ap-southeast-2.horizon.vmware.com Australia
cloud-us-2.horizon.vmware.com United States
cloud-eu-2.horizon.vmware.com Ireland
cloud-ap-2.horizon.vmware.com Australia
cloud-jp.horizon.vmware.com Japan
cloud-uk.horizon.vmware.com United Kingdom
cloud-de.horizon.vmware.com Germany

After Region Selection

After you save in the preceding step, the console typically displays the Migration screen.


Screenshot of the Migration page in the next-gen console.
Note: If the Migration screen is not displayed, you can navigate to it by using Migration in the left navigation.

Next Steps

Follow the on-screen guidance. Complete the documented migration prerequisites and complete the pairing process.

Phase 2 - Pair Environments to Enable Migration Between Your Next-Gen and First-Gen Environments

To enable migration of a Horizon Cloud on Microsoft Azure deployment to your next-gen environment, you must pair your first-generation environment with your Horizon Cloud - next-gen environment.

Note: To perform the steps in the next-gen console, you must have the Administrator role in the next-generation environment. Refer to the page Assigning Administrative Roles in the Horizon Cloud Service - next-gen using guide.
Remember: Currently the console provides the migration banner, the Next-Gen Migration wizard, the Migration menu and the Migration page only when your first-gen deployments are made eligible for migration by VMware.

About This Pairing Code

A pairing code is the system's way of associating your Horizon Cloud - next-gen environment with your first-generation environment for the purposes of migrating your first-gen deployments.

You obtain a pairing code from your first-gen environment, copy that pairing code, and paste it into the migration panel in your Horizon Cloud - next-gen environment.

Pairing Steps

Each time you generate the pairing code using the console, the code is valid for 30 minutes. If you do not complete Step 9 before 30 minutes has elapsed, simply repeat Step 5 to generate a new one to copy and paste in Step 9.

If you choose to view both consoles at the same time, a best practice is to use browser windows in private mode or incognito mode to avoid UI issues that might result from the browser cache of images or other cached page content.

  1. Obtain the pairing code using one of these methods.
    • If your console displays the migration banner, you can click the banner's LET'S GO to start the Next-gen Migration wizard and select Yes on the Get Started step to display the pairing code as depicted in the following screenshot.
      Note: The first-gen console displays this banner and wizard only when VMware has enabled them in your first-gen environment.

      Screenshot of the Next-gen Migration wizard for the Yes scenario.
    • Click your account name displayed in the console and select Pairing Code.
      Screenshot showing the user account menu and the pairing code choice.
  2. Copy the pairing code. The following screenshot illustrates the code redacted for privacy.
    Screenshot showing the console window and a redacted pairing code.

    This pairing code is valid for 30 minutes.

    If the code expires, the console has a refresh action for you to generate a new one.

  3. Go to the Migration page in your Horizon Cloud - next-gen environment.
    • From the Migration - Get Started wizard, you can click Start to launch the next-gen console displaying the Migration page.
    • Alternatively, you can open a browser window, log in to VMware Cloud services, and from the Services page, navigate into the Workspace ONE service, locate the Horizon Cloud Service card within your set of Workspace ONE Cloud services, and then click the action to open the next-gen console from there. Then navigate to the Migration page using the using the left hand navigation menu's Migration entry.
      Screenshot of the console and an arrow pointing to the location of the Migration choice.

      The following screenshot illustrates the console's Migration page.


    Screenshot of the Migration page in the Horizon Universal Console.
  4. Click the Pair Tenants link.
  5. In the Pair Tenants window that appears, paste your copied pairing code into the Pairing Code field.

    The following screenshot illustrates this step. The pasted code is redacted here for privacy.


    Screenshot of the Pair Tenants window with a redacted code in the Pairing Code field.
  6. Click Pair.

    When the system has successfully paired the tenants, the next-gen UI indicates that pairing is successful.


    Screenshot of the Migration page for a successful pairing.

Next Steps

Now that your first-gen tenant and next-gen tenant are paired, follow the on-screen guidance and connect an identity provider.

Phase 3 - Configure the Required Identity Provider Settings in Your Next-Gen Environment

In this phase of the migration workflow, you must input settings for an external identity provider. These settings register the identity provider for use with the next-gen environment.

Brief Introduction

The next-gen environment by design relies on having an external identity provider to provide the authentication required when end users attempt to access their entitled resources.

The next-gen architecture's use of an external identity provider allows for integration with third-party products and solutions to provide multi-factor authentication and SSO capabilities.

Attention:

Before registering the identity provider, verify that the to-be-migrated pod's AD domain is connected to your identity provider – the one that you'll specify for this next-gen environment.

Video Illustration

These Tech Zone videos illustrate configuring one of the supported identity provider types in a next-gen environment:

Preparations

Ensure that your identity provider is set up and is connected to your AD domain as described in the page Setting Up Your Identity Provider located in the Horizon Cloud - next-gen guide.

The next-gen tenant console UI requires input of an auxiliary domain join account. This is a difference from the first-gen tenant console, where the auxiliary domain join account was optional. Ensure that you have the name of an auxiliary domain join account before starting the domain registration steps in the UI.

Create the Identity Provider Connection

In the console for your next-gen tenant, navigate to the console's Identity Provider UI tab by clicking Connect in the Migration page.


Screenshot of the Identity Provider tab in the next-gen console UI.

Complete the console's Identity Provider flow to connect the next-gen tenant to an identity provider.

For the specific guidance about this Identity Provider UI, see the page Connecting Your Identity Provider located in the Horizon Cloud - next-gen guide.

The following screenshot illustrates the completed state, where the identity provider is successfully connected (some values redacted for privacy).


Screenshot of the Identity Provider UI tab when successfully connected.

Next Steps

In the next-gen console, navigate to the Migration page.


Screenshot of the console and a callout-1 at the location of the Migration choice.

Now that the identity provider is connected, the console makes available the Start button, and you can click it to begin scheduling the automated migration.


Screenshot of the Migration page with the Start button available to use.

Phase 4 - Schedule a Pod's Migration Maintenance Window

In this phase, you select the to-be-migrated pod, specify the details required for the system's build-out of the Horizon Edge, and reserve a calendar slot in which you want the migration maintenance window to take place.

This calendar slot is the maintenance window.

During the maintenance window you and other administrators cannot access the Horizon Universal Console of your first-gen tenant and your end users cannot access their desktops and applications that are provisioned by the migrating pod.

Before Beginning These Steps

Before starting this workflow in the console, make sure the following items are in place.

All the prerequisites are in place
You have determined which Horizon Edge Gateway deployment type - Single VM or AKS - to use: Decide on Your Deployment Type and Fulfill Its Requirements.
In addition to the main prerequisites, you have fulfilled the prerequisites of your chosen Horizon Edge Gateway deployment type:
You have completed the steps in Phase 3 - Configure the Required Identity Provider Settings in Your Next-Gen Environment.
Ensure that Azure policies related to tags and resource group creation, are lifted (turned off) and remain off until you see that the Horizon Edge Gateway and Unified Access Gateway instances are successfully deployed in the pod's subscription. The deployment activity starts after you complete the scheduling wizard. When successfully deployed, notification messages will appear in the next-gen Horizon Universal Console.
Important: If a prerequisite is missing, the system's pre-validation checks will fail and the system cannot enter its pre-build phase, which will block the migration process.

The scheduling wizard's UI requires you to either select or input values for the following items.

Ensure you have this information and items in place before starting the wizard. These items are all described in the prerequisites pages.

New Unified Access Gateway items:
  • FQDN you'll enter into the wizard UI
  • SSL certificate for the Unified Access Gateway configuration (PEM or PFX format) that matches the FQDN.
Important: Ensure that the certificate's common name or FQDN precisely matches the FQDN that you plan to enter in the wizard. The wizard's validates the data within the certificate with the typed-in FQDN. If there is no match, the system will prevent the migration from being scheduled and you'll have to cancel out of the scheduling wizard.

If using the AKS deployment type

For the AKS type, the wizard asks for:
  • NAT gateway or route table associated with the management subnet, used for the Horizon Edge's AKS cluster outbound connections
  • User-assigned managed identity
  • The CIDRs to use for the Horizon Edge's AKS cluster (service CIDR, pod CIDR)
Note: If you had to create a new VNet and management subnet for use with the AKS type to work around the AKS-restricted IP addresses, ensure you know their names so that you can identity and select them in the wizard UI.

If using the Single VM deployment type

For the Single VM type, the wizard doesn't ask for input.

If the pod's external gateway is using a private IP address

If the first-gen pod's external gateway deployment is configured to use a private IP address, have the new public IP address to use for the next-gen Unified Access Gateway deployment, as described in Prerequisites for Migrating a First-Gen Horizon Cloud Pod..

The wizard asks for that information.

Some Site-Related Points - Universal Broker Environments

Please keep these points in mind when you have a first-gen Universal Broker environment with multiple Horizon Cloud pods.

As described in the first-gen Administration Guide page Working with Sites in a Universal Broker Environment, when your first-gen tenant is using Universal Broker, you can configure sites and home sites.

  • The system migrates the site configurations that exist in the first-gen tenant during the first pod migration. An example of site-related information is the mapping of a user to a home site.
  • When you finalize that first pod's migration and then subsequently make changes to the site-related information in the first-gen environment, those changes will not become visible in the next-gen environment until the next pod migration.
  • Any existing site-to-user and site-to-group mappings in the next-gen environment are the source of truth when a pod is migrated. If a user or group home site mapping for a user or group exists both in the next-gen environment and in the first-gen environment, the migration process ignores the first-gen site mapping. This information is included in the migration report.
  • After each pod's migration, if you had any home site mappings, review the home site mappings in the next-gen environment and update as needed for your organizational needs.

Schedule Migration Workflow UI

Click Start on the Migration page to see the Schedule Migration workflow.



The console displays the set of first-gen Horizon Cloud on Microsoft Azure deployments that are in the pod fleet of the first-gen tenant paired with this next-gen tenant.

The system automatically validates that a first-gen deployment is compatible with the self-service migration. This criteria includes validating that pod manager instances are running an appropriate manifest version, the images, VDI desktop and farm VMs have the appropriate Horizon Agent versions, and that features used in the first-gen deployment are also compatible with the self-service migration's current abilities.

For each first-gen deployment, the console indicates whether the deployment meets the system's criteria for its automated migration. If the criteria are met, the UI indicates Ready to migrate.

If the deployment does not meet the criteria, you can click on the status column to display a window which describes the issues. After you address those items, you can use the Rescan action to rerun the system check of the first-gen deployment. For examples of the criteria the deployments must meet, see Exclusions and Special Case Scenarios for Migration.

Note: When you use the Rescan action, the page does not automatically refresh. You must click Refresh to see the latest status.

Select First-Gen Pod

When UI indicates the pod you want to migrate is ready to migrate, select the pod and click Next.

If you have multiple pods in your first-gen environment with a combination of internal-only gateways and external gateways, migrate the pods with external ones first.



After selecting a pod, click Next to proceed.

Horizon Edge - Add New, Select Existing

When you click Next, the system analyzes what is available in the next-gen environment for a Horizon Edge to represent the post-migration pod.

The wizard displays buttons:

  • Add New
  • Select existing

A grayed-out button means it cannot be used for this migration and the system-selected one must be used. A banner will display the reason.

If neither are grayed-out, and one is selected by default, this means the system recommends using the pre-selected one and you can override the system's recommendation and choose the other one for this migration.

The following sections briefly describe the purposes of Add New and Select existing in the Schedule Migration flow.

Button - Select Existing

When Select existing is selected, the wizard displays a list of the environment's existing Horizon Edges. Select the Horizon Edge to use for this migration and click Next. Proceed to Step 3 - scheduling the migration time period.

When using an existing Horizon Edge, the system scales the existing Unified Access Gateway deployment with the same number of Unified Access Gateway instances that are associated with the first-gen pod. The maximum limit of this scale is eight (8) Unified Access Gateway instances. When that limit is reached in the selected Horizon Edge, the Unified Access Gateway deployment won't be increased.

Also, about the following use cases:

  • First-gen pod has the same subscription, same Microsoft Azure region, different app ID (service principal) than the selected Horizon Edge: The system scales the selected Horizon Edge's provider by adding the first-gen pod's app ID to that provider.
  • First-gen pod has a different subscription, same Microsoft Azure region, different app ID (service principal) than the selected Horizon Edge has: The system adds a secondary provider to the selected Horizon Edge.

Button - Add New

When Add New is selected, the system will create a new Horizon Edge for this first-gen pod's migration.

In this case, the wizard requires you to complete the displayed options and fields for configuring the new Horizon Edge.

UI Fields Description
Horizon Edge Name Specify a name that will uniquely identify this Horizon Edge within your next-gen tenant. The name must start with a letter [a-Z], and contain only letters, dashes (-), and numbers.
Deployment Type

Click the choice that corresponds to the deployment type you decided to use for the Horizon Edge Gateway.

Single Virtual Machine is the default.

  • Single Virtual Machine - Deploys the Single VM type.
  • Azure Kubernetes Service- Deploys the AKS type.

See the section below that corresponds to your chosen Deployment Type.

Single Virtual Machine Deployment Type

For the Single Virtual Machine deployment, there are no additional related fields in the wizard. This type of deployment uses the pod's management subnet for the Horizon Edge Gateway.

Continue with the Unified Access Gateway information.

Azure Kubernetes Service Deployment Type

Complete the fields. These are all required. The UI validates these all have entries before it will enable the Next button.

UI Fields Description
Cluster outbound type Two choices - NAT gateway or User defined routes.

Select the choice that matches what your or your IT team decided to set up in Azure to meet this requirement, as described in section AKS Type - Configure Either a NAT Gateway or a Route Table and Associate to Management Subnet.

User Assigned Managed Identity Select the user-assigned managed identity that you or your IT team has set up in Azure to meet this requirement, as described in section AKS Type - Create User-Assigned Managed Identity
Virtual Network and Management Subnet If you see both of these fields, make the selections according to what you prepared to handle the prerequsites.

These fields are displayed when the system's checks determine that the VNet overlaps the AKS-restricted IP ranges as described in Determine Whether the Pod's VNet or Connected Networks Contain AKS-Restricted IP Addresses.

Select the new VNet and management subnet in that VNet.

Service CIDR Input the CIDR that you or your IT team has decided on to meet the AKS service CIDR requirement, as described in section AKS Type - Reserve Required Virtual IP Ranges.
Pod CIDR Input the CIDR that you or your IT team has decided on to meet the AKS pod CIDR requirement, as described in section AKS Type - Reserve Required Virtual IP Ranges .

Unified Access Gateway Information

UI Fields Description
Unified Access Gateway FQDN Type the FQDN for the Unified Access Gateway that you or your IT team decided to use for this deployment. The Horizon Agents in the virtual desktops and apps will connect to this FQDN.
Certificate Type Two choices - PEM or PFX. Choose the type that matches the certificate you or your IT team obtained for this deployment, that matches the Unified Access Gateway FQDN.

For PFX, an additional Password field displays for you to enter the password for the PFX certificate.

Certificate Click the button to upload the certificate.
Manual Public IP This field displays when the system detects the first-gen pod's external gateway deployment is configured to use a private IP address.

Enter the public IP address that you want used for the next-gen deployment, as described in Prerequisites for Migrating a First-Gen Horizon Cloud Pod.

Note: This public IP must be different from the public IP already in use for the to-be-migrated first-gen deployment, to support rollback to the first-gen deployment state if rollback is needed.

As part of the pre-build activities, the system will deploy the next-gen Unified Access Gateway deployment's load balancer with a private IP address. After the load balancer is deployed and its private IP address known, you must ensure that you set up the routing so that this public IP directs traffic to the deployed load balancer's private IP.

When all of the fields have entries, click the Next button to move to the next step.

Step 3 - Schedule Migration Time Period

In this step, you select a time period for the migration's maintenance window.

During the selected time period:

  • Do not make any changes to the first-gen pod, its resources, settings, etc.
  • Do not make any changes to the next-gen environment's deployment.
  • The system will prevent access to the Horizon Universal Console.
  • Your end users cannot access their desktops and applications that are provisioned by the migrating pod.
  • Refrain from accessing the next-gen environment during the selected time period, to avoid disrupting the process.

The UI displays a calendar view that depicts those slots that the system makes available for the migration activities.

  • The calendar view accurately reflects which days and time slots are available for migrating your selected first-gen pod.
  • Generally speaking, the first day available for selection will be a minimum of 7 days in the future.
  • You can scroll through this calendar view as needed to find a date and time slot appropriate for your team and organization's needs.
  • Each time slot is a 6-hour block.

The following screenshot illustrates the UI calendar used for selecting the migration maintenance time window.

Hovering over one of the time blocks displays a pop-up that shows that slot's time in both your browser's local time and UTC.


Screenshot of the Step 3 - Schedule Migration when it first displays

The following screenshot illustrates a selected block. The system will begin its activities at this time.


Screenshot of the calendar with Tue Mar 15 12:00PM time slot selected and the Save button now available

When you have selected one of the time slots, you then click Save to save your choice.

What the System Does Next

After you save your selected time slot, the system will display a message that confirms your selected time window and describes the next steps.


Screenshot of the confirmation message about the scheduled time slot and what will happen next.

After you click OK in the confirmation message, the system will:

  1. Perform its pre-build activities.
    When using Add New (migration to a new Horizon Edge)
    In this case, the system deploys the Horizon Edge and its associated resources (the Horizon Edge Gateway and Unified Access Gateway instances and associated load balancers).
    When using Select existing (migration to an existing Horizon Edge)
    When using an existing Horizon Edge, the system scales the existing Unified Access Gateway deployment with the same number of Unified Access Gateway instances that are associated with the first-gen pod. The maximum limit of this scale is eight (8) Unified Access Gateway instances. When that limit is reached in the selected Horizon Edge, the Unified Access Gateway deployment won't be increased.

    Also, for the following use cases:

    • First-gen pod has the same subscription, same Microsoft Azure region, different service principal app ID: The system scales the selected Horizon Edge's provider by adding the first-gen pod's app ID to that provider.
    • First-gen pod has a different subscription, same Microsoft Azure region, different service principal app ID: The system adds a secondary provider to the selected Horizon Edge.
  2. Copy the published images and App Volumes applications from the first-gen pod to the Horizon Edge.

A deployed Horizon Edge has a load balancer for the Horizon Edge Gateway instance and a load balancer for the Unified Access Gateway instances.

In the Add New use case, when the new Horizon Edge is deployed and you and your IT team can obtain the IP addresses for those load balancers and update your DNS to add a records that map the Unified Access Gateway FQDN load balancer IP address with the Unified Access Gateway FQDN specified in this Schedule Migration wizard. For more details, see Configure Required DNS Records After Deploying Horizon Edge Gateway and Unified Access Gateway in the next-gen documentation.

Note: If you entered a Manual Public IP, you must ensure you set up the routing needed from that public IP to the deployed load balancer's private IP address.

Clicking OK in the confirmation message returns you to the console's Migration page.

Your Next Steps

Most of your time during the system's pre-build phase is waiting for the system to finish its pre-build activities (refer to the migration flow diagram).

During the pre-build phase, you can use the Migration Status and Report columns in the console's Migration page to check on what is happening.

Tip: When the migration is adding a new Horizon Edge, VMware recommends that when you see that the Unified Access Gateway instances and load balancer are deployed, you should configure the necessary DNS entries.

Even though these DNS entries can be configured after the maintenance actions are completed, the migrated environment isn't fully functional without the DNS entries that map your specified FQDNs to the underlying IP addresses allocated to these resources. See Phase 6 - Configure DNS Records for the Infrastructure Created in Self-Service Migration Phase 5.

Important: When your first-gen tenant is a Universal Broker environment, avoid making any changes to the site-related configurations for users and groups that are already set in the first-gen tenant.

Migration Page Features

Now that one pod is scheduled for migration, the console's Migration page displays that status and makes available actions for rescheduling (Reschedule) and cancelling (Cancel) the scheduled migration time.

When you select one of those actions, follow the on-screen prompts.

The following screenshot shows the pod selected and the availability of the Reschedule and Cancel actions. The Finalize action in this screenshot is unavailable because this pod is not yet migrated.


Screenshot of the console's Migration page with one pod scheduled for migration.

Phase 5 - Pre-Build - Automated Actions Prior to Maintenance Window

During this phase, the system automatically performs pre-build migration activities in advance of the specified migration window. This front loading of activities seeks to minimize the amount of time needed in the migration maintenance window.

Brief Introduction

As described in What to Expect, using a pre-build shortens the amount of time it will take the migration to occur during the maintenance window.

For all migrations, the system deploys the required resources during the pre-build phase.

When the migration is using a new Horizon Edge, the system also deploys the resources for the Horizon Edge at the start of the pre-build.

Attention: Because the system creates resources in this pre-build phase, you are likely to see new resources appearing in your Azure subscription and in your next-gen environment during this time.

Be aware of these points:

  • Even though the next-gen console does not prevent you from creating pools in the next-gen environment using those resources, VMware strongly recommends that you avoid creating pools or doing other creation workflow using those new resources until after the overall migration is completed.

    If those resources are used within the next-gen environment prior to the migration maintenance window, and then you subsequently cancel the migration or use the UI's rollback action, the system cannot return the next-gen environment to its original starting state. In this scenario, you might need to undertake additional manual actions in the environment to get it to a state where the system is then able to have you re-initiate the migration process.

  • During the pre-build, the system first temporarily duplicates each first-gen published image in the first-gen pod's base-vms resource group, and performs agent update and other activities on these duplicates before publishing them in the next-gen environment. These temporary VMs use the naming convention MIGXXXXXXXXXXXX.

    As the system works with these temporary VMs and until they are published to the next-gen environment, you will see the MIGXXXXXXXXXXXX images listed on the first-gen console's Imported VMs page.

    It is important that you avoid performing any actions on these temporary VMs, because doing so can cause the migration pre-build phase to fail. For example, do not power off the temporary VMs.

This pre-build will not impact your existing pod or user sessions.

Important: When your first-gen tenant is a Universal Broker environment, avoid making any changes to the site-related configurations for users and groups that are already set in the first-gen tenant.

During the Pre-Build

During the pre-build:

  1. If the migration is using a new Horizon Edge instead of an existing one, the system deploys the next-gen Horizon Edge, using the inputs you provided in the Schedule Migration UI in Phase 4.
  2. 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.
  3. When this migration is the first one into the next-gen environment, the system takes the first-gen tenant's Active Directory (AD) domain configurations and creates the equivalent domain configurations in the next-gen environment.

    In the next-gen environment, the system registers all of the first-gen tenant's registered domains during the pre-build activities for the first scheduled migration. For subsequent pod migrations from the same first-gen tenant, the system re-verifies that the first-gen tenant configurations are in sync and skips registering domains that already exist in the next-gen environment.

    Note: The next-gen environment requires auxiliary accounts for both the domain bind and domain join account in the next-gen AD domain configurations. If a first-gen tenant's AD domain configuration is missing an auxiliary domain bind account or auxiliary domain join account, the system will automatically re-use the primary account information as the companion auxiliary account in the next-gen AD domain configuration.

    As a best practice, you should obtain service accounts in your AD domains for these auxiliary domain bind and domain join accounts, and after the pre-build activities, edit the AD domain configurations to add those auxiliary accounts.

  4. The system copies the first-gen deployment's published images and App Volumes related files to the Horizon Edge, and configures the copies for use with the Horizon Edge.
  5. For each of the following first-gen items, the system creates a test pool in the Horizon Edge.
    • RDSH desktop farms
    • RDSH app server farms
    • Floating desktop assignments (pools) from single-pod broker tenants. (Multi-cloud assignments won't have test pools.)

    Each test pool contains one machine and mirrors the pool's configuration settings from its first-gen counterpart.

    You can use these test pools to pre-validate that the pool's machines will behave in line with your expectations, before the pool is fully migrated during the maintenance window.
    Note: Because the system rebuilds floating and RDSH pools, if you have licensed third-party solutions in your environment where the license is tied to the identity of the VM more of those licenses might be consumed.

The pre-build activities end at this point. The system starts its next activities at the start of the scheduled maintenance time period. To provide for the event of rollback, the first-gen deployment's published images and App Volumes related files remain in place until when you later confirm the end-to-end migration is completed.

Your Next Steps

After the resources are built in your subscription, please perform the activities described in the following sections.

When migrating to a new Horizon Edge, configure the required DNS entries

At the point when you see that the new Horizon Edge's Unified Access Gateway and Horizon Edge Gateway instances are up and running, you should configure your DNS with records that map the FQDNs that you specified in the migration UI to the relevant IP addresses. See Phase 6 - Configure DNS Records for the Infrastructure Created in Self-Service Migration Phase 5.

Typically those instances are up and running within 48 hours of the scheduled migration maintenance window.

Pre-validate pool behavior using the test pools

Locate the test pools in the Horizon Universal Console by navigating to Resources > Pools.

Each test pool will have a single machine that you can use to pre-validate the next-gen experience for that pool.

AD domains - auxiliary domain-bind and domain-join accounts

As described in the previous section, if a first-gen tenant's AD domain configuration is missing an auxiliary domain bind account or auxiliary domain join account, the system will automatically re-use the primary account information as the companion auxiliary account in the next-gen AD domain configuration.

As a best practice, you should obtain service accounts in your AD domains for the auxiliary domain bind and domain join accounts, and after the pre-build activities, edit the AD domain configurations to add those auxiliary accounts. In the next-gen console, you edit the domains on the Integrations page (Integrations > Manage > Domains).

Phase 6 - Configure DNS Records for the Infrastructure Created in Self-Service Migration Phase 5

In this phase, you or your IT team updates your DNS with records that map the FQDNs that you specified in the Schedule Migration UI to the appropriate IP addresses.

Note: You can skip this step of configuring DNS records when the migration is using an existing Horizon Edge.

Same as for a greenfield Horizon Edge deployment, you are responsible for creating the DNS records. The self-service migration cannot perform that update on your behalf.

Even though the DNS records that map the IP addresses to their FQDNs can be done at a later date, it is a best practice to create those records as soon as the IP addresses are assigned to the instances.

The reason for putting the mapping into place sooner than later is because lack of the records that map your chosen FQDNs to the instances' underlying IP address will prevent your next-gen environment from being fully functional for the post-migration validation steps.

For the details about which IP addresses need to be mapped to the FQDNs, see the page Configure Required DNS Records After Deploying Horizon Edge Gateway and Unified Access Gateway in the next-gen documentation.

In the Horizon Universal Console, the FQDNs and relevant load balancer IPs are displayed in the Horizon Edge's details page. You can drill-down to the Horizon Edge's details from the console's Capacity page (Resources > Capacity > Horizon Edges).

Next Steps

When the starting time for the scheduled migration maintenance window arrives, the system begins the remaining migration activities.

In this migration documentation, continue reading with Phase 7 - Migration Maintenance Window.

Phase 7 - Migration Maintenance Window

At the start time of your scheduled migration window, the system automatically starts its final automated migration steps. During this time, administrator and end-user access is prevented to the administration console and end-user entitled resources in the first-generation tenant.

While the migration is in progress, the console's Migration page displays the status for the migrating pod.


Screenshot of the Migration page with the first-gen pod's migration in progress

Restricted Activities

During this maintenance window:

  • Do not make any changes to the first-gen pod, its resources, settings, and so on.
  • Do not make any changes to the next-gen deployment.
  • The system will prevent access to the first-gen Horizon Universal Console.
  • Your end users cannot access their desktops and applications that are provisioned by the migrating pod.
  • Refrain from accessing the next-gen environment during the selected time period.

The self-service migration requires the above restrictions because, during this time, the system is actively transferring resources from the first-gen deployment to the next-gen environment.

The System's Automated Actions

The active operations that occur during this maintenance window include:

  • Shrinking the first-gen deployment's floating desktop pools and farms until they no longer use any capacity.
  • Correspondingly, expanding floating desktop pools and farms in the next-gen environment to match the capacity they had in the first-gen deployment.
  • Pairing the desktop VMs from the first-gen deployment's dedicated desktop pools with the next-gen environment.
    Note: The migration actions for dedicated desktops might automatically power on the desktop VMs as needed, even if the time is outside of the dedicated desktop pool's power management schedule. As part of the migration, the Horizon agent in the desktop VMs must unpair from the first-gen deployment and pair with the next-gen environment, which might require powering on the VMs.

If the system detects any failure, it automatically attempts to revert the changes made up to that point. For details about the reversal process, see page Rolling Back a Migration.

When the actions are completed successfully and the maintenance window end time is reached, you'll see the pod's Migrating status change on the console's Migration page.


Screenshot of the new status at the end of the maintenance window activities
Tip: The system reflects this status because the first-gen pod infrastructure of its pod manager instance and Unified Access Gateway instances still exist until you confirm deletion of the pod.

Special Notes about Dedicated Desktop VMs

At the end of the maintenance window, unless you finalize the migration:

  • The monitoring data for dedicated desktop VMs will not be published to Workspace ONE Intelligence.
  • The next-gen console will prevent you from updating or reinstalling agents for any dedicated desktop pool or dedicated desktop VM.

    The reason for preventing agent updates and agent reinstalls until the migration is finalized is because changes to the agents in the dedicated desktops could cause problems in the event of rollback. If you attempt to roll back the migration from the next-gen environment to the first-gen deployment state, and the agents were modified in the next-gen environment, the dedicated desktops might not work properly in the rolled-back first-gen deployment.

To finalize the migration, see Finalize the Migration.

Perform Post-Migration Activities to Confirm Migration Success

When the system completes its actions in the migration maintenance window, all the resources are now within the next-gen environment and your end users are able to access their desktops and applications.

At this point, the system lifts the restrictions it set for the maintenance window.

  • You and your other admins can access the first-gen Horizon Universal Console.
  • Your end users can access their desktops and applications, which are now provisioned by the next-gen environment.
Important: Because the URL or server address used to access end-user resources is different in the next-gen environment, you must inform your end users of the new address to use in their Horizon Clients and when using Horizon HTML Access Client (the browser). Refer to the page Launch a Desktop in the next-gen documentation.

Avoid Doing These Activities Until You Have Finalized the Migration

While some activities are allowed prior to finalizing the migration, taking such actions can cause issues.

Avoid renaming sites that were migrated until you have finalized the migration.
Do not rename sites prior to finalizing the migration flow. If you roll back the migration from the next-gen environment back to the first-gen tenant, and the migrated site name was renamed in the next-gen environment, then when that rolled-back pod is later migrated and that migration ultimately finalized, the next-gen environment will display both site names: the original first-gen site name, now empty, from the earlier migration and the new site name when it was renamed. If this scenario happens, delete the empty original first-gen site name from the next-gen environment.

Recommended Activities and Things to Know

To ensure that the next-gen environment is functional from your organization's business perspective, you and your VDI admins should complete the activities described in the following sections.

The following sections also describe characteristics of the migrated deployment. Review those characteristics for understanding of things you'll see in the next-gen environment post-migration.

Download and Review Migration Report

Post-migration, download and review the migration report.

The migration report is available from the Reports column on the console's Migration page.

This migration report provides details about the migrated resources and where changes were made in the migration process.

Typical changes include a resource's name change. The migration might change a resource's name if the resource from the first-gen deployment is migrated to a next-gen environment where the same name is already in use. In such situations, the self-service migration automatically renames those first-gen resources to avoid name clashes.

Confirm End User Experience

Confirm that end users can launch their floating desktops, dedicated desktops, and remote apps according to their entitlements.

Tip: For a video illustration of the end-user experience, see the Tech Zone video located within Log in to a Horizon Cloud - Next-Gen Desktop or App as an End User.

The end-user experience of launching desktops and applications in a next-gen deployment is described in the Using Horizon Cloud Service - next-gen guide:

The next-gen environment's starting address is cloud.vmwarehorizon.com.

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

Remember: As described in Exclusions and Special Case Scenarios for Migration, 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 can choose to reselect their desired preferences again in their clients if they want to.

Confirm Admin Login Experience

Confirm that admins logging in to the next-gen console can see the pools and other resources that they expect to see from the migrated first-gen deployment.

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

  1. Log in using https://console.cloud.vmware.com/ (VMware Cloud services), and navigate to My services to locate the Workspace ONE card.

  2. 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.


Minimum VM Setting From the Pod's VDI Desktop Assignments and Farms

The migration process is designed so the first-gen VDI desktop assignments and farms have equivalent power management settings in their equivalent entities in the next-gen environment.

For the first-gen VDI desktop assignments and farms, the equivalent next-gen entities are pools and pool groups. In the next-gen environment, the power management settings are made at the pool-group level. In the pool group's power management settings, the Minimum VMs is based on the percentage of VMs to keep powered on relative to the total VMs in the pool group. In the first-gen environment, the setting named Min VMs directly represents the minimum number of VMs desired in the VDI desktop assignment or farm.

Post-migration, when you edit the pool groups that the system created from migrating those first-gen assignments and farms, the console displays those pool groups' Minimum VMs setting as the percentage converted from the first-gen Min VMs value. The functionality continues to adhere to the Min VMs number based on the converted percentage.

AD Domain Configurations

The next-gen environment requires auxiliary accounts for both the domain bind and domain join account in the next-gen AD domain configurations.

During the pre-build activities, if a first-gen tenant's AD domain configuration is missing an auxiliary domain bind account or auxiliary domain join account, the system will automatically re-use the primary account information as the companion auxiliary account in the next-gen AD domain configuration.

If this is your scenario, then post-migration obtain service accounts in your AD domains for the auxiliary domain bind and domain join accounts and edit the AD domain configurations to add those auxiliary accounts. In the next-gen console, edit the domains by navigating to Integrations > Manage > Domains.

Attention: Once the system has migrated the first-gen tenant's AD domain configuration to the next-gen environment during the first pod's migration, you are responsible for maintaining any attribute changes for the configured domains in both the first-gen and next-gen environments. The system does not automatically propagate changes you make in one environment to the other. For example, if you update the password for the domain bind account in your first-gen tenant, then you need to perform the same update in the paired next-gen environment.

Site-Related Settings - Multi-Cloud Assignments

When your first-gen environment had multi-cloud assignments, perform the following actions post-migration.

Review the home site mappings
After each pod's migration, if you had any home site mappings, review the home site mappings in the next-gen environment and update as needed for your organizational needs.
Review the site-related settings in the pool groups created from migrating multi-cloud assignments
The migration process defaults some of the settings in the pool groups that are created from migrating the first-gen multi-cloud assignments to next-gen pool groups. These defaults are chosen to ensure end users could get to their desktops when the migration window ends.

Post-migration, you should carefully review these settings and ensure the defaults meet your requirements, or adjust them as needed to fit your organizational use cases. These settings are located within the pool group settings.

  • The Scope setting is set to Any site by default and the setting to require the home site is switched off.
  • The home site overrides from the first-gen assignment are not migrated over to the pool group.

App Volumes

Post-migration:

App Volumes: Bulk application entitlements
In the next-gen architecture, the system manages the entitlements differently than in the first-gen architecture. During the migration process, the system handles the resolution of any bulk application entitlements that were in the migrated first-gen deployment. This resolution ensures that the bulk entitlements are migrated into the form appropriate with the next-gen environment's management of entitlements. End users will still have access to the same set of App Volumes applications as they were entitled to in the first-gen environment.
App Volumes: Pod migrations
During the successive migration of Horizon Cloud pods over time, the system takes care of all of the App Volumes entities from the first-gen pods into the next-gen environment.

For example, you have the Notepad++ application as an App Volumes application with your first-gen pods and is used in both pod-1 and pod-2, and there are multiple versions of the application, with npp v7.8.1 in pod-1, npp v7.8.2 in both pod-1 and pod-2, and npp v7.8.3 in pod-2.

During pod-1's migration pre-build, the system copies the App Volumes application Notepad++ along with the npp v7.8.1 and npp v7.8.2 to the next-gen environment, as those are the two versions used in pod-1. The other pod (pod-2) is yet to be migrated at this point.

At this point, you have both environments and you want to make changes to the App Volumes entities in both the first-gen environment and next-gen environment. For these entities, during migration the system does not delete what it has already copied to the next-gen environment. If there are conflicts in App Volumes entities between the first-gen and next-gen environments, the entities present in the next-gen environment take precedence.

To illustrate, in the first-gen environment, you delete the package npp v7.8.2 in pod-2 before migration and add a new package npp v7.8.4. Then when you schedule pod-2's migration, the system copies the packages currently used by pod-2 (npp v7.8.3 and npp v7.8.4) to the next-gen environment. The npp v7.8.2 package in the next-gen environment that was copied there during the pod-1's migration remains in the next-gen environment, even though that npp v7.8.2 was deleted from the first-gen environment.

Remote Apps from First-Gen Application Farms

As described in the first-gen documentation here, remote apps are provided by application farms from the first-gen pod. The next-gen Horizon Universal Console has new terminology and its labels reflect that.

Post-migration:

  • One-to-one mapping is retained between the first-gen application farm and the resulting pool in next-gen.
  • A pool is created for each migrated farm, using the farm's name.
  • The migration process also creates a pool group for each pool, using the pool's name, which in the case of migration is also the original farm's name.
  • Each pool group displays the information about the user entitlements migrated from the first-gen applications assignments, according to the apps associated with that pool group's pool.
  • The first-gen applications assignment name is not visible in the next-gen console. When a first-gen applications assignment contains remote apps from multiple farms, then to see the remote apps and end-user entitlements within the next-gen console, you can view each pool group that was created with the farm names, or use the console's Desktop & App Catalog > Published Apps.

Consider:

  • First-gen applications assignment Assign-1 has apps app1, app2 from farm Farm-1, and user User-1 is entitled for app1 and app2.
  • First-gen applications assignment Assign-2 has apps app1 from Farm-1 and app3 from farm Farm-2, and user User-2 is entitled for app1 and app3.
  • Meaning that app1 is entitled to both User-1 and User-2, app2 is entitled to User-1 only, and app3 is entitled to User-2 only.

After migration to next-gen:

  • You see a pool named Farm-1 and a pool group named Farm-1 created for that pool. In that pool group, you see applications app1 and app2 (those were the applications from that first-gen farm).
  • You also see a pool named Farm-2 and a pool group named Farm-2 created for that pool. In that pool group, you see application app3.
  • The migrated entitlements are:
    • app1 from pool group Farm-1 entitled to User-1 and User-2
    • app2 from pool group Farm-1 entitled to User-1
    • app3 from pool group Farm-2 entitled to User-2

After Post-Migration Activities - Finalize

When you have confirmed that the next-gen environment is operating satisfactorily, the final pod-migration action is to finalize the migration.

During finalization, the Azure resources that the first-gen pod is still consuming from your Azure subscription are deleted.

Tip: You must finalize the migration as soon as possible to avoid your cost of running both the next-gen Horizon Edge's resources and the first-gen pod's resources in parallel. Finalizing reduces your costs because it deletes those Azure resources that the first-gen pod is still consuming.

After a pod is migrated, every time you log in to the Horizon Universal Console, the UI prompts about finalizing that pod's migration.


Validate the pod and continue migration as described in the text.

Finalize the Migration

Finalizing the migration is the last step in migrating a first-gen Horizon Cloud on Microsoft Azure pod.

Benefits of Finalizing

By finalizing:

  • You avoid additional Microsoft Azure costs because finalizing deletes the remaining resources consumed in Azure by the first-gen pod.
  • The system lifts the restrictions it placed on dedicated desktops when the maintenance window began:
    • Monitoring data for dedicated desktop VMs starts publishing to Workspace ONE Intelligence.
    • You can run the agent update and agent reinstall operations on dedicated pools and VMs.
  • You can safely make updates to the migrated images and pools without concerns of impacting rollback to the first-gen pod.

After finalizing, the migration cannot be rolled back from the next-gen environment back to the first-gen deployment state.

Before Finalizing - Perform Recommended Post-Migration Activities

Before finalizing, you should ensure the recommended post-migration activities are done. Those activities are described in the page Perform Post-Migration Activities to Confirm Migration Success.

Best Practice - Finalize Within a Few Days After Migration

It is a best practice to finalize the migration of each pod within a few days of completing the migration process because of the following factors:

  • Until the first-gen pod is deleted by finalizing the migration, you are incurring Microsoft Azure subscription costs for running the first-gen resources, including pod manager instances and Unified Access Gateway instances.
  • Until you finalize the migration, the next-gen Horizon Universal Console prevents you from using the agent update operations on dedicated pool groups and from using agent reinstall on dedicated VMs (Agent > Update Agent or Agent > Reinstall).
    Attention: When your next-gen environment has a non-finalized migration, the console prevents running the update agent and reinstall agent operations for all dedicated pool groups and dedicated VMs, whether they were ones migrated from first-gen or ones newly created in the next-gen environment. In this scenario, the console displays a guidance message about the need to finalize the migration.

    The reason for preventing agent updates and agent reinstalls until the migration is finalized is because changes to the agents in the desktops could cause problems in the event of rollback. If you attempt to roll back the migration from the next-gen environment to the first-gen deployment state, and the agents were modified in the next-gen environment, the desktops might not work properly in the rolled-back first-gen deployment.

  • As time elapses and you and your VDI admins make changes in the next-gen environment, the ability to rollback the migrated environment to a first-gen deployment state that would satisfy your end users becomes degraded. For example, as you expand dedicated desktop pools in the next-gen environment and assign end users to new desktops, and then try to rollback to the first-gen pod, issues might occur for those new desktops on the first-gen side.

Finalizing Steps

You finalize the migration using the Finalize action on next-gen console's Migration page.

After you click Finalize, the console displays an approval window for you to approve deletion of the source first-gen pod.


Screenshot of the Approve Source Pod Deletion window

To complete the migration process and confirm to the system that the first-gen pod can now be deleted, click Approve.

After Finalizing - Verify Private Endpoint Status for App Volumes Applications Storage Account, and Configure As Needed

After finalizing, it is strongly recommended to configure the Microsoft Azure private endpoint for the App Volumes applications storage account, if you see it is not already configured for the Horizon Edge.

Although the migrated environment works without this private endpoint configuration, configuring the private endpoint will further enhance the security for this storage account. As of this writing, when the migration process deploys a new Horizon Edge, this storage account's default configuration has public network access enabled from all networks. (This default is different from the first-gen pod's settings.)

To verify the status in the next-gen Horizon Universal Console, navigate to the Horizon Edge details and look for the App Volumes Application Storage section.

If you see Not Configured, follow the guidance described at these locations in the next-gen Using guide.

As an illustration, the following screenshot depicts the UI showing a single storage account and where you can see if the private endpoint is configured. In this case, the private endpoint is not yet configured for this storage account.


Screenshot of the location in the Horizon Edge details UI where the private endpoint configuration status is displayed.

The following screenshot shows the location of the menu for configuring the private endpoint. When you click the configure choice, follow the on-screen guidance. The steps are documented in Configure Private Endpoint for an App Volumes Application Storage Account.


Screenshot of the three-dot menu for configuring the private endpoint on the storage account.
Note: If you want, you can have the private endpoint use a subnet different than the Horizon Edge Gateway's management subnet, and in a different VNet if you prefer. In that case, you must ensure network peering is established between the VNet you choose for the private endpont and the VNets that have the Edge Gateway's management subnet and VNets of the desktop pools' subnets (if those subnets are in VNets different from the Edge Gateway's management subnet). For more information, see Azure Private Endpoint for App Volumes Application Storage Accounts page.

The following screenshot illustrates when the private endpoint is configured.


Screenshot of the status in the UI when the private endpoint is configured.

Pod Migration Completion

A finalized migration is a successful migration, congratulations!

For more information about day-2 operations, see the guide Using VMware Horizon Cloud Service - next-gen.

Remember: As described in the Scheduling page's section of Site-Related information, avoid making any changes to the site-related configurations for users and groups that are already set in the first-gen tenant. When you finalize the first pod's migration and then subsequently make changes to the site-related information in the first-gen environment, those changes will not become visible in the next-gen environment until the next pod migration.