Compass vs Backstage

At a glance

	Atlassian Compass	Backstage
Product status	End of sale 13 May 2026, end of support 31 December 2027	Open source, actively developed, no end date
What you are getting	A finished product, for a limited time	A framework to build a portal from
Catalog source	compass.yml committed to each repository	catalog-info.yaml committed to each repository
Effort to a usable state	Already running	Six to twelve months on most published accounts
Ongoing burden	None until the deadline	A release every two weeks without semantic versioning
Atlassian integration	Native across Jira, Confluence and Bitbucket	Plugins, which you build or adopt and maintain
Self-service scaffolding	Templates removed 1 December 2025, read-only since	Software templates, a core feature
Licence cost	Not purchasable	None. The cost is engineering time
Extensibility	Limited	Unlimited, and yours to write

How the two differ in practice

The clock is doing most of the work in this comparison. Compass ended sales on 13 May 2026 and reaches end of support on 31 December 2027, so the only question is where to go, not whether to go.

Backstage is the obvious open-source destination and the catalog concepts map across almost directly. Compass registers a service when somebody commits a compass.yml, Backstage registers one when somebody commits a catalog-info.yaml, and both go stale at the same rate when nobody maintains them. A team migrating between the two changes which file holds the declaration and nothing about how the catalog is maintained.

What does change is who carries the product. Compass is finished software that Atlassian ran for you. Backstage is a framework: a demo instance runs in an afternoon, and a usable one takes upwards of seventy setup steps and, on most published accounts, six to twelve months of TypeScript and React work. Releases land every two weeks without honouring semantic versioning, so upgrades are a permanent cost rather than an occasional one. Every plugin is a separate codebase to own.

There is one direction where Backstage is clearly ahead. Compass lost scaffolding templates on 1 December 2025 and has been a read-only catalog since, while software templates are a core Backstage capability. A Compass user who missed self-service would get it back.

The honest observation is that a forced migration is a strange moment to take on a build project. Deadline pressure and a six-to-twelve-month construction effort combine badly, and the teams that regret this decision usually made it because Backstage looked free.

Where each one is stronger

Compass is stronger for as long as it exists. It works today, it is supported until the end of 2027, and it costs nothing extra to keep using while a proper evaluation runs. The native Jira, Confluence and Bitbucket integration is genuinely difficult to replace, and for a shop fully inside the Atlassian estate it is the thing that will be missed most. Panic-migrating in 2026 to avoid a 2027 deadline is the expensive mistake here.

Backstage is stronger wherever owning the code has real value. It has no end-of-life date, which is not a small consideration for a team being asked to migrate for the second time in a few years. Nobody can raise its price or retire it. It is extensible without limit, and software templates restore the self-service capability Compass removed. For an organisation with a genuine platform engineering function, it is a reasonable foundation.

Both share the limit that matters most in year two: they are declaration-based. Neither knows about a service nobody registered, and neither notices when an owner leaves. Migrating from one to the other carries that problem across intact.

How to choose

Answer the staffing question before the product question. Can you assign at least one engineer to a portal indefinitely? If not, Backstage will not reach a usable state and the deadline will arrive with the migration unfinished, which is materially worse than having chosen a commercial product.

If you cannot staff it, the shorter paths are commercial. How Backstage compares to Port and how Backstage compares to Cortex cover those two, and both reach a usable state in weeks with no upgrade burden.

Use the time you have. There is no advantage to moving in 2026 rather than 2027, and a considered choice made in the second half of the window beats a rushed one made now.

Export first regardless of destination. Historical records and configuration have value independent of where you land, and getting them out is work that is never wasted. What to move to before Compass end of support covers the full set of destinations, including the case where a declared catalog is not what you needed in the first place.

A catalog built the other way

A forced migration is a cheap moment to ask whether a declared catalog was the right shape in the first place. NOFire AI reads the catalog from what is actually running, so there is no file to keep current.

• Services, owners and dependencies come from deploys, traces, repositories, cloud resources and incidents. Each fact is dated and marked observed or inferred.
• A service nobody declared still appears. So does a service with no owner.
• A wiki is generated for every service and updated as production changes. Nobody writes or commits a page.
• A policy gate reads the same map to bound what an agent can do, and holds a write for a person or refuses it.
• Coding agents run in a microVM through brig, our open-source sandbox. The control system watches that run from outside the boundary and can stop it.

Check it against the three entities you believe are wrong today. Why a declared catalog drifts describes the failure, and what to move to before Compass end of support covers the switch.