Compass: Atlassian’s migration to DX Fabric
Atlassian Compass in 2026 is a migration story: its catalog and scorecard functions are moving to DX Fabric, and new sales ended in May.
Atlassian ended new Compass sales on 13 May 2026 and is encouraging customers to migrate component catalog and scorecard use to DX Fabric.
Compass centred software components, ownership and health scorecards
Compass centred software components, ownership and health scorecards. The useful idea was connecting engineering standards to a live catalog rather than keeping architecture in static documents.
The strategic consequence is timing. A rushed migration can create outages or rework, while delaying too long can leave a team with fewer replacement options and less vendor support. The useful 2026 context is the window between those two pressures.
DX Fabric is the target for catalog and scorecard migration
DX Fabric is the target for catalog and scorecard migration. Customers need to plan data transfer and understand which functions move directly and which do not.
Lifecycle is now central to the operating decision rather than a footnote. Existing users may still have a working product, but support dates, packaging changes or replacement platforms alter what “current” means for new projects and for systems that must remain in service. For Compass, that consequence belongs to this specific 2026 product context.
Operations features require separate handling
Operations features require separate handling. Atlassian notes that alerts and operations functionality must move to Jira Service Management rather than assuming an one-click DX migration.
The transition around Compass creates operational work because data, configurations and integrations do not disappear when a product name changes or sales stop. The organisation has to preserve behaviour while moving to the replacement model, which makes compatibility part of the migration cost.
What the transition preserves and what it changes
That matters because The combined effect in migration work. Existing data, automations and integrations do not disappear when a product name changes or a service is absorbed into another platform.
Operations features require separate handling. A further consequence is continuity. Customers need to know which functions survive, which are repackaged and which processes must be redesigned, because a tidy portfolio rename can still create substantial operational work behind the scenes.
How packaging can change the economics for Compass
Operations features require separate handling. Packaging changes can also alter economics. A capability that once had its own tier may become part of a broader platform with different limits, bundles or prerequisites. Organisations need to compare the function they actually use rather than assume the new product name represents an identical commercial offer.
Timing determines risk. Moving too early can force teams onto an immature replacement, while waiting until support or access changes become urgent leaves little room for testing. The useful 2026 position for Compass is therefore the overlap between old and new: enough certainty about the destination to plan a controlled move without pretending the transition is already invisible.
What existing customers actually carry forward for Compass
A product transition changes the question from “what can I buy?” to “what happens to the work already built here?” data, automations, permissions and integrations can survive a rename or portfolio shift only if the replacement provides a clear mapping. That matters because the visible brand change is usually the smallest part of the migration.
That matters because existing customers carry history that a new buyer does not. Saved configurations, URLs, training material and internal procedures may all refer to the old product even when the capability moves elsewhere. Transition quality depends on how much of that operational memory remains valid and how much has to be rewritten.
The migration quality around Compass will be judged by how much user work survives the change. Names and menus can move quickly; data models, automations and habits move more slowly. The best transition provides a clear mapping from the old capability to the new one and enough overlap for teams to verify that critical processes still behave as expected. It also gives organisations time to update training and internal documentation before the old path disappears. That matters because that is the practical meaning of lifecycle reporting here: not merely announcing that a product changed, but explaining what the change asks existing users to carry forward.
Compass in the wider manufacturer portfolio
For related coverage from the same manufacturer, see Trello in 2026: when a simple board becomes an automated workflow. It covers a different product or service in the portfolio and is included for context rather than as a direct alternative.
Where the product stands now for Compass
A renamed or absorbed product changes the reader’s question from purchase to continuity: what survives, what moves, and what existing customers have to map onto the replacement.
Bringing the design together for Compass
The developer portal therefore has to be read as one product whose parts change the same outcome. dX Fabric is the target for catalog and scorecard migration. Operations features require separate handling. For the developer portal, that matters because in 2026, the significance comes from how those design choices coexist: the useful capability appears only when the surrounding system, market or workflow can support it, while the limitation appears where one of those dependencies becomes the next bottleneck. That is a more informative picture of the developer portal than any one specification or feature viewed alone.
Compass: why the 2026 context matters
Atlassian ended new Compass sales on 13 May 2026 and is encouraging customers to migrate component catalog and scorecard use to DX Fabric. That current position matters because the central issue is specific to Compass: Atlassian Compass in 2026 is a migration story: its catalog and scorecard functions are moving to DX Fabric, and new sales ended in May. The lifecycle and the technical story therefore meet in the same place—what the product can do now, what surrounding system has to support it and which part of the value proposition changes as the portfolio moves forward.
For Compass, the consequence is not an abstract specification comparison. The product has to be understood through the workload or service it changes, the operational cost it removes or creates, and the continuity expected from the current generation. That is the context that turns the documented features into a useful 2026 explanation rather than a catalogue entry.
Source note: Official information for Compass was checked on 19 September 2026. Primary source. Manufacturer performance claims remain manufacturer claims unless independently stated.
