Why do we need Collection Admin role on the Target Project?

[daryllmamaril]

Hi Team!
How are you all? Can someone please help and explain

1.) Why do we need a Project Collection Administrator Role on the Target Organization? I'm getting a push back, because the organization where we would like to migrate our project to is used globally. I don't really know how to explain properly why I need this access. The only thing I can think of is because of the PAT Token??? I have looked at the docs and couldn't find an explanation regarding the permissions, unless i missed it. Is there a work around, if in case they refuse to give me the Collection Admin role on the Target Organization?

2.) What are the permissions needed on the source? Is being a project Admin on the projects to be migrated sufficient?

Thanks in advance for all your help!

[MrHinsh]

@daryllmamaril there is one good reason and one bad reason that we recommend Project Collection Administrator

The bad Reason

We use the "Bypass Rules" and for most people, it's just easier to have Admin than to mess around with the individual permissions required to get it.

The Good Reason

If there are any "Denied" marked in the system for Area paths, or in other locations that we are accessing you will be blocked and will not know why. Project Collection Administrators bypass all "Denied" that are set.

note: Denied is a bad practice and not recommended anyway, but tones of folks that have not read the documentation for Azure DevOps think that it works differently to how it does.

What are the permissions needed on the source? Is being a project Admin on the projects to be migrated sufficient?

For the Source all you need is read access.

[daryllmamaril]

@MrHinsh thank you so much for the explanation. Really appreciate it! Hope I can convince our global admin to give me this access.

[MrHinsh]

If they refuse then you can still use the tool, there is just a risk of exceptions.