Sync Jira issues and Azure DevOps work items: evaluation checklist

Development visibility or two work records?

The official Azure DevOps integration documents deployments, builds, branches, commits and pull requests in Jira. If that is your requirement, begin there. If your team maintains an Azure Boards work item and a separate Jira issue, list the fields and directions that must be synchronized.

Keelcroft's published app connects one Jira Cloud project to one Azure DevOps project. Its production release covers titles, mapped states, tags/labels and an optional plain-text description. Later development features are not part of this checklist.

Prepare access, not a token in an email

You need Jira installation/configuration permissions and authorized Azure DevOps project access. The app supports a personal access token with Work Items read/write and Service Hooks read/write/manage, or a configured Microsoft Entra service principal. Ask your administrator about organisation policies and the appropriate least-privilege identity.

Store credentials directly in the app, never in an email or recording. Create a nonsensitive test issue and work item. The publisher has not independently completed a real Azure DevOps round trip, so validate your configuration on a test project before relying on it.

Map states before you enable both directions

1. Save the Azure DevOps organisation/project connection in the Jira project's app settings.
2. Store the credential and run the setup check. It creates, reads and attempts to remove a disposable work item; follow any cleanup result.
3. Start with title sync and a reviewed state map. Keep descriptions off unless a plain-text projection is appropriate.
4. Explicitly map the state names used by your Azure process and Jira workflow. Do not assume identically named states have identical business meaning.
5. Enable sync and link an existing Jira issue to an existing Azure DevOps work item.

Read both platforms to verify the outcome

Edit the title in Jira and independently open the work item in Azure DevOps. Repeat in reverse. Test mapped transitions separately, including any required Jira transition permissions or Azure process rules. Inspect the reconciliation result rather than treating a successful HTTP write or install as proof.

Azure work-item writes include the revision read by the app, so a concurrent update can make a write fail instead of overwriting newer data. Genuine conflicting field edits follow the chosen policy and are reported; equal-timestamp conflicts are held.

Know the production limits

Jira labels cannot contain spaces; incompatible Azure tags are reported rather than rewritten. Plain-text description transfer flattens receiving-side formatting. Do not assume production support for rich HTML, files, comments, assignee matching, native priority or the newer backlog-import candidate.

The ordinary sync does not mirror issue deletion. The separate setup check is an exception for its disposable test work item. Server-host configuration is not a claim of independently verified Server compatibility. For help, share the failed step and a redacted error without secrets or work-item content.

Decide using your own test result

Proceed only if the app covers your required scope and your first real test works. Check the Marketplace calculator for the licensed Jira site size; the number of people in the connected project is not necessarily the billing tier. A standard evaluation is not a paid subscription or a completed rollout.

Reference: Official Azure DevOps development and deployment integration. This guide describes Keelcroft's public foundational workflow and states candidate/live-testing boundaries separately; it is not a competitor benchmark or certification.