Atlassian Compass phase-out: options for your catalog and scorecards

Atlassian Compass phase-out: what to decide about your catalog and scorecards

Your Compass catalog and scorecards are changing hands, so the decision in front of you is whether to accept the move to DX or to move the catalog to a portal you control. The choice turns on three questions: data residency, lock-in, and who will run the portal. Self-hosted Backstage is the main open-source option for the second path, because it is an Apache-2.0 framework with no paid edition from the project itself, and it is hosted in your own infrastructure. Before you decide, confirm with Atlassian and DX what the transition terms, export options and timelines are for your organization, since no DX price or date is established here.

Start with residency and lock-in. Ask where your component ownership, team data and scorecard results would sit after the transition, and whether you can export them in an open format. Backstage stores catalog entities as YAML descriptors, conventionally named catalog-info.yaml, kept beside your code, so the source of truth stays in your repositories. Cortex and OpsLevel are the other portals you may evaluate. Their self-managed editions still need a vendor license key or license file, so self-hosting them does not remove the subscription. Confirm those license terms in writing before you treat either as an exit from a vendor relationship.

Then decide who runs the portal. Backstage needs a platform team to operate it, including PostgreSQL, upgrades and plugin maintenance, and the project's versioning policy means you will be tracking monthly and weekly release lines. Name an owner, a backup owner and the hours they can give before you commit. If you lack that capacity, weigh a fixed-scope implementation and a retainer for upgrades and support against accepting the DX transition. Whichever path you take, export your current catalog and scorecard definitions first so that you keep the option open while you decide.

What the phase-out requires from your catalog

Moving off Compass means your ownership data, component relationships and scorecard logic have to survive the move in a form you control. The cards below set out the four requirements that matter most when you compare DX, self-hosted Backstage and other portals.

Keep catalog data in your control

Your catalog is the record of which services exist, who owns them and how they connect. A self-hosted Backstage instance stores its catalog in your own infrastructure, with PostgreSQL in production, so the data stays under your access controls and backup policy. Before choosing a target, ask each vendor where catalog data is stored, who can read it and how you export it in full. Confirm the answer in writing, not in a sales deck.

Preserve ownership in version-controlled descriptors

Backstage describes each entity in a catalog-info.yaml descriptor that lives next to the code it describes. Kinds such as Component, API, Resource, System, Domain, Group and User let you keep ownership and relationships as reviewable files rather than as settings inside a web console. Map every Compass component to a kind and an owner before migration starts, and flag any service with no clear team. Those gaps will show up later as orphaned entities if they are not resolved first.

Keep API definitions attached to components

API entities in Backstage can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions, so consumers can see the contract next to the owning service. If your Compass setup records API relationships or links to specifications, inventory those now and confirm which formats they use. Any spec that lives only in a wiki page will need a new home in your repositories before the catalog can reference it.

Keep scorecard logic auditable

Scorecard rules decide which teams look compliant, so they need the same review as code. Backstage's Tech Insights plugins evaluate checks defined in configuration, which you can version and approve. Export every Compass scorecard criterion, record its owner and the evidence it depends on, and decide which rules must be re-implemented rather than copied. Ask any replacement vendor how rule changes are logged and who can approve them.

Secure sign-in through your identity provider

Backstage ships 19 authentication providers, including GitHub, GitLab, Google, Azure, Okta, Auth0 and generic OIDC, so you can sign in through the identity provider you already run. Configure sign-in resolvers so every provider maps to the same identity, and disable guest access in production as the authentication documentation advises. Without this, the same engineer can appear as two catalog users and team ownership becomes unreliable.

How accepting DX differs from self-hosting Backstage

Accepting the DX transition keeps the operating model you already have: Atlassian hosts the catalog, applies the upgrades and decides the roadmap, and your team keeps consuming the service rather than running it. That is a legitimate choice for many organizations, especially where the engineering budget is better spent on the services being cataloged. Before accepting it, confirm directly with Atlassian where DX stores catalog data and metadata, which regions and subprocessors are involved, how data is exported in a usable format, what happens to your scorecard history at the end of the transition, and what terms apply if you later leave. Those answers belong in writing, not in assumptions about what the migration will preserve.

