Usually the system being migrated away from.
Azure DevOps provides work tracking, repositories, and pipelines. Our work is migrating work, code, and pipelines into the Atlassian estate with the access model redesigned.
Azure DevOps holds work and pipelines in estates consolidating onto Atlassian. The migration is straightforward. The access model is the part worth designing.
What it is
Azure DevOps provides work tracking, repositories, and pipelines. In our engagements it is most often a source rather than a destination, as organizations consolidate delivery onto one estate.
What it does
Work, code, and pipelines together
Which is why migrating it is a multi-workstream exercise rather than a data copy.
Its own access model
A second permission model to maintain, and a second one to review.
Where it fits
L2, platform and migration. It is part of the system of work. Consolidating it removes a second access model and a second set of pipeline credentials, which is usually worth more than the tooling consolidation itself.
What we do with it
Migration into the Atlassian estate
Work items, repositories, and pipelines, with the access model redesigned rather than replicated.
Pipeline credentials as identities
Build credentials hold wide scope and belong in the same review as every other identity.
Connecting delivery to change control
Where a release needs an approval record, the systems have to agree on what approved means.
Where it earns its place
An organization consolidating delivery tooling
Two estates after an acquisition is the common trigger.
An estate with pipeline credentials nobody reviews
The migration is the moment those get inventoried.