The breaking change in Backstage v1.54.6 is the one you shouldn't ignore: the catalog-backend has had its relations compatibility mode ripped out. That's not a minor refactor — it's a forced model migration for any IDP that relied on Backstage silently normalizing relationship shapes.
If your platform treats the Backstage catalog as the canonical graph for services, libraries, and ownership, this one commit affects the contracts your scaffolder templates, CI pipelines, and sync jobs depend on. The v1.54.6 branch implements the removal of the relations compatibility mode; the work landed across the catalog-backend packages and docs, tightening how relations are represented. Alongside that, the release includes a config fix that returns a consistent zero value for all-zero ISO-8601 durations — this stops surprising behavior when configs use durations set to 0, which matters for golden-path templates that compute timeouts or TTLs.
Why the relations change matters
Backstage's old compatibility mode was a concession to messy real-world catalogs: mixed relation shapes, ad-hoc annotations, and importers that tolerated multiple formats. That leniency bought a lot of migration pain avoidance — but it also hid data-quality problems. Removing the compatibility shim forces teams to be explicit about relation types and cardinality. That is the right call. Compatibility layers are long-term technical debt; they propagate ambiguity into the platform and into users' mental models.
The downside: expect immediate churn. Service catalogs that relied on Backstage cleaning up relations will suddenly surface broken edges. Templates that generate scaffolds with assumed relations will fail in subtle ways. Platform teams need to add migration steps to their golden paths and validate relations during CI, not just at runtime. If you missed it, there's a focused writeup of this refactor here: Backstage catalog-backend breaking refactor removes relations compatibility mode.
Ecosystem and hardening
The plugin directory continues to grow, which helps platform teams reduce bespoke work by discovering community extensions. The v1.54.6 line also contains scaffolder and Kubernetes plugin adjustments and scaffolder fixes addressing stale CI-cache behavior. Those changes are the operational flip side of the relations refactor: plugin authors are cleaning up assumptions so IDPs can rely on clearer contracts.
Metrics: DORA as baseline, but the new priorities are explicit
Operationally, the conversation has shifted from "measure something" to "measure the right product metrics for an IDP." DORA's four — deployment frequency, lead time, change failure rate, MTTR — remain the baseline and the reason teams still reference the Four Keys approach for instrumentation. But the upstream Four Keys reference implementation is less actively maintained, and many teams are forking or reimplementing similar flows to feed dashboards and SLOs because the original repo isn't being actively updated by the community.
Platform teams that want to prove ROI are layering on Platform NPS, Time-to-First-Deployment (TTFD), and friction logs. These metrics capture developer velocity and the friction that the platform itself introduces. If your SLIs are only about clusters and pods, you don't have a product — you have infrastructure. Treating the platform as a product requires continuous user research, TTFD experiments, and instrumentation that ties catalog model correctness to developer outcomes. For a recent take on adopting DORA plus product-oriented metrics, see PlatformEngineering.org 2026 guidance: DORA, SPACE, and Golden Path adoption metrics.
Opinion: break compatibility when it forces clarity
This forced break is overdue and welcome. Letting compatibility masks quietly shape teams' behavior is how brittle platforms are born. Yes, you'll have short-term upgrade pain and a spike in ticket noise. Do it anyway: the alternative is years of implicit assumptions leaking into repos, automation, and onboarding flows.
Final thought
Expect a flurry of Backstage PRs and migration scripts in the coming weeks. The teams that will win aren't the ones that pin an old Backstage and hope for the best — they're the ones who treat the catalog as a product, add TTFD and friction logs to their dashboards, and use this break as an occasion to surface and fix bad graph data. That's where the real platform ROI gets made.
Sources
- Backstage GitHub repository (commits and releases around v1.54.6)
- Platform engineering maturity in 2026: What the data tells us
- Five key recommendations for platform teams in 2026
- What is an Internal Developer Platform (IDP)?
- Developer Portals & Service Catalogs in IDPs
- Platform engineering tools you NEED to know in 2026
- DORA fourkeys reference implementation (archived)