Forum Discussion
Completely migrate DevOps Organisation to new Tenant and Subscription
Hi,
hope this question besides here.
Can anyone confirm the steps needed to completely migrate a DevOps Organisation to a new Tenant and Subscription.
The first steps are obvious:
- Prepare new AD Tenant
- Switch AD Connection (Switch to another Azure Active Directory - Azure DevOps Services | Microsoft Learn)
Currently there is a MPN Subscription in use (also for DevOps billing) even with that i don't see problems, as we could change the billing Sub to f.e. a PAYG Sub during Migration.
The main concern is about whats "inside" our projects:
- We use ServicePrincipals for deploying into AppServives and others
- We have some service connections to GitBucket and other
Even if the change to the new AD Tenant and billing Subscription goes smooth
We would need to recreate all ServicePrincipels at the point we would migrate our AppServices and other services in to a subscription within the new tenant?
Even if we migrate out MPN Subscription (via support case) we would need to create all needed SP in the new tenant and modify the pipelines which use them.
Are we correct?
Did anyone else a migration like this on?
Appreciate all your feedbacks
Regards,
Ben
- Coming back to my own request.
We've done the migration last week and it was quite smooth.
With the help and steps described here: https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription we were able to reactivate most of the pipelines and resources without problems.
KeyVault was a bit specific but once done like described it worked again immediately.
The big work was at customer site to modify all pipelines with the new ServicePrinciples.
Ben
- Coming back to my own request.
We've done the migration last week and it was quite smooth.
With the help and steps described here: https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription we were able to reactivate most of the pipelines and resources without problems.
KeyVault was a bit specific but once done like described it worked again immediately.
The big work was at customer site to modify all pipelines with the new ServicePrinciples.
Ben- Thanks for your post, Benjamin. We are about to embark on a tenant-to-tenant migration where all Azure DevOps and microservice components exist within the source tenant - so no external companies/customers/security contexts involved. Would that have changed your approach?
Hi David,
I don't think that would have changed our approach.
If you do a tenant-to-tenant migration and DevOps also uses Azure resources (WebApp, StorageAccount, KeyVault, ecc) you still have to do the same steps.
If it helps you, these were roughly our steps (keep in mind that in this case we also did an Office 365 migration)
- Prepare the users in the new tenant
- Change the AAD connection for DevOps (https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/change-azure-ad-connection?view=azure-devops)
- UserMapping after migration in DevOps
- Document all RBAC, Roles, ecc. as described here: https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription
- Migration of the subscription to the new tenant
- Restore RBAC, KeyVault, StorageAccount accesses in the new tenant
- Re-create all ServicePrincipals in DevOps and adjust the pipelines
Regards,
Ben
Benjamin Graus Thanks for sharing. I'm still not sure about one thing. If you don't migrate Azure subscription to other tenant, would you still need to recreate Service Connections? Let's say my setup is:
- Azure Tenant 1-- Azure Subscription 1
-- Azure DevOps 1
--- Service Connection to Azure Subscription 1
--- Service Connection to Azure Subscription 2
- Azure Tenant 2
-- Azure Subscription 2
- Azure Tenant 3
I'd like to migrate Azure DevOps 1 to use Entra ID of Azure Tenant 3. Will my two Service Connections continue working?
Hi AlexKuk ,
I'm not sure about this. But I think that the ServiceConnections are still in place - even if you change the EntraID Tenant for the DevOps Org. As they are setup on "another" level.
Maybe set you up a quick test DevOps Org and try it before you move the prod Org.
Regards
Hello Benjamin,
Thank you very much for sharing your experience on this migration.
I'm going to embarque on similar approach but I'm also still beginner in Azure DevOps administration.
Especially now that they have introduce Microsoft Entra to replace AD.
I have one question.
I have actually a Azure DevOps Service setup with that mainly use Azure DevOps for its work items (we will introduce later, repository and pipeline and test plan) with a specific tenant.
- Azure Subscription
- Azure DevOps service (Visual Studio Online seen in resources in Azure subscription) and located in https://dev.azure.com/XXXXX (XXXXXX being by organization)
Now we have merged activitiy with a new customer that has his own Azure
- Azure Cust (but they have no subscription)
I think my point is, in your steps that you cited:
- Prepare the users in the new tenant
- Change the AAD connection for DevOps (https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/change-azure-ad-connection?view=azure-devops)
- UserMapping after migration in DevOps
- Document all RBAC, Roles, ecc. as described here: https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription
- Migration of the subscription to the new tenant
- Restore RBAC, KeyVault, StorageAccount accesses in the new tenant
- Re-create all ServicePrincipals in DevOps and adjust the pipelines
1. As there are no use of Pipeline or REpository would we need still to restore the KeyVault, storage account?
2. Also all the work item you have created, were you able to keep all of them and all their history? even if the user are do no longer exist with the previous tenant and AD?
3. when you have changed the directory to the new directory, weren't there any trouble as the Subscritpion were not yet move to the tenant yet?
4. How did you perform the Subscription to the new tenant? have you used the Azure Portal to do so?
Hello Benjamin Graus ,
All the migrations I have done in the past involved Support teams. It could be really delicate in terms of user account (in new and old tenant), user/team related queries, dashboard, boards, permissions... and service connections. Support could help you link new user acccounts with old ones, not to loose track of history changes. My guess is you need to recreate every service connection (that is what I remember, did my last one 4 years ago), that cannot be migrated to new AD. I would involve Support 100% in the process.
