Atlassian Compass Sunset: What to Export and Where to Move

Atlassian is phasing out Compass. Existing access is planned to end at the end of your contract or when Compass support ends on December 31, 2027, whichever comes first. This is not a one-destination migration: catalog and scorecard work moves toward DX Fabric, while Compass operations capabilities such as alerts and on-call move to Jira Service Management.

If your team uses Compass today, start by inventorying which capabilities you actually depend on, then map each one to its destination and identify what Atlassian does not move automatically.

The short version

• Software catalog and component metadata: transition to DX Fabric.
• Scorecards: recreate them in DX; Atlassian says Compass scorecards do not sync automatically.
• Atlassian Teams: sync into DX, but review membership and team-lead assignments because the team model is not identical.
• Dependencies: imported into DX as relations.
• Alerts and on-call: move to Jira Service Management, not DX.
• JSM affected-service links: test them. Atlassian currently documents a gap where a DX entity cannot be selected directly as an affected service in a JSM alert or incident.
• Custom Forge apps: reassess them. DX is not currently supported inside Forge; Atlassian points customers to the DX API for custom catalog access.

Compass transition checklist

1. Inventory what Compass is doing for you

Do not start with the product name. Start with the jobs your organization has assigned to it. Inventory components and types, custom metadata, owners and team relationships, dependencies, scorecards, metrics, on-call schedules, alerts, Jira links, dashboards, automation rules, webhooks, APIs, scripts, and Forge apps that depend on Compass.

The output should be a dependency map, not just an export file. A technically successful import can still break the operating model if a Jira board, automation, incident flow, or ownership process depended on a Compass relationship nobody documented.

2. Decide what belongs in DX Fabric

Atlassian recommends DX Fabric as the destination for software catalog and software-health capabilities. Its documented onboarding tooling imports Compass components and metadata, including custom fields, and recreates components as DX entities. Dependencies move into DX as relations, and Atlassian Teams can sync into DX daily.

3. Review the team-model differences before you sync

Atlassian documents two important differences: a person can belong to only one DX team, and every DX team must have a team lead. If someone belongs to multiple Atlassian Teams, the import assigns them to one DX team. The Atlassian Team creator is used as the DX team lead when possible, with another member substituted if the creator is inactive.

Before migration, identify shared or matrixed team memberships and decide what the authoritative ownership model should be. Otherwise a technically valid import can create a team model your engineering organization does not recognize.

4. Rebuild scorecards deliberately

Compass scorecards do not sync into DX. Atlassian says they must be recreated after onboarding.

Use that as a governance checkpoint. For every scorecard, record its purpose, owner, data source, threshold, exception process, and whether anyone still acts on the result. Rebuild the standards that drive decisions; retire the ones that became dashboard furniture.

5. Move operations capabilities to Jira Service Management

DX is not the destination for Compass alerts and operations functionality. Atlassian directs that work to Jira Service Management. If Compass is carrying on-call schedules, alerts, or operational service relationships, treat the transition as two connected workstreams: catalog and engineering health to DX; operations to JSM.

Atlassian says the JSM migration must begin before your Compass contract ends or before Compass support ends on December 31, 2027, whichever happens first.

6. Test the JSM/DX boundary

Do not assume every Compass-to-Jira relationship has a direct DX equivalent. Atlassian currently documents a gap: a DX entity can contain a link or alias to a JSM service, but when creating an alert or incident in JSM today, you cannot directly select a DX entity as the affected service. Compass services migrated into JSM can still be connected to alerts and incidents.

Walk through a real incident before cutover: affected service, on-call lookup, escalation, ownership, reporting, and post-incident analysis.

7. Audit custom extensions and automation

List every Forge app, automation rule, webhook, API integration, scheduled job, dashboard, and script that references Compass. DX has an API, but Atlassian states that DX is not supported within Forge today. “There is an API” is not the same as “our existing extension will keep working.”

For each dependency, choose one outcome: migrate, rewrite, replace, retire, or accept the gap temporarily with an owner and target date.

8. Use the overlap window for verification

Atlassian’s documented DX onboarding process includes a guided migration and one month of access to both DX and Compass after the initial transfer. Use that overlap for reconciliation rather than treating the import-success screen as acceptance.

What to export before you start

• Component inventory and types
• Custom field definitions and important metadata
• Component ownership and team relationships
• Dependency relationships
• Scorecard definitions, criteria, and current applicability
• Integration and automation inventory
• On-call and alerting configuration that must move to JSM
• A sample of Jira work items, incidents, dashboards, and reports that rely on Compass data

The point is not to build a museum of Compass. It is to have enough evidence to prove the new operating model contains what the old one actually needed.

Where each Compass capability goes

What not to do

Do not wait until the final contract quarter and call this a data migration. Compass may be the visible product being retired, but the real work sits in ownership, scorecards, automation, incident operations, and the system relationships built around the catalog.

Also do not rebuild every Compass artifact simply because it exists. A sunset is one of the rare moments when deleting an obsolete standard or integration is cheaper than carrying it forward.

Official Atlassian references

• The Next Chapter for Compass
• Migrate from Compass to DX
• Migrate from Compass to Jira Service Management

The Avaratak take

Start with the dependency map, not the destination product. If Compass is only a catalog, the transition can be relatively contained. If it has become the connective tissue between engineering ownership, scorecards, Jira work, and operations, you have an architecture change to manage.

Avaratak can help assess the Atlassian side of that transition, especially where Jira, Jira Service Management, service relationships, integrations, and governance meet the new DX model. Talk through the transition with a senior consultant.