Detailed CSP to EA Migration guidance and crucial considerations

 

If you have executed a CSP to EA Azure migration, you undoubtedly understand the potential unforeseen challenges that can arise when essential planning elements and comprehensive activities are overlooked.

In this blog, I've shared insights drawn from real-world migration experiences. This article can help you meticulously plan your own CSP to EA migration, ensuring a smoother transition while incorporating critical considerations into your migration strategy.

 

What is CSP to EA Migration

 

Organizations who are on CSP agreements/enrollments might want to decide to move to other enrollments type like in this article we will specifically talk about Enterprise agreement

 

To understand more in depth on these offers please refer the links

 

CSP Agreement :Cloud Solution Provider program overview - Partner Center | Microsoft Learn

Enterprise agreement: Azure Enterprise Agreement enrollment design area guidance - Cloud Adoption Framework | Microsoft Learn

 

 

It's possible to transfer other subscriptions from a CSP Partner to the subscriptions created and managed under Enterprise Agreement. However, these migrations aren't supported for billing transfer as documented in the Azure subscription transfer hub article. This means we can't perform this migration by making the enrollment changes in the backend.

 

This is where the whole planning of manual migration comes into the picture depending on what kind of setup we are hosting in the source subscription.

The subscriber needs to manually move resources between source CSP subscriptions and target EA subscriptions.

We will use a service called Azure Resource Movere and mix of manual migration effort here in this migration approach.

 

Migration Strategy 

 

 

Assessment & Discovery

 

• As a very first step we need to do the discovery of the workloads, resources hosted in the source subscription.
• We need to do a deep dive into each and every workload, how they are connected, dependency mapping, IP hardcoding etc.
• Create a very detailed excel report by exporting all the workloads across the subscriptions and document what can be moved with Azure resource Movere and what can not be moved. (i.e refer this link to create a support matrix on what's is supported for direct migration and what needs to be reconfigured) Move operation support by resource type - Azure Resource Manager | Microsoft Learn
• Use above link to create a comprehensive report on the support matrix by resource
• Apart from the resource assessment and discovery one of the very crucial consideration is to Document the existing RBACS in the source subscription. Will discuss later in the article on what to consider with the RBACS 

 

 

 

Prepare a Migration Plan

 

Here are few observations and recommendations that will help you plan the migration in better way

 Always create at least 2 Migration plans to be presented to the customer.

 

• Plan type A - if all the workloads are supported for the migration with Azure resource Movere then we good to go with just one plan as this will be straight forward migration with Azure resource Movere with forecasted downtime notified to the respective stakeholders/vendors/customers etc

 

• Plan type B- most of the resources are supported for the migration with Azure Resource Movere and few resources can't be moved with Azure resource Movere

This plan should contain a mix approach of the migration where we will be moving supported resources with ARM(Azure Resource Movere) and unsupported ones we will be reconfiguring

 

• Plan Type C- After creating the report mentioned in Assessment and discovery phase we got to know that most of the resources are PAAS kind of resources which are not at all supported for the migration with Azure Resource Movere hence we need to follow an approach of reconfiguring the resources.

In this plan its recommended to setup an environment in parallel while source is up and running in the CSP. This migration strategy can be called like setting up DR Environment (replica environment in same region) in parallel in the target subscription and once the same has been done plan the downtime, DNS switch and actual failover and cutover from source to the target.

 

RBAC check (To be done right after the destination subscription creation)

 

While doing EA enrollment in major scenarios organizations will keep the same Azure AD tenant. It is possible that the organizations might be going with different partner for the EA enrollment than the one who was managing the CSP. In this scenario customer might not want the CSP partner to have the access to the EA subscriptions. Below are the RBAC considerations to be followed in such scenario.

 

- While target subscription is being created check if there are root inherited access being created for the CSP partner in the target EA subscription, if yes please follow below steps for the same to be removed if customer don’t want to keep the access live for CSP partner in the EA subscriptions. This inheritance happens because partner has authorized their service principal at the root management group level which is the root tenant group and while CSP was setup those privileges were authorized to the partner Foreign principal.  In this way any new subscription that is being created in that Directory, CSP partners Foreign principal or allowed users will automatically have the owner access to the subscription due to delegated permissions given at the root management group level.

Please refer the article for understanding this more in details Delegated administration in Azure Active Directory - Microsoft Entra | Microsoft Learn

Obtain a customer's admin privileges - Partner Center | Microsoft Learn

 

Steps to remove the CSP partner inherited privileges from the new subscription being created in the EA

To address this, we will need global admin to review the roles assigned at the root management group. We can follow these steps to remove the assignments from root management group:

 

 

Look for Management group in Global Search and select the same. 

 

 

Under Overview, click on Root Management Group:

 

 

 

 

Go to IAM blade --> Role Assignments --> Select the identities with Owner access --> Click on Remove

 

 

 

 

 

 

 

Removing permission at the Root Management Group level will not have any impact on the existing CSP subscriptions apart from the delegated subscriptions rights being provoked and the partner will no longer have the inherited access to the newly created subscription in the EA.

You still need to work on ending the CSP relationship etc once the complete migration has been performed.  This is a business decision hence perform with caution Add, change, or delete a subscription advisor partner - Microsoft 365 admin | Microsoft Learn

 

Checklist before moving resources

 

There are some important steps to do before moving a resource. By verifying these conditions, you can avoid errors.

• The source and destination subscriptions must be active. The source and destination subscriptions must exist within the same Azure Active Directory tenant.

• The destination subscription must be registered for the resource provider of the resource being moved.

• If you move a resource that has an Azure role assigned directly to the resource (or a child resource), the role assignment isn't moved and becomes orphaned. After the move, you must re-create the role assignment. Eventually, the orphaned role assignment is automatically removed, but we recommend removing the role assignment before the move.
• Before moving the resources, check the subscription quotas for the subscription you're moving the resources to. If moving the resources means the subscription will exceed its limits, you need to review whether you can request an increase in the quota

 

Process of the Migration through Azure Resource Movere

• Validation: In this process before we perform the migration, we need to do the validation check through the Azure Resource movere tool itself. The first step here is to move all the dependent resources in the single resource group. This will need you to disable vnet peering if any before you can move the vnet across RGs hence your downtime consideration needs to be taken accordingly.
• Once you bring all the dependent resources to the single RG, run the pre validation before you can start the actual move operation

Both the source group and the target group are locked during the move operation. Write and delete operations are blocked on the resource groups until the move completes. This lock means you can't add, update, or delete resources in the resource groups. It doesn't mean the resources are frozen. For example, if you move an Azure SQL logical server, its databases and other dependent resources to a new resource group or subscription, applications that use the databases experience no downtime. They can still read and write to the databases. The lock can last for a maximum of four hours, but most moves complete in much less time.

If your move requires setting up new dependent resources, you'll experience an interruption in those services until they've been reconfigured.

• Changed resource ID

When you move a resource, you change its resource ID. The standard format for a resource ID is /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}. When you move a resource to a new resource group or subscription, you change one or more values in that path.

If you use the resource ID anywhere, you'll need to change that value. For example, if you have a custom dashboard in the portal that references a resource ID, you'll need to update that value. Look for any scripts or templates that need to be updated for the new resource ID.

 

 

Step by step process on the move operation

Move resources to a new subscription or resource group - Azure Resource Manager | Microsoft Lea

 

 

Scenarios not supported/Limitations/Crucial considerations

The following scenarios aren't yet supported:

• Virtual Machine Scale Sets with Standard SKU Load Balancer or Standard SKU Public IP can't be moved.
• Virtual machines in an existing virtual network can be moved to a new subscription only when the virtual network and all of its dependent resources are also moved.
• Virtual machines created from Marketplace resources with plans attached can't be moved across subscriptions. For a potential workaround, see Virtual machines with Marketplace plans.
• Low-priority virtual machines and low-priority virtual machine scale sets can't be moved across resource groups or subscriptions.
• Virtual machines in an availability set can't be moved individually.
• For AVD movement ensure all the host pools in the resource groups are belonging to the same location group or else the validation will fail and we wont be able to initiate the move
• Azure VPN Gws needs to be considered for reconfiguration as we can't move these. If you have a basic VPN gw created that is associated with Basic public IP that might get migrated with Azure resource Movere
• VMs that are attached std public ip they need to be disassociated before you can move this with Azure resource movere 

 

Summary

• Create different options and strategy for the approach of the migration and discuss the plan with the respective workload owners like Network, Database, application, security etc. and walk them through the report/Plan of action.
• Discuss the limitations, downtime, associated with each plan and conclude the plan that fits best to the customer's organizations goal.
• Have Support ticket proactively created and keep the support team on standby as a proactive measure
• Once the plan of action has been freezed, ensure a proper RACI Matrix is setup and all the required stakeholders are present during the migration
• Document the forecasted downtime
• Perform a complete post migration validation checklist (Involves application testing, user acceptance, DB, BCDR functionality etc)

 

 

Note: Would recommend to consider setting up parallel environment in the target subscription and plan the failover for mission critical production workloads where customers can't afford much of downtime as we might need additional downtime while using Azure Resource Movere in case the resources are stuck in the validation or during move operations.  At the other hand we have more control on planning the accurate downtime while we setup the parallel environment in the destination and perform the cutover