Self-hosting Backstage moves hosting, upgrades and access control into your environment. Backstage is licensed under the Apache License 2.0, and the project itself offers no paid edition, so the software cost is zero while the infrastructure, PostgreSQL, plugin maintenance and platform staffing become your line items. It is a CNCF project that reached the Incubating maturity level in March 2022, which signals an active governance process but does not replace your own support decisions. You also take on sign-in configuration: the authentication documentation recommends resolvers that map every identity provider to one identity and advises against guest access in production. Your team owns the Backstage versioning policy cadence, including security backports and Node.js compatibility.

The decision comes down to who carries which risk. Ask whether your platform team can commit to running an upgrade cadence, and whether your data residency and access rules are easier to meet inside your own cloud account. If the answer to the first question is no, the DX path may be the safer choice even though it leaves you dependent on a vendor roadmap. Document the decision with the data questions answered, so the choice is traceable when auditors or procurement ask why a given catalog sits where it does.

Comparing DX, self-hosted Backstage, Port, Cortex and OpsLevel

This table compares the paths open to a team leaving Compass by data control, self-hosting, licensing and effort. Read each row against your own data residency rules and how many engineers you can spare to run a portal. The main takeaway is that only Backstage removes the vendor license from the picture, while the others can keep a subscription even when self-hosted.

Criterion	Backstage (self-hosted)	Port, Cortex and OpsLevel (self-managed)
Licensing	Apache-2.0 open source with no paid edition from the project itself	Commercial products; self-managed editions need a vendor license key or license file
Where catalog data lives	In your own infrastructure, in a PostgreSQL database you operate	Port integrations can run in your infrastructure via Helm or Docker; Cortex and OpsLevel self-managed run in your cluster, but vendor licensing still applies
Subscription after the move	None from the project; you pay for hosting, staff and any support contracts you choose	Likely continues; confirm with each vendor whether the self-managed license is priced separately from SaaS
Catalog model	catalog-info.yaml descriptors with Component, API, System, Group and other kinds	Each product has its own data model; check how Compass components and teams map to it
Scorecards	Must be rebuilt, typically with the Tech Insights plugins, using rules you write	Scorecard or rubric features exist in each product; confirm how well they import Compass scorecard rules
Effort to run	Needs a platform team to upgrade, patch and extend plugins; upgrades follow a monthly and weekly release cadence	Vendor handles product updates under the license; your team still runs the cluster, database and integrations
Security patching	Backstage backports high and critical fixes to releases from the last 6 months where feasible	Depends on the vendor's release terms; confirm patch windows in writing before signing
Best fit	Teams that want full control and can staff a platform team	Teams that want a packaged product and accept a continuing license

Which option fits which situation

If your policy requires service ownership data, dependency maps and team records to remain in your own cloud account or data center, self-hosted Backstage is the option that matches that requirement most directly. Backstage is an Apache-2.0 framework with no paid edition from the project itself, so the software carries no license fee, but your infrastructure, database and staff carry the running cost. Commercial self-managed editions of other portals still need a vendor license key or license file, so they do not remove the subscription.

Catalog storage: Backstage keeps catalog data in PostgreSQL in production, which you host inside your own network.
Source of truth: catalog-info.yaml files live in your Git repositories, so ownership data can be reviewed like any other code.
Identity: Backstage ships 19 authentication providers, so sign-in can use your existing identity provider.
Vendor dependencies: Ask whether any integration sends data to a vendor-hosted service, since a plugin can change where data flows.
Ask first: Confirm with your security and legal teams which data classes are in scope and whether a self-managed commercial edition would still send license or telemetry data outside your environment.

If your organization is comfortable with a vendor hosting the portal and your data processing terms cover it, a hosted option can reduce the operating work your team takes on. Port's data integrations can be hosted by Port with a configurable resync interval, and Cortex and OpsLevel also offer SaaS deployments. The trade-off is that the vendor operates the platform and you depend on its roadmap, pricing and contract terms.

