Atlassian is winding down Compass and redirecting customers toward DX Fabric, its new internal developer portal product. Compass has been closed to new customers since May 13, 2026, and Atlassian has stated that all access to the product will end on December 31, 2027.
That gives Compass users a fixed window to make a decision they may not have planned for. The catalog, ownership records, and health scorecards that live in Compass now have a shelf life, which forces a migration onto Atlassian's clock and a budget question at renewal. The sections below cover what Atlassian has officially confirmed, the sunset timeline, what is at risk in your environment, and how to weigh the replacement decision before it gets made by default.
What Atlassian said about Compass's future
Atlassian has officially confirmed that they are retiring Compass and consolidating its core capabilities, catalog and scorecards, into DX, an “AI-native intelligence layer”. Atlassian acquired DX in September 2025. The platform layer underneath is called DX Fabric. There are a few capability gaps between the two systems, outlined below:
All alerts and operations functionality, such as incident and on-call workflows, must be migrated to Jira Service Management, as it is not supported in DX.
When creating an alert or incident in Jira Service Management today, you will not be able to connect a DX entity as an affected service.
Jira Integration: Within DX, you can connect a Jira work item to an entity via alias. However, within Jira, you cannot connect a DX entity to a work item.
Scorecards don't sync into DX, and must be recreated after onboarding to DX.
For roadmap and migration planning, Atlassian is directing customers to its migration documentation in the Atlassian support center and to their Atlassian account team.
The Compass end-of-life timeline
There are two key dates to be aware of:
Compass is no longer available to new Atlassian customers as of May 13, 2026.
All access to Compass will end on December 31, 2027, the end-of-support deadline.
Atlassian says no immediate action is required and that existing customers can keep using Compass until then, but encourages all Compass customers to transition to DX for their catalog and scorecard needs.
However, customers interested in considering their full set of options rather than deferring to Atlassian’s default should begin their evaluations as soon as possible. That end-of-support date is a hard deadline; waiting until late 2027 compresses the evaluation and migration into the same crunch, and a source of truth for service ownership is not something you want to move under deadline pressure. Starting the evaluation now allows for a deliberate choice.
What's at stake in your environment
Everything Compass holds is affected. Service and component records, ownership assignments, health scorecards, and the on-call and incident context that sits alongside them all have a hard expiry now, with access to Compass ending December 31, 2027.
Different teams will feel these affects in different ways. The platform teams who built and maintain Compass face a migration project. SRE teams risk losing component health data and operational context mid-incident. Developers lose a daily reference tool, and leaders face a budget and vendor decision at renewal.
A forced migration is a forced decision. Skipping the evaluation is in itself a choice. The default path (accept DX, move the data over, and move on) is not the only option, and it is worth understanding what else if available before you commit.
Why the default move deserves a second look
Compass's own sunset is proof that betting an operational source of truth on a single vendor's portfolio roadmap carries risk, regardless of which vendor it is. The exposure is worse for a tool at the margins of a sprawling portfolio, where it competes for roadmap attention against far bigger products and usually loses out. Teams that built their ownership model and health scorecards around Compass must now re-platform on someone else's timeline. Moving straight into another single-vendor portal relocates that risk rather than resolving it.
DX Fabric is a capable successor. It absorbs Compass's catalog and scorecard functionality, adds AI-impact measurement, and comes from a company with a research pedigree in developer productivity. The question worth asking of any candidate, DX included, is whether you want your tools to not only see the full picture, but also close the loop and drive action by enforcing standards and routing fixes to an owner. Some tools are built to surface outcomes while others are built to drive change.
DX Pros & Cons
Pros:
SQL-powered scorecard rules give real flexibility for complex, cross-source checks
Scorecards and catalog manageable as code via the DX Terraform provider
Catalog imports components from Compass or Backstage, easing a migration
Full DevEx picture, see the "why" not just the "what” through developer surveys
Cons:
Every scorecard check is hand-written SQL, even simple ones like "has an owner," so authoring needs SQL fluency and concentrates in the platform/data team
Checks evaluate against data landed in the DX Data Cloud warehouse, not live at evaluation time, so you can only check what has already synced
Workflows front your CI by design: DX dispatches a single request to automation you build and maintain yourself, rather than orchestrating and enforcing policy natively
Limited paths from insights to action. Scorecard failures route to Initiatives (issues + notifications); no documented path for a failing rule to auto-trigger remediation or block a deploy
Configuration can be complex; some integrations still need manual setup
Reporting UX gaps: Overview view harder to read than the Insights tab; heatmap clarity limited
Another developer portal, or a platform built to run engineering operations
A sunset is a useful moment to ask a bigger question than "which catalog do we buy next." It is a chance to ask whether a catalog-and-scorecard tool was ever the whole job.
AI agents now write, review, and merge a growing share of code, which means the build half of engineering is getting more automated by the month. The half downstream of the code did not get faster to match: the review, testing, security checks, on-call, and cost controls that decide whether what shipped is actually safe to run. Those controls were built for human volume, and the time between an idea and a merged change has collapsed, so more change now lands on them faster than they were designed to absorb. In Cortex's 2026 Engineering Benchmark Report, pull request throughput and incident volume rose in close step, which is what it looks like when an organization starts producing software faster than it can safely operate.
As agents take on more of the line work, per-change human review stops scaling, and the place a person can still meaningfully steer moves up to the level of the whole system: the patterns and trends across the entire loop, and the decision about where to push and where to ease off.
That is the job a catalog-and-scorecard portal was never sized for. Steering the system depends on a live, automatically maintained record of every service, who owns it, and what standard it is held to, plus a way to act on what that record surfaces. This is the discipline of engineering operations: building the systems that let the engineering organization run fast without losing control. The forced migration for Compass customers is an excellent moment to consider upgrading from an internal developer portal to an engineering operations platform built to help engineering teams govern the next phase of the AI SDLC.
What to preserve when you migrate off Compass
Whatever you select to replace Compass must carry forward four things to preserve your existing capabilities:
Service ownership records
Dependency mapping
Health and scorecard history
On-call context
The Compass-to-DX path includes Atlassian's migration tooling, with a one-time sync that imports your components and a connector that keeps Atlassian Teams in step. That helps if you plan to stay inside the Atlassian portfolio. If you are evaluating a move off it, no non-Atlassian platform offers a native Compass importer, so the best question becomes which platform gets you back to full visibility fastest with the least manual re-cataloging. That makes migration a preservation-and-upgrade decision, not a data-transfer chore.
How Cortex maps onto the job Compass was doing
Cortex is the Engineering Operations Platform that runs mission control for the AI software factory. As the SDLC becomes more automated and engineers shift to designing and managing the systems that produce software, Cortex gives leaders the visibility, intelligence, and controls to keep teams shipping fast without runaway risk to reliability, security, and cost. It covers the jobs Compass did and extends past them.
From manual cataloging to automatic discovery
Where Compass relied on a manually maintained catalog, Cortex's Context Graph scans your repositories in the background as soon as the first integration is connected, mapping services, dependencies, and ownership automatically. For unowned services, AI-powered ownership prediction fills the gaps from repository activity. For a team migrating off Compass, that means the catalog rebuilds itself in days rather than the weeks a manual re-catalog would take, and it stays current as your environment changes, so nothing drifts between audits.
Scorecards that keep working after the migration
Cortex Scorecards codify your standards and grade every service against them continuously, in a define, assess, and improve loop. When a service falls short, Initiatives turn the gap into a tracked campaign with an owner, a Jira ticket, and a deadline, so standards keep getting enforced rather than checked once and forgotten. For the transition itself, you can run a migration and modernization scorecard that tracks each service's progress off Compass and onto its replacement, giving platform leads a live view of who is done and who is behind.
The Engineering Intelligence layer Compass never had
Compass answered "what do I own." Cortex's Engineering Intelligence answers "how is the organization doing." It rolls data from 50-plus integrations, including GitHub, PagerDuty, Datadog, and Jira, into a view of velocity, reliability, and AI adoption, in terms an engineering leader can take into a business review. That capability feeds the DRIVE framework, Cortex's model for measuring engineering effectiveness in the age of AI across five pillars: delivery, reliability, initiatives, vigilance, and efficiency.
Proof: teams that treated a platform shift as an upgrade
A Compass migration is coming whether you planned for one or not. This transition is an opportunity to implement more than a replacement portal: a system that keeps ownership current, enforces standards automatically, and closes the gaps the old setup left open.
Rapid7 used Cortex to migrate 3,000 RDS instances in under two weeks, turning a project that would normally sprawl across quarters into a tracked, per-team effort with a clear finish line. Archer packaged its golden paths into self-service Workflows and now saves roughly 24 hours per new service, taking a service from concept to deployed in under three hours. H&R Block used Cortex to cut MTTR from as much as 24 hours to under one, and to remove days of manual seasonal prep work for senior leadership.
See what Cortex surfaces about your own catalog, ownership, and standards in a live demo.
FAQs
Will Atlassian force existing Compass customers onto DX, or is there a way to stay on Compass longer?
Atlassian is not forcing an immediate move. Existing customers can keep using Compass until their contract ends or until end of support on December 31, 2027, whichever comes first. Atlassian is strongly encouraging customers to transition to DX for catalog and scorecard needs, but DX is the recommended path, not the only one. Nothing stops you from evaluating a non-Atlassian platform in the same window.
What happens to on-call and incident workflows currently configured in Compass?
These do not move to DX with the rest of your Compass data. Atlassian's supported path routes alerts, on-call schedules, and incident response to Jira Service Management. If your Compass usage is centered on incident workflows, treat that as a separate migration track with its own owner and timeline, because it lands in a different product than your catalog and scorecards.
Is DX included in existing Atlassian licensing, or does it require a new purchase?
DX is a cloud-based subscription and is not automatically bundled into current Compass or Jira licensing. Plan for a commercial conversation with your Atlassian account team as part of the transition, and factor a potential new line item into your renewal budget. Confirm the specifics for your contract directly with Atlassian, since terms vary.
How does a service catalog and ownership migration actually get planned, and who should own that project internally?
A platform or DevEx team should own the project, since they understand the current data model and the dependencies on it. Start by inventorying what lives in Compass: services and components, ownership assignments, scorecard definitions and history, and any on-call context. Decide what has to carry forward and what can be rebuilt cleaner. Then run the old and new systems in parallel to validate data parity before you cut over.
What is the difference between an internal developer portal and an engineering operations platform in practice?
An internal developer portal centers on developer access: a catalog, documentation, and self-service scaffolding, answering "what do I own and where do I find it." An Engineering Operations Platform covers that and adds the operational layer on top: automated standards enforcement, org-level intelligence on velocity and reliability, and the ability to run cross-team initiatives and migrations as tracked programs. The portal shows developers their services. The platform tells leaders whether the organization is meeting its bar, then turns each gap into tracked work with an owner.
How long does it typically take a platform team to get full visibility into services and ownership on a new tool?
It depends on how much manual cataloging the tool requires. Platforms that rely on manual entry can take weeks to months to reach parity with an existing catalog. Platforms with automatic discovery populate much faster: Cortex, for example, begins mapping services and ownership as soon as the first integration connects, with most teams seeing usable data within the first sprint. Full value, with custom integrations and mature scorecards, takes longer and scales with the complexity of your environment.
---
Facing a Compass migration and want to see what an upgrade looks like instead of a lateral move? Book a demo and we'll map your Compass catalog, ownership, and scorecards onto Cortex.
