Backstage by Spotify is an open-source platform for building IDPs (internal developer portals). IDPs provide standardization and visibility for engineering teams and managers, as the single source of truth for status, ownership, and metrics on software projects. Teams often try Backstage when they have aspirations of “building anything and everything,” but run into problems when supporting “anything and everything” becomes a full-time job for multiple front and back-end engineers. Often for naught, when adoption hangs at less than 10% as reported by the VP of Engineering at Spotify herself.
If this sounds familiar, Cortex offers a solution for migrating off Backstage without losing the hard work you’ve put into catalogs and plugins. Read on to learn the common signs that your Backstage implementation may be struggling, and what to do about it. Signs that
Backstage may no longer be the right choice
Like many open source solutions, Backstage is a good fit for some scenarios, but isn’t right for every organization. Unfortunately, you might only discover whether Backstage is a good fit (or not) once you’ve already adopted the tool. Here are some signals that Backstage isn’t working quite right for your organization.
1. Disappointing developer adoption
One of the most disappointing outcomes with Backstage is the limited developer adoption that some teams see. Even after all of the engineering work to implement and maintain Backstage, some organizations see as few as 10% of their developers use Backstage. In fact, Spotify themselves admitted to only a 10% adoption rate amongst their own team.
Developers don’t log in to Backstage because oftentimes there isn’t actionable information for them, like a notification system or concept of time bound tasks.
2. Spending too much time building basic integrations
While Backstage features a Git integration, it lacks out-of-the-box integrations with critical tools in your team’s stack, like Datadog, PagerDuty, Snyk, and ServiceNow. While your team can in many cases build the integrations you need, maintaining those integrations overtime can be time-consuming and resource-intensive.
3. Lackluster reporting
Backstage offers some basic reporting through ‘Soundcheck’ which is included with their paid plugin subscription, but Soundcheck doesn’t give broad visibility beyond the component level. This means that it can be difficult to track team progress on high-level initiatives or look at how different parts of your organization are trending.
Backstage Soundcheck is limited in part due to their lack of integrations—only SCM and Github integrations are available today. And the lack of automation attributes to it’s limited potential, as well; checks must be performed manually, and reporting can only be viewed at the component level, and not by domain, team, or individual. It can be challenging for SREs and team leads to define what they care about in Backstage, drive progress, and monitor these important indicators.
4. Ongoing maintenance
One of the reasons a team might choose not to stick with Backstage in the long term is the engineering work required. There is significant set-up and configuration time, and then you need to invest in ongoing maintenance (e.g., manually pulling security patches and version upgrades). Throughout, you may have limited support because Backstage is an open source project.
This hidden cost can result in frustrated engineers who need to spend their time implementing and maintaining an IDP rather than more impactful projects.
Organizations who choose to implement Backstage often allocate headcount to implement and maintain their IDP—many now-Cortex customers that tried Backstage report 2-3 FTEs that spent 6-9 months just trying to stand Backstage up.
Solving these challenges with Cortex
Cortex is a fully-managed IDP for enterprise teams that addresses many of the challenges with Backstage. Here’s just a few areas Cortex stands apart from Backstage:
- Out-of-box integrations with 50+ software tools and services to pull data into your IDP (and plugins to build any other integrations you need)
- Scorecards so you can define & track requirements across your service catalog
- Initiatives for motivating progress on operational maturity & software reliability
- Rich reporting that provides bird’s eye executive visibility or lets you drill into specific software components
- Ongoing support and fast setup—you can onboard and start seeing value within hours. And with no ongoing maintenance costs, many teams find that the total cost of operation (TCO) is lower with Cortex.
If you’re already using Backstage and want to make the switch to Cortex, the first question on your mind is going to be: what does migration look like? Fortunately, because Cortex already integrates with Backstage through a plugin, it’s a very simple process.
Preserving your catalogs
Thanks to Cortex’s built-in Backstage plugin, migrating from Backstage to Cortex is simple and can be done in a matter of hours, while preserving all your existing catalogs and configuration details.
The Backstage plugin was originally built as a way for developers to sync data between Cortex and Backstage, since many Backstage users found that reporting and scorecards wasn’t up to par in their Backstage instance. The plugin syncs entities in Backstage to Cortex, and then renders Cortex views in Backstage for Scorecards and Initiatives.
Because Cortex already understands all of the data in Backstage, migrating from Backstage to Cortex is a simple process. We’ll port over your existing catalogs from Backstage so you gain immediate visibility into all of your software entities with documentation, change history, dependencies, and always up-to-date ownership information—all in one place.
And unlike Backstage, Cortex scorecards are automated to ensure alignment on best practices or make progress against short-term initiatives like migrations, version EOL, and compliance. Tasks prioritization highlights daily "quick wins" with deadlines and alerting to focus the team on what matters most.
Migrating your plugins
It’s also easy to migrate your existing Backstage plugins.
Migration starts with creating a Cortex plugin via Scaffolder, using the built-in Cortex Plugin Template. We walk you through what updates need to be made to the repo, registration files, dependencies, and more.
Replacing the Backstage entity usage with Cortex entity usage is often the biggest step, since there’s no easy or complete 1:1 mapping between the two data models. Once you replace the data fetching layer, you’re ready to test.
Keep your catalogs, lose the maintenance
If you're an existing Backstage user eager to hear more about the experiences of others who've successfully migrated—and what drove them to make the move!—don't hesitate to get in touch.
If you’re new to Cortex and would like to learn more on your own, request a live demo or check out our interactive demo to see how Cortex can help you cut noise for developers and drive action to improve software.
.png)
