Site icon TheWindowsUpdate.com

How to migrate classic Cloud Service to Cloud Service Extended Support – Part 2 In-place migration

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

In part 1, we have learned how to manually migrate a classic Cloud Service to Cloud Service Extended Support by recreating a new CSES(Cloud Service Extended Support) resource and redeploy the modified project. The manual way actually offers user more flexibility, but it will also consume more time. 

 

For this reason, Azure Cloud Service Extended Support officially offers a feature called In-place migration and this will do almost everything for users to migrate from a classic Cloud Service to CSES except the code change in your local project. In this part, we will focus on the feature how the in-place migration will be done and what this feature can do. 

 

The main advantage of in-place migration compared to manual migration

Before how to do the in-place migration, let us highlight the main advantage: 

 

Before you begin 

There will be some additional points to do before we start the migration. Please have a check of following points carefully since it may cause unexpected issue if they are not matched: 

1. Follow the “Before you begin” part of the document to make sure if you are an administrator/coadministrator of the subscription and if the resource providers Microsoft.ClassicInfrastructureMigrate,Microsoft.Compute, Microsoft.Networkand Microsoft.Storage are already registered.

Page of resource provider registration in Azure Portal

2. We should have a running classic Cloud Service. Please take care: If your classic Cloud Service was deployed before 2017 without classic Virtual Network setting and the deployment was never deleted, please kindly delete the current deployment and redeploy it. Otherwise, the in-place migration progress will be failed.

 

 

 

Then, let us move on the main process.

 

Original resource status: 

Since the process of this in-place migration is quite simple and the way is already explained clearly in official document for Portal and for PowerShell, in this blog I’ll use Azure Portal as example and mainly focus on providing you information about what it maximumly can do and what change there will be. Some of the resources in this blog may be unnecessary for your project, I’ll point it out later with keyword optional.

Resources overview:

classic Cloud Service to be migrated

Reserved IP used by classic Cloud Service

classic Virtual Network used by classic Cloud Service

(optional) A subnet in Classic Virtual Network: classiccssubnet

Subnet of classic Virtual Network used by classic Cloud Service

classic Network Security Group used by previous classic Virtual Network subnet

It can be linked to the subnet when we create subnet in Classic Virtual Network manually in Azure Portal.

Page of creating subnet in classic Virtual Network manually

(optional) An inbound security rule in Classic NSG: addedbeforemigration 

Inbound security rule of classic NSG

Resource Group containing all classic resources

 

Setting of classic Cloud Service: 

Role and Instance of classic Cloud Service

.cscfg configuration of classic Cloud Service

Certificates used by classic Cloud Service

Extensions of classic Cloud Service

RDP setting of classic Cloud Service

 

In-place migration process: 

The in-place migration process can mainly be split into three steps: validate, prepare and commit. Please check following steps to see how it works.

In-place migration page in Azure Portal

If you cannot see the Validate button, please click on the Refresh migration state button of the migration page but not the one of your browser, then the Validate button should appear. 

Possible in-place migration page without validate button

Validation progress in Azure Portal

Validation result in Azure Portal

Prepare progress in Azure Portal

If everything is good, you’ll see the result such as:

Prepare result in Azure Portal

Expected resources in newly created resource group

One Cloud Service Extended Support 
One public IP address
One Load Balancer 
One Key Vault (Only if your classic Cloud Service is with any certificate) 

Please check the above resources for following points. If anyone of these is not matching, please stop here and raise a support ticket to Azure support for help.

1. Whether the new public IP address is having the same URL as your classic Cloud Service and IP address as your classic reserved IP if you use.

New public IP address

2. Whether all the certificates are saved in the Key Vault secret part.

Certificates in Azure Key Vault secrets

To check this, you may get authorization failure as following:

Authorization failure when checking certificates in a newly created Key Vault

Please follow these steps to add an access policy to make yourself able to list certificates and secrets part. 

a. From Key Vault, click on Access policies and create button

Access Policy page of Key Vault in Azure Portal

b. Select the corresponding permission that you need. If only for checking certificate part, we can simply select the Secret & Certificate Management template click Next. 

Permissions of creating a new access policy

c. Type in the email address of the account signed in and select it. Please make sure your account is in the selected item shown at bottom side.

User of creating a new access policy

d. Skip the Application step and click Create.

Validation page of creating a new access policy

Commit progress in Azure Portal

Migration result in Azure Portal Notification window

 

Result:

 

Overview of all resources

Main resource group and resources: 

Main resource group and resources after migration

The name of the resources will be in following format:

P.S. If the classic Cloud Service is without classic Reserved IP address, a new public IP address will be created in the same resource group after in-place migration but the naming format will be IP-{classic Cloud Service name}. 

 

Then about Virtual Network and Network Security Group, it is more complicated. Please check following description and match your own situation: 

Resource group of Virtual Network and NSG

The name of these two resources will be in following format:

1. New Virtual Network: Group-{original resource group name}-{classic Virtual Network name} 

2. New Network Security Group: Group-{original resource group name}-{classic Network Security Group name} 

 

The subnet created in classic Virtual Network, the link between this subnet and classic NSG and the manually created security rule in classic NSG will all be migrated.

Migrated Virtual Network with migrated subnet

Migrated NSG with migrated security rule

 

The naming format of Virtual Network will be the same: Group-{original resource group name}-{classic Virtual Network name}.

 

The subnet created in classic Virtual Network will also be migrated. 

 

 

Setting in the CSES:

CSES using new public IP resource

Extensions in new CSES resource

RDP setting of new CSES instance

Certificates page of new CSES resource

 

After migration and possible error

Once the in-place migration is successful, please remember to check the new configuration .cscfg from Azure Portal and use this configuration to replace your original .cscfg configuration of project in your local environment.

.cscfg of CSES in Azure Portal

 

There are also some common errors which users may get. Please kindly check our official document about the prerequisites for deployment and common errors and known issues.

 

 

According to the official document, the classic Cloud Service will be retired on 31st August 2024. Every user is required to migrate their deployment from classic Cloud Service to other services and the Cloud Service Extended Support is a good choice for most of users. The in-place migration is the officially recommended way for this purpose and will make everyone easy to start using CSES.

Exit mobile version