Forum Discussion

Benjamin Graus's avatar
Benjamin Graus
Brass Contributor
Oct 17, 2022
Solved

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 (https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/change-azure-ad-connection?view=azure-devops)

 

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

9 Replies

  • Hi Benjamin Graus​

    Thanks for laying it out so clearly. This kind of tenant and subscription migration in Azure DevOps can get tricky, especially when it comes to service principals and pipelines. 

    A few things to keep in mind before making the move: 

    • User and service principal identities stay behind: When you switch Azure AD tenants, most of the user and service principal identities won’t carry over. You’ll need to recreate them in the new tenant.
    • Billing is the easy part: Changing the subscription (like from MPN to PAYG) is usually straightforward. The real work is on the identity and project content side.
    • Service connections are tenant-specific: Connections to App Services, GitBucket, etc., will need to be reconfigured— because they’re tied to SPNs from your old tenant.
    • Pipelines may break: If your pipelines use those old SPNs, you’ll need to update them with the new ones after migration.
    • Audit and traceability: Be careful during the switch —rebuilding things manually can leave gaps in traceability and version history. 

    So yep, your assumptions are pretty spot on: 

    • You’ll need to recreate service principals in the new tenant.
    • Service connections and pipelines will need to be updated to reflect the new identity and permission structure. 

    However, if you're looking to save yourself from a lot of manual work (and some post-migration surprises), you might want to check out OpsHub Migration Manager for Microsoft Azure DevOps (OM4ADO).  Co-built with Microsoft for no downtime, no disruptive and full fidelity migrations between Microsoft tools.  

    Hope it helps!

  • 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
    • Chan-Dara's avatar
      Chan-Dara
      Copper Contributor

      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?

       

    • AlexKuk's avatar
      AlexKuk
      Copper Contributor

      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?

      • Benjamin Graus's avatar
        Benjamin Graus
        Brass Contributor

        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

         

         

    • DavidAtTrupp's avatar
      DavidAtTrupp
      Copper Contributor
      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?
      • Ajay_Kumar_Ghose's avatar
        Ajay_Kumar_Ghose
        Brass Contributor
        Hello DavidAtTrupp, we are require to migrate our all projects from Azure devops to another tenant.. What are the perquisites we would require . Could you please guide me ..TIA
  • 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. 

Resources