Atlassian Compass alternatives, 2026
NOFire AI
What should we migrate to before Atlassian Compass reaches end of support?
Atlassian Compass reaches end of support in December 2027. NOFire AI replaces it with a catalog built from production signals rather than declarations, which means the migration carries no YAML and no re-declaration project.
At a glance
| Atlassian Compass | NOFire AI | |
|---|---|---|
| Product status | End of sale 13 May 2026, end of support 31 December 2027 | Active development, no end-of-life date |
| Catalog data source | compass.yml committed to each repository | Observed from DNS and L7 call graphs, Prometheus rules, CI/CD and incident history |
| New service discovery | Appears once somebody writes and merges a descriptor | Appears once it is running and carrying traffic |
| Atlassian integration | Native across Jira, Confluence and Bitbucket | Standard webhooks and API, no first-party Atlassian surface |
| Scorecards | Rule-based checks against declared YAML fields | Four fixed binary checks against live production signals |
| Self-service scaffolding | Templates removed 1 December 2025; read-only catalog since | Not offered |
| SSO and SCIM | Requires a separate Atlassian Guard subscription | Included |
| Blast radius | Dependency tracking, no blast radius figure | Calculated over the observed dependency graph |
| Cost of staying put | Zero until the deadline, then unsupported | Not applicable |
Why teams look for an alternative
The deadline is the reason this page exists, so here are the dates. Atlassian ended Compass sales on 13 May 2026. Support ends on 31 December 2027. Until that date Compass keeps working and keeps receiving patches.
That timing lands badly for one group in particular. Teams who moved from Opsgenie to Compass are being asked to migrate a second time inside a few years, to a destination Atlassian has not named for them. The reasonable reaction to that is a preference for something that will not schedule a third migration.
Underneath the deadline sit the reasons people were already looking. Compass registers a service when somebody commits a compass.yml, which means the catalog reflects the subset of production that a person remembered to declare, and drifts from there. Scorecards built on that data report confidence about readiness rather than readiness.
The product also narrowed before it was retired. Scaffolding templates were removed on 1 December 2025, leaving a read-only catalog, and SSO with SCIM provisioning sits behind a separate Atlassian Guard subscription that was rarely in the original budget.
Where the current tool still wins
The strongest argument for Compass is that you already have it and the clock has not run out. Eighteen months is enough time to evaluate three products properly, and a rushed migration to the wrong destination costs far more than the remaining supported life of the thing you are on. Panic is the expensive option here.
The Atlassian integration is genuinely hard to replace while it lasts. If your services, their documentation and their work all live in Jira, Confluence and Bitbucket, Compass sits natively inside that and shows the connections without any wiring. Nothing outside the Atlassian estate reproduces that, ours included.
It is also worth being clear about what Compass is and what we are. Compass is a developer portal. If the portal itself is what your organisation values, the honest replacements are Port or Backstage, not this. A derived catalog answers what is running, who owns it and what breaks when it fails. It does not give developers a place to go and do things, and if that is what stops working in 2027, we are not the answer to it.
How to switch
Use the time. Decide first whether you are replacing a portal or replacing a catalog, because those lead to different shortlists and the deadline pressure tends to blur them.
If it is the catalog, the useful test is one you can run this week. Connect a derived catalog to the same environment and count three things: services running in production with no compass.yml, descriptors naming an owner who has left, and declared dependencies carrying no traffic. The derived catalog produces all three directly. Those numbers tell you how much of your current catalog was ever true.
There is no migration to plan. Nothing reads the existing YAML, so services are discovered because they are running rather than registered because a file exists. What a derived service map contains covers the difference, and the descriptors can stay in the repositories until Compass itself goes.
Keep Compass through the evaluation, and move on your own schedule rather than Atlassian's.
Frequently asked questions
- When does Atlassian Compass reach end of support?
- Atlassian ended Compass sales on 13 May 2026 and support ends on 31 December 2027. After that date there are no updates, security patches or bug fixes, so a migration needs to complete before the deadline.
- Do we have to migrate off Compass immediately?
- No, and rushing is the more expensive mistake. Compass keeps working and keeps receiving patches until the end of 2027. That is enough time to evaluate properly rather than to move twice.
- What are the options for replacing Compass?
- Backstage if you want to build a portal and have the team for it, Port or Cortex if you want to buy one, and NOFire AI if what you actually needed from Compass was an accurate picture of what is running.
- Will our compass.yml files transfer?
- To another declared catalog, largely yes, since the concepts map across. To NOFire AI there is nothing to transfer, because services are discovered from production signals rather than registered from a file.
Which one fits your team
Do not panic-migrate. You have until December 2027, and the useful move is to pick a destination that does not create the same problem again rather than to pick one quickly.
Go deeper: how a derived catalog is built
Related answers