CODEWITHSUNDEEP
azure-devopsazure-pipelinesazure-pipelines-release-pipelineazure-reposazure-boards
jmzagorski
jmzagorski

Reputation: 1155

Move multiple Azure Devops projects into one project (same org)

I am in an enterprise that creates many large to small scale applications. Way back when I started using Visual Studio Online/VSTS/now Azure devops I broke all of these apps out into different projects. However, now it seems there is good support for managing multiple apps in one project, and this seems easier from a management standpoint.

From the research I did it seems i can do each service individually:

  1. Repos: Select Import Repository from the consolidated project and enter in the URL of the app i want to import BEWARE

Also, the system automatically resets the State and Reason fields to the default initial values for the work item type that you move.

and I skimmed over the docs and missed that snippet. oops

  1. Boards: Go to query (optionally select query across project) and move all items to the consolidated project (creating the appropriate teams, areas and past sprints to keep history)
  2. Builds: Export json from source projects and import to consolidated project
  3. Releases: Same as Builds

(we do not use test plans or artifacts at the moment)

Doing it this way I probably will loose build and release history, which is probably not a big deal once enough time passes, but I did not find any other good way.

My two questions are:

  1. Are there better guidelines to move entire projects to one project?
  2. Will I permanently or temporary loose anything else besides the build and release history that I am not realizing?

Upvotes: 3

Views: 4312

Answers (1)

Bevan
Bevan

Reputation: 1424

I went through the same thing and had to do what you described. At the time there was no support for moving services/functions between Projects or Orgs at all, let alone consolidating into a single Project. Unless something's changed, short of automating via your own API scripting it's all manual.

The other watch outs were mainly around access and security:

  • External API integrations such as Web Apps, Function Apps, JIRA, Service Now
  • External inbound app authorisations
  • External outbound app authorisations such as Azure Service Principals
  • Variable Group authorisations to YAML Build Pipelines
  • Library reference updates including KeyVault
  • etc

This refactoring ended up being much more work than the platform consolidation itself.

Upvotes: 1

Related Questions