> For the complete documentation index, see [llms.txt](https://docs.getint.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.getint.io/guides/integration-synchronization/non-jira-connectors/azure-devops-to-azure-devops-integration.md).

# Azure DevOps to Azure DevOps integration

## Integrating Azure DevOps and Azure DevOps

Connecting two Azure DevOps organizations keeps work items aligned across separate environments. Teams often run more than one Azure DevOps instance after a merger, when working with an external partner, or when a business unit maintains its own organization with its own process template and permissions. This integration automates updates between both sides in real time, removing manual re-entry and reducing the risk of discrepancies across work items, statuses, comments, and attachments.

The same setup applies when both sides are hosted differently, for example, Azure DevOps Services (Cloud) on one side and Azure DevOps Server (on-premise) on the other.

### Azure DevOps Azure DevOps Licensing Model

The Getint licensing model for Azure DevOps and Azure DevOps focuses on predictable costs and scalability:

#### Standard Licensing

* This tier covers a direct integration between one Azure DevOps instance and a second Azure DevOps instance for a fixed fee. It includes unlimited project and work item synchronization without hidden charges.

You can find more information about our pricing structure here: [Getint Pricing](https://www.getint.io/pricing).

#### Network License

* Designed for managed service providers or large organizations, this option supports three or more instances. It allows for a specific number of connections (e.g., up to 10 instances) and provides the flexibility to swap integrated tools while the license is active.

For more details on licensing, visit our [Licensing Page](https://docs.getint.io/billing-and-services/licensing).

### Requirements to Build Your Integration:

* **Deployment Options**: Getint provides two ways to host your integration: a managed [SaaS platform](https://app.live.getint.io/) or a self-hosted On-premise version. More information about Getint On-premise [here](https://docs.getint.io/getting-started-with-the-platform/deployment-options/on-premise-deployment).
* **Authentication**: Both Azure DevOps organizations require a Personal Access Token to establish a secure connection. You can find the steps to generate the access token for your connectors here: [Connection Guide](https://docs.getint.io/guides/quickstart/connection).
* **Service Accounts**: Because the integration attributes comments to the user who created the connection, we recommend using dedicated Service Accounts in both organizations to maintain a clear distinction between automated updates and individual user activity.
* **Process Templates**: Work item types and states depend on the process template of each project (Basic, Agile, Scrum, or CMMI). Check the template used on each side before you map types and statuses, since the available values may differ even though both applications are Azure DevOps.

### Setting Up Your Azure DevOps Azure DevOps Integration

#### 1. Access the Getint App

* Log in at [app.live.getint.io](http://app.live.getint.io/). If you do not have an account, click **Sign up** to create one.
* Enter your details, select the apps you want to connect, and click **Create new workspace**.
* After you create the workspace, go to it to launch Getint.

#### 2. Create an Integration

* Go to **Workflows** (lightning bolt icon) and click **Create Integration**. From this menu, select **Continuous Sync** or **Data Migration**.

#### 3. Generate an Azure DevOps Token

To integrate Azure DevOps (Server or Cloud), you must provide a token with the necessary permissions. Repeat these steps in both organizations so that you have one token for each side of the integration:

* Log in to your Azure DevOps organization.
* Open **User Settings** from the profile menu.
* Select **Personal Access Tokens** from the left sidebar.
* Click **New Token** and enter a name for the token.
* Set the expiration and select the appropriate scopes:
  * **Work Items**: Read & Write
  * **Project and Team**: Read & Write
  * **Graph**: Read (required for accurate user data retrieval)
  * **Code**: Read (if you're syncing repositories with the Git Connector)
* Click **Create**, then copy and securely store the generated token. This token authenticates and authorizes Getint to access your Azure DevOps organization.
* When configuring the Azure DevOps connection details in Getint, provide the generated token as the password.

{% embed url="<https://www.loom.com/share/de71aa8b806340039b5931b0c9c4c74d>" %}

{% hint style="info" %}
A token is scoped to the organization where it was created. A token from the first organization will not authenticate the second one, so generate both before you start.
{% endhint %}

#### 4. Connect to the First Azure DevOps Organization

* Click on **Connect App** and choose Azure DevOps, then select **Create a new connection**. Enter the URL for the connection and click **Next**.
* Provide a name for the connection, enter your email, and paste the token generated in the previous steps. Click **Add** to complete.
* Once the connection is established, select the Azure DevOps project(s) you want to synchronize from the dropdown menu and click **Connect**.

{% hint style="warning" %}
Give each connection a name that identifies its organization, for example, *ADO Production* and *ADO Partner*. Both sides appear as Azure DevOps in the integration view, and clear names prevent you from configuring the wrong side.
{% endhint %}

#### 5. Connect to the Second Azure DevOps Organization

* On the right side of the integration, click on **Connect App**, choose Azure DevOps, and select **Create a new connection**. Enter the URL of the second organization and click **Next**.
* Provide a name for the connection, enter your email, and paste the token generated for that organization. Click **Add** to complete.
* Select the project(s) you want to synchronize and click **Connect**.

#### 6. Configure Type Mapping

* **Quick Build**: Automatically map fields and types between applications with this feature.
* **Manual Mapping**: Use this feature for full control over the integration. Select **+ Add Type Mapping** to define how your types map between systems. This could include:
  * Azure DevOps *User Story* → Azure DevOps *User Story*.
  * Azure DevOps *Bug* → Azure DevOps *Bug*.
  * Azure DevOps *Task* → Azure DevOps *Task*.

When both projects use the same process template, types usually map one to one. When the templates differ, map the closest equivalent instead, for example, Scrum *Product Backlog Item* to Agile *User Story*.

#### 7. Item Routing

If you selected multiple projects on either or both sides, you must define Item Routing. All relevant information about defining conditions is here: [Syncing Many Projects](https://docs.getint.io/getintio-platform/syncing-many-to-many-projects#defining-conditions-in-items-routing).

#### 8. Field Mapping

* Review or manually map fields within mapped types, including **title**, **description**, and **assignees**.
* Define the synchronization flow for each field, using the arrows in the middle and selecting **Apply**.

Custom fields are defined per organization. A field that exists on one side is not created automatically on the other, so add the matching custom field in the second organization before you map it.

{% hint style="warning" %}
**Inline images** aren't supported for the **Description** field.
{% endhint %}

#### 9. Assignee Mapping

* Use the assignee mapping option to match assignees between both Azure DevOps organizations. For more details, visit our doc: [Assignees (users) mapping](https://docs.getint.io/getintio-platform/workflows/assignees-users-mapping).

Users are mapped by their account in each organization. If the same person uses a different email address in each one, map the two accounts manually.

#### 10. Status Mapping

* Map status fields to align both Azure DevOps projects. For example, *New* could be mapped to *New*, *Active* to *Active*, and *Closed* to *Closed*.
* When the projects use different process templates, map the equivalent states instead, for example, Agile *Resolved* to Scrum *Done*.
* You can also configure the status direction to support unidirectional transitions instead of bidirectional updates.

#### 11. How to Manage Comments & Attachments:

* Comments are enabled by default. You can configure these settings to match your organization's needs, such as selecting unidirectional or bidirectional sync and filtering by criteria like creation date, author, or visibility (public/private).
* To synchronize attachments, toggle on the **Synchronize attachments** setting and choose the sync direction.

#### 12. Advanced Tab

* Enable **Customize create/update actions** to manage item synchronization. This allows for specific rules, such as one-way creation for the left application combined with bidirectional updates.

This setting is useful between two Azure DevOps organizations when one side owns item creation and the second side only receives updates.

#### 13. Filtering:

It is possible to filter the synchronization to customize it for your needs and requirements. Please see the doc [Items Filtering](https://docs.getint.io/getintio-platform/workflows/items-filtering) for more details.

**UI Filtering Option:**

* Click on the filtering icon near the app icon in your integration. This will apply to that side of the integration.
* Select whether the filtering applies to *All*, *New*, or *Synced* items.
* Note that if the option **New items** is selected, the filtering will apply only to the new items, and the already synced items will continue to sync and update. If the option **Synced items** is selected, only the already synced items will be updated based on that filter.
* Choose the options and add the value for the filter. It is possible to filter more than one option for each field.
* Select **Apply** after creating the filters and **Save** the integration.}

#### 14. Test the Integration

* Create test work items in either Azure DevOps organization and observe how they synchronize.
* Confirm that the data between the two organizations is correctly synced.
* Monitor the integration status and the logs in Getint to verify that everything functions as expected.

### Conclusion

Following this guide lets you set up an Azure DevOps to Azure DevOps integration with Getint. This configuration supports data synchronization of work items, statuses, and comments across two separate Azure DevOps organizations, allowing teams to collaborate while each side keeps its own projects, process templates, and permissions.

For further assistance, please contact us at the [Support Center](https://getint.io/help-center) or [Schedule a Demo](https://calendly.com/d/cpws-jb2-8xx/demo-call-all-team).

<figure><img src="https://4106311246-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MR6Z9V8zLATPQPOGSDf%2Fuploads%2F9OSEDBl869gRue9mQAwv%2FGetint%20Yellow%20Banner.png?alt=media&amp;token=9cc42142-6e48-4931-8fd5-cbf7dcf4cdc1" alt=""><figcaption><p><a href="https://calendly.com/d/cpws-jb2-8xx/demo-call-all-team
">Start your integration journey. Schedule a free consultation with our Getint Integration Expert today!</a></p></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.getint.io/guides/integration-synchronization/non-jira-connectors/azure-devops-to-azure-devops-integration.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
