One of the benefits of today’s cloud-based world is portability. The ability to easily move full application environments around in the cloud can be both positive and negative. This portability can create a “casual” attitude about events such as moving full “production” environments around. This casual attitude can lead to modern day catastrophes with big consequences. One of these events is the movement of an Azure Subscription from one Azure Tenant to a completely different Azure Tenant.
For those who are not familiar with the Microsoft Azure Cloud structure, these terms might require a brief introduction before we dig into the details. An Azure Tenant is a enterprise/corporate level structure that includes the use of an Azure Active Directory. This “Tenant” also holds all the accounts and billing connections for the services that are being used in Azure for the enterprise. A subscription is a private allocated space with a unique ID under the Tenant where it was created. The subscription will hold all the resources that are being used in the cloud, such as VNets, VMs, Databases, PaaS services, etc.. Sometimes in the life of a subscription is the need to transition that subscription to a different enterprise/corporate Tenant throughout the subscription. This requirement can be generated as a result of many different scenarios, from merger and acquisitions to one firm developing a solution in their subscription and then transitioning that solution to their client.
We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
When you are considering this kind of transfer here are a few high-level things to keep in mind. I have provided a link at the end of this blog to download a more detailed checklist.
Prior to the transfer
- Be sure to review all of the components to determine if they are still needed. This especially true when the subscription includes some development or testing environments. Ideally, this is being done on a regular basis through normal operational processes, but we all know how that goes with development environments.
- Pull together any and all documentation that you have on the solution and components within the subscription. Architecture drawings – application, network, integration, etc.; disaster recovery plans, account listing – users, service, permissions; resource listing – PaaS services, VMs, VNets, databases, marketplace items, etc.
- Read all of the reference postings from Microsoft regarding the transfer of subscriptions.
- Determine if someone from one of the enterprises or Microsoft is going to execute the transfer.
Day of Transfer
- Establish a conference call of some kind with all appropriate parties from both the source and target tenant enterprises.
- Make sure all key individuals are on the call before starting the transfer. Owners/operators of the subscription resources and applications need to be on the call from both enterprises.
- Validate all pre-requisite transfer items were completed.
- Be sure everyone is aware that this process might take several hours to complete depending on many different factors including all Post Transfer activities to be completed.
- Verify accessibility to all major resources in the subscription as an owner.
- Validate correct production operation of all applications within the subscription.
- Confirm ability to see billing information in the Enterprise Azure Portal.
The transfer of a subscription and the resources included can be a very powerful tool in your cloud toolkit. It is one of those tools that is very powerful but can also be a big problem if not executed properly. I hope you have found this blog to be helpful as an introduction to this powerful tool. To guide this work a Subscription Transfer Checklist was created that provides a lot more details around each part of a transfer project. Many line items are “optional” depending on the configuration of the subscription being transferred. Click here for a reference Subscription Transfer Checklist.