SOLVED

Completely migrate DevOps Organisation to new Tenant and Subscription

Occasional Contributor

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:

 

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

 

 

 

4 Replies

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. 

best response confirmed by Benjamin Graus (Occasional Contributor)
Solution
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?vie...)
- 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