Operations: The vendor patches and runs the service, which removes upgrade and database work from your team.
Data location: Hosted integrations pull or receive data in the vendor's environment, so review where that data is stored and processed.
Exit path: Keep your catalog in files you control, such as catalog-info.yaml, so a later move is a conversion rather than a rebuild.
Pricing: Request written pricing for the period after the Compass transition, because DX pricing for Compass customers is not something this page can state.
Ask first: Confirm data residency, subprocessors, retention periods and the export format in the contract before signing.

How to stand up a self-hosted Backstage catalog

This sequence takes a team from an undecided hosting choice to a running Backstage instance that holds its imported catalog under one sign-in identity. Each step closes with a check you can run before moving on. Reading the versioning policy first will set the upgrade habits the rest of the work depends on.

Choose where Backstage will run
Platform engineering and security decide the hosting location, usually inside the organization's own cloud account, data center or air-gapped network, and confirm who holds administrative access to the host. Record the decision alongside network reachability to your source control, identity provider and the systems that hold catalog data. Done when the hosting location, owners and network paths are written down and approved. Confirm with your security team whether any integration needs outbound access that your network policy blocks.
Deploy Backstage with PostgreSQL for production
The platform team creates a Backstage app from the project's supported tooling and points it at a PostgreSQL database for production. SQLite is suitable only for local development, so do not promote a SQLite-backed instance. Backstage gives each backend plugin its own logical database through Knex, so plan database access, backups and credentials for PostgreSQL before the first deployment. Done when the instance starts against PostgreSQL in a non-development environment and the database backup job is confirmed to run.
Configure one authentication provider and its sign-in resolver
The identity team selects one of the built-in authentication providers, such as GitHub, GitLab, Azure, Okta or generic OIDC, that matches your existing identity system. The team writes a sign-in resolver so every provider you later add resolves to the same user identity, and turns off guest access for production. Done when a test user signs in through the chosen provider, lands on the same identity record as before, and an anonymous request is refused.
Import catalog-info.yaml descriptors
Service owners add a catalog-info.yaml descriptor to each repository, and the platform team registers those files with Backstage through a Location entity or a reviewed import list. Descriptors define Component, API, Resource, System, Domain, Group and User entities, and API entities can reference OpenAPI, AsyncAPI, GraphQL or gRPC definitions. Done when every in-scope component appears in the catalog with a named owner, and a sample of entries has been checked against the source repository by its team.
Confirm the Node.js runtime and release line
The platform team checks the versioning policy and selects a Node.js release that Backstage currently supports. Backstage supports exactly two adjacent even-numbered Node.js releases, and the policy names the supported pair for each Backstage version, so confirm that pair before pinning the runtime. Record the chosen Backstage release line and its Node.js version in the team runbook. Done when the runtime version in the build and the runbook match the policy for the release you run.
Set a regular upgrade cadence and security response
The platform team schedules a regular upgrade routine that follows the main release line, which ships monthly on the Tuesday before the third Wednesday, or the next line, which ships weekly on Tuesdays. The versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last 6 months if feasible, and other security fixes may be backported, so staying within that window matters. Done when a named owner receives release notices, a test instance upgrades first, and the team can show the last applied release.

Questions buyers ask before hiring help with a Compass exit

What does a Compass exit cost and what drives the price up?

The cost comes mostly from the work itself, not from software licenses, since Backstage is Apache-2.0 licensed with no paid edition from the project. Expect one-time costs for cataloging and mapping your components, rebuilding scorecards, standing up hosting, PostgreSQL and authentication, and building or configuring plugins. Recurring costs cover hosting, upgrades, and the platform engineers who keep the portal running. Scope drives cost most: the number of components, custom integrations with Jira or Bitbucket, and how many scorecard rules must be rebuilt. Ask any provider for a written scope that separates these one-time and recurring items, and for the assumptions behind each line.

How long does a Backstage migration from Compass take?

Timing depends on how many components you have, how many already live in compass.yml files, and how many scorecards and integrations must be recreated. Backstage itself ships a main release line monthly and a next line weekly, so your team should plan upgrades as an ongoing task, not a one-off. Ask for a timeline tied to phases you can check: catalog export, import into catalog-info.yaml entities, identity mapping, scorecard rebuild, and cutover before Compass access ends. Confirm the Compass end date with Atlassian or DX directly, since that date sets your hard deadline.

What must our team provide before an engagement starts?

Your team should provide a current export or list of Compass components, the owners and teams for each, and any compass.yml files kept in repositories. You also need access to your identity provider so teams and users can be recreated, a decision on which Backstage authentication provider you will use, and named contacts for each engineering group that owns services. Provide the existing scorecard definitions and the Jira and Bitbucket integrations in use. A written scope should list these inputs and who on your side is responsible for each one.

Can our own engineers do the Compass exit without outside help?

Yes, many teams can, provided they have engineers who know Kubernetes, Node.js, TypeScript and PostgreSQL, and time to own the portal after launch. Backstage supports exactly two adjacent even-numbered Node.js releases, so you will need a process for tracking that support window. Outside help is most useful for the initial architecture, the identity and sign-in resolver setup, and the scorecard rebuild. Decide which parts your staff will run and which need a retainer, and ask any provider to name what knowledge transfer they include.

Does self-hosting Cortex or OpsLevel avoid the subscription?

No. Both vendors' self-managed editions still need a license from the vendor. Cortex requires a JWT license key and access token from its account team, plus a PostgreSQL database on a Kubernetes cluster. OpsLevel's self-hosted edition requires a license file and is installed through Replicated on a Kubernetes cluster (preferred) or a VM. OpsLevel's documentation lists minimum specifications of 16 CPU, 16 GB of memory, capacity for at least 20 pods, and 24 Gi of disk for pilots or 120 Gi for production. Self-hosting changes where the data lives and who runs the infrastructure, but the license cost remains, so compare it with Backstage's hosting and staffing costs.

What does a fixed-scope engagement with DeployOpen cover?

A fixed-scope engagement covers the scope, deliverables and timeline agreed in writing before work starts. For a Compass exit, the written scope should name the components and teams to migrate, the catalog-info.yaml conventions, the identity mapping, the scorecard rules to rebuild, the hosting target in your own cloud account, data center or air-gapped network, and the handover items. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Backstage inside your infrastructure. It does not issue audit reports or certifications. Ongoing upgrades and support after handover are available as a separate retainer.

What breaks most often when moving catalog data into Backstage?

The most common problems are inconsistent ownership, components with no clear owner, and identity mismatches where one user appears under several sign-in providers. Backstage's authentication documentation advises configuring sign-in resolvers so every provider resolves to the same identity, and not offering guest access in production. Check that every catalog entity uses a valid kind from the Backstage descriptor format, such as Component, API, System or Group, and that API entities carry the right definitions. Test imports in a staging instance first and compare entity counts against your Compass export.

Questions to settle before choosing a portal

Settle four questions with leadership and the platform team before comparing products, because each answer changes which option fits. The first is ownership: who runs the portal after go-live. A self-hosted Backstage instance is a platform you operate, which means someone owns upgrades, plugin maintenance, the PostgreSQL database and on-call. The Backstage versioning policy describes a monthly main release line and a weekly next line, so a named owner with time reserved for upgrades is a precondition, not an afterthought. Commercial self-managed editions of Cortex and OpsLevel shift part of that work to the vendor but still require a license key or license file, so ask who holds those credentials and who renews them.

The second question is which identity provider is authoritative. Backstage ships 19 built-in authentication providers, but the authentication documentation advises sign-in resolvers that map every provider to the same identity, and it recommends against guest access in production. Decide now whether users, groups and team ownership come from your existing directory, because catalog-info.yaml owners and Group and User entities must match it. The third question is what data leaves your environment. Port can run its integrations hosted by Port or self-hosted with Helm or Docker, and OpsLevel's self-hosted edition needs the instance reachable over the internet for push-based integrations. Confirm each vendor's network requirements in writing before assuming an option keeps catalog data internal.

The last two questions set the timeline and the migration scope. Ask the DX team, in writing, how long Compass access remains available and what export formats are supported, and confirm this with your Atlassian account contact, since the phase-out details are not part of the facts available here. Then decide what must be exported: compass.yml files in source control, UI-created components, scorecard definitions and team ownership each need a different path. The Backstage descriptor format documentation is the reference for the target model. Answers to these four questions determine whether a self-hosted Backstage portal, a vendor self-managed edition or a DX transition is the right next step.

Evidence to keep from the transition

Whatever option you choose, internal reviewers and external auditors will ask you to show what the catalog contained, who could change it, and why you chose it. The cards below list the records worth exporting and dating before Compass access ends. None of them is a certification on its own, and an independent auditor decides what your evidence proves.

Catalog and ownership export

Keep a dated, written export of every component, API, system and team owner from Compass, including components created in the UI that never appeared in a compass.yml file. Store it outside the tool you are leaving. Reviewers use it to confirm that each production service had a named owner on a given date. Check that the export includes the owner field for every entity, since a blank owner is often the finding that matters most.

Portal access control configuration

Record who can read, edit and administer the new portal, and how those roles map to groups in your identity provider. For a self-hosted Backstage instance, the permission policy and the team group definitions are the artifacts to keep under version control. Confirm that offboarded staff lose access through the identity provider rather than through a manual list inside the portal.

Authentication resolver configuration

Keep the sign-in configuration that shows how each identity provider maps to a single catalog user, along with proof that guest access is disabled in production. Backstage's authentication documentation advises resolvers that make every provider resolve to the same identity. Reviewers will test this by signing in through two providers and checking that one user record results, so capture that test result as well.

Upgrade and patch record

Log each Backstage upgrade with its release version, the date applied and the test evidence behind it. The versioning policy says high and critical vulnerabilities are backported to releases from the last six months where feasible, so a current version is the baseline to show. Also record the supported Node.js version in use, since Backstage supports only two adjacent even-numbered Node.js releases. Gaps in this log are hard to explain after the fact.

Decision record for the chosen option

Write a short decision record that names the options you considered, including staying with the DX transition, and the criteria you scored them on. Include the cost components, the data each option would hold, and who approved the choice. Reviewers look for evidence that the decision was deliberate, reviewed and dated, and that known gaps, such as scorecard dashboards or integrations that need extra work, were accepted by a named owner.

How DeployOpen approaches a Compass phase-out

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Compass phase-out, that means agreeing on which catalog and scorecard data moves, where a self-hosted portal runs, and who operates it before any work starts.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which Compass components, teams and scorecards are in and out of the migration.
We confirm which identity provider, cloud account or data center will host the self-hosted portal and its PostgreSQL database.
Quotes follow from the written scope, so the scope should name the integrations and plugins you need.

How we build

We stand up a self-hosted Backstage instance inside your own infrastructure, sized to the scope agreed in writing.
We convert catalog data into catalog-info.yaml descriptors and configure the Software Catalog for your component and team model.
We set up sign-in resolvers so every identity provider resolves to the same user, and we leave guest access off in production.
We test catalog imports, ownership mapping and scorecard rules against the scope before any cutover.

How we hand over

Deliverables include the configured instance, descriptor files, import records, and runbooks for operating the portal.
We document the catalog conventions and scorecard definitions so your platform team can extend them without us.
We prepare the evidence and control records your assessors may ask for during the transition, without issuing any audit opinion.
Handover covers backup and upgrade procedures so the portal can follow the Backstage release line your team chooses.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover tracking Backstage security releases and applying upgrades within your change process.
Security testing of the portal, its plugins and its integrations can run alongside the support retainer.
Ask any provider, including us, to confirm in writing what support, response and upgrade commitments are included.