Open-source alternative to OpsLevel maturity rubrics: the short answer
If you lead a platform or engineering team and need OpsLevel-style rubric scores without renewing a licensed self-hosted edition or sizing a new cluster for it, the open-source route is Backstage Tech Insights, which combines facts (data points collected from catalog entities), checks (rules evaluated against those facts) and the tech-insights-maturity plugin, which adds maturity rankings and categories to checks. These are community plugins for the Backstage framework, not a packaged scorecard product, so you assemble the scoring model yourself and own its upkeep. Backstage is licensed under Apache-2.0 and the project itself offers no paid edition, so the software cost is zero, but the work of building, hosting and maintaining the rubric is not.
The most important planning point is that OpsLevel rubric logic cannot be imported as-is. Export your existing checks and their criteria, then translate each one into a fact source (for example, a catalog annotation, a CI result or a repository property) and a rule that evaluates it. Some OpsLevel checks will map cleanly, others will need a new data source, and a few may not be worth rebuilding. Confirm with your own team which checks drive decisions before you start. The OpsLevel self-hosted edition, by contrast, still requires a license file from OpsLevel and runs with a minimum of 16 CPU and 16 GB of memory, so self-hosting it does not remove the subscription or the sizing decision.
Before committing, ask a concrete question: which of your rubric levels are used for promotion, funding or compliance evidence, and who will answer for their accuracy after the switch. Backstage Tech Insights gives you the building blocks to present team-level progress, but the accuracy of those scores depends on the entity data behind them. Review the Backstage Tech Insights community plugin documentation to confirm the fact and check model fits your rubric, and plan a parallel run where both systems score the same services until the results agree.
How OpsLevel rubric capabilities map to Backstage Tech Insights
This table maps each OpsLevel rubric capability to its closest Backstage Tech Insights equivalent, with the plugin or annotation that carries it. Read the right-hand column first, since it flags where a custom plugin or a confirmation with the plugin documentation is needed. The main takeaway is that the scoring model transfers well, but OpsLevel-specific check types and reporting views usually need to be rebuilt.
| Capability | Backstage equivalent | Gap or action |
|---|---|---|
| Maturity levels and categories | tech-insights-maturity plugin adds maturity rankings and categories to checks | Recreate your level names and category groupings in the plugin configuration. Confirm the ranking options in its current documentation. |
| Check definitions (rubric rules) | Tech Insights checks evaluate facts against rules for each catalog entity | Translate each OpsLevel check into a fact and a rule. Checks that depend on OpsLevel-only signals need a new fact source first. |
| Automated data collection | Facts are collected by fact retrievers that read from the catalog, APIs or source systems on a schedule | Build or configure a retriever for each data source. Confirm which retrievers ship in the community plugins and which you must write. |
| Ownership and team assignment | Owner field and Group and User entities in catalog-info.yaml, with ownership data exported from OpsLevel | Map OpsLevel teams to Group entities and service owners to the owner reference. Ownership accuracy drives every team-level score. |
| Service metadata and tags | Catalog annotations and labels on Component entities, read by facts and checks | Define an annotation naming convention before migration so checks can filter on it consistently. |
| Integration-based evidence (CI, repos, cloud) | Facts built from annotations, catalog data or plugin-provided data such as Kubernetes or CI status | Expect custom fact retrievers for sources without a published plugin. Treat each one as code you must test and maintain. |
| Team-level progress reporting | Scorecard views from the tech-insights-maturity plugin and the Tech Insights plugin frontend | Team rollups and trend views may need a custom plugin or dashboard. Confirm what the current frontend shows per group. |
| Check history and trend tracking | Tech Insights stores check results over time in its backend database | Confirm the retention and history view you need. Plan a PostgreSQL backup policy for the stored results. |
| OpsLevel-specific check types and levels | No direct equivalent in the Backstage community plugins | Gap. Rebuild each unique check as a fact plus rule, or retire it with the owning team's agreement. |
Which open-source options fit rubric replacement
Maturity rubrics can be rebuilt on Backstage in a few different ways, and each option asks something different of your team. The cards below cover the primary Tech Insights path and the reporting and scorecard options that sit beside it, with the trade-offs you should weigh before committing.
Backstage Tech Insights with maturity
Tech Insights is the closest match for OpsLevel rubrics. The community plugin lets you define facts (data points) and checks (rules) against catalog entities, and the tech-insights-maturity plugin adds maturity rankings and categories to those checks. This fits teams already running Backstage with a catalog they trust. Check that the community plugin version matches your Backstage release, since it is maintained outside the core project.
Custom Backstage frontend scorecards
A custom frontend plugin can render your own scorecard views inside the portal, using the same catalog entities that feed your checks. This suits organizations with in-house React capacity and specific rubric layouts that no community plugin provides. The trade-off is that you own the component code, its tests and its upgrades through every Backstage release, so budget ongoing engineering time for it.
Self-hosted dashboards fed from catalog data
Some teams export catalog facts into a self-hosted dashboard tool and keep reporting outside the portal. This fits leaders who want team-level progress charts that do not depend on Backstage's frontend. You must build and maintain the export job, and confirm that the dashboard tool's license and hosting model meet your data residency rules before you adopt it.
Keeping pace with Backstage releases
Backstage's main release line ships monthly, and the next release line ships weekly on Tuesdays. Rubric checks written against plugin APIs can break between releases, so plan a regular upgrade cadence. Backstage backports high and critical vulnerability fixes to releases from the last six months where feasible, which limits how far behind you can safely drift.
Node.js support and runtime upkeep
Backstage supports exactly two adjacent even-numbered Node.js releases, and the versions in scope change with each Backstage release. Confirm which Node.js versions your target Backstage release supports before you pin your build image. Rubric checks that call custom backend code inherit this constraint, so include runtime upgrades in your maintenance plan.
How OpsLevel checks translate into Tech Insights facts and checks
Each OpsLevel check maps to two pieces in Backstage Tech Insights: a fact, which is a data point collected from catalog entities or an external source, and a check, which is a rule evaluated against that fact. The community tech-insights-maturity plugin then adds maturity rrankings and categories to the checks, so the rubric levels you use today have a place to land. Before writing any code, list every OpsLevel check with its rubric level and the data it reads. That inventory is the translation work, and it tells you how many facts you need to collect and which checks depend on something outside the catalog. Confirm the current facts and check definitions against the Backstage community plugins repository for the plugin version you plan to run.
Checks written as a pass or fail test on a single property are the easiest to port. An example (illustrative only) is a rule that a service has an owner set, or that its catalog-info.yaml declares a lifecycle value. One fact collects the property from each entity, and one check asserts its value. Rubric levels such as bronze, silver or gold can be modeled as maturity categories, with each level grouping the checks that must pass for a service to reach it. Keep the level boundaries identical to your current rubric so team scores do not shift on cutover unless you intend them to.
Checks that depend on OpsLevel's own calculated data need an equivalent source before they can port. Examples include scores computed from service dependencies, check results that rely on OpsLevel integrations with monitoring or CI tools, and aggregates that OpsLevel calculates across a service's history. For each one, decide whether the value will come from a Backstage plugin, from your CI or observability system through its API, or from a descriptor field maintained by the owning team. Some checks will not have a direct equivalent, and you should record those as explicit decisions rather than silently dropping them. Ask the team that owns the rubric to sign off on each substitution before you retire the OpsLevel version.
Exporting existing checks through Terraform or the API
The OpsLevel CLI, which is MIT-licensed, can export configuration as Terraform, and that output is the fastest starting point for rubric and check definitions. Expect the output to describe the rubric structure and check names, along with the conditions the provider exposes for each. Confirm in the current CLI help which resources the export covers before you plan the migration.
- Rubric and check definitions: The export carries the levels, categories and checks configured in the account, so you can see the full rubric in one place.
- Versionable resources: The output is HCL that you can store in Git, diff between runs and review like any other infrastructure change.
- Coverage gaps: Some check types may appear only in other formats, so compare the export against the checks in the interface.
- Service and ownership links: Exported service records help you map each check to the catalog entities it evaluates.
Before moving on, compare the number of exported checks with the number of checks shown for each rubric in the OpsLevel interface.
Use the GraphQL API when the Terraform output lacks the detail you need, such as check descriptions, filter logic or per-service results. The API lets you query the rubric and check fields directly and shape the response for the next step. Check the GraphQL schema for exact field names, because they can change between API versions.
- Fields the export omits: Query rubric and check fields directly when the Terraform output does not show the logic or description you need.
- Schema introspection: Use the schema to confirm field names and types before you write queries against a live account.
- Per-service results: Pull pass or fail status by service when you need evidence for team-level progress in Backstage.
- Scripted output: Write responses to JSON files so they can feed the fact and check review that follows.
Test each query against one service first, and confirm that the returned values match what the OpsLevel interface shows for that service.
An export is not a verified translation of your rubric. Conditions may depend on OpsLevel-specific functions or on integrations that Backstage Tech Insights does not provide out of the box. Read the logic for every check, because names alone can hide differences in thresholds, scope or exceptions.
- Hand-review each check: Read the condition, threshold and scope for every check, not only the name.
- Flag platform-specific inputs: Note checks that rely on a particular integration and record which Backstage data source would supply the same signal.
- Mark ambiguous rules: Flag checks with thresholds or conditional logic that need a decision from the rubric owner.
- Keep a reconciliation sheet: Map each source check to a planned Backstage fact or rule, along with its owner and status.
Get sign-off on the reconciliation sheet from the rubric owners before any check is enabled in Backstage.
The GraphQL API returns results in pages and enforces rate limits, so an export can fail silently or stop partway. Confirm the current paging behavior and rate limits for your account in OpsLevel's API documentation, and build the export around them. A partial export can look like a complete one unless you check it.
- Paging: Request results page by page and follow the cursor until no pages remain, so every service and check is captured.
- Rate limits: Confirm the limits that apply to your account and build retries with backoff into the script.
- Scheduled pulls: Run large exports outside busy periods and repeat them only at defined points in the migration, such as before each phase.
- Completeness checks: Compare record counts from the API with the Terraform export and with the counts shown in the interface.
Keep the raw responses from each run so you can rebuild the Backstage mapping without repeating the export.
Migrating rubric checks in phases without losing team scores
This sequence moves each OpsLevel rubric check into a Backstage Tech Insights fact and rule, proves the results match in parallel, and only then retires the originals, so every team keeps an accurate maturity score throughout the switch.
Inventory checks, rubrics and owners
Platform engineering lists every OpsLevel rubric, level and check, and records which team owns each service and which group approves rule changes. Export the current OpsLevel definitions with the CLI or GraphQL API so the list comes from the source rather than memory. The step is done when every check has a named owner, a service scope and a short note on what it measures. Ask your OpsLevel administrator to confirm that no rubric is applied through an unmanaged override.
Export definitions and freeze ownership data
Pull services, teams and ownership into a versioned file, and agree a freeze window in which changes to team ownership are made only in one place. Keep the source of truth for owners clear, because a Backstage catalog built from stale ownership will score the wrong team. The output is a dated export that the catalog import can be checked against. Confirm with each team lead that their services and group memberships in the export are correct.
Translate each check into a fact and rule
For each OpsLevel check, define a Tech Insights fact that collects the underlying data, then write a rule that evaluates it against catalog entities. Where a check depends on a repository setting, a pipeline result or a Kubernetes label, identify the data source and confirm that the plugin or integration can read it. Group checks into maturity categories that match the original rubric levels, using the tech-insights-maturity plugin. The step is complete when each check has a documented fact, a rule and a mapping to its rubric level.
Mirror catalog entries as catalog-info.yaml
Convert the exported ownership and service records into catalog-info.yaml descriptors so each component, system and group exists in Backstage with the same owner as in OpsLevel. Validate the descriptors against the Backstage descriptor format and load them into a non-production catalog. The step is complete when every service in the OpsLevel export appears once in the Backstage catalog with the expected owner and lifecycle.
Run both systems in parallel and compare
Keep OpsLevel scoring as the official result while Tech Insights evaluates the same entities. Record each service's level in both systems on every run and export the differences into a comparison report. Expect mismatches at first, since scoring logic, data freshness and scope rarely match on the first pass. The step is done when the comparison shows that scores agree for the agreed set of services over consecutive runs, and the team has signed off the criteria for agreement.
Fix mismatches and document each cause
Sort every mismatch into one of three causes: a wrong fact, a wrong rule or a catalog or ownership error. Correct the fact or rule, or the descriptor, and rerun the comparison until the causes are resolved. Record the cause and fix for each change, because auditors and team leads will ask why a score moved. The output is a change log that links each rule to the OpsLevel check it replaces.
Publish team-level progress in Backstage
Expose team-level maturity results on the Backstage side so each team sees its own services, the rule that failed and the remediation path. Share the scores with team leads before they become authoritative, and let them dispute results through a defined channel. The step is done when every team can view its results in Backstage and the platform group has confirmed that the displayed scores match the agreed comparison.
Retire OpsLevel checks in order
Switch the authoritative score to Tech Insights one team or rubric at a time, then disable the matching OpsLevel checks and keep the export archived for reference. Confirm ownership data is still accurate in both systems until the last switch, and check your OpsLevel contract or self-hosted license terms before you stop using the platform. The step is complete when no team relies on OpsLevel for scoring and the archived export has been verified.
Running Tech Insights beside OpsLevel during the transition
While OpsLevel and Backstage both run, each team needs clear answers on which system owns the scores, how the two sets of results are compared, and when reporting moves. The cards below cover those decisions and the network constraint that shapes them.
Naming the source of truth
Decide, per scorecard, which system's score is authoritative for leadership reporting and audits. Until a check has been re-created and validated in Tech Insights, OpsLevel should stay authoritative for that rubric, and Tech Insights results should be labeled as provisional. Record the decision in a short table with the owner of each rubric, so a team never sees two different maturity levels with no explanation.
Comparing parallel results
Run both systems against the same services for a fixed period and export results from each into a shared table keyed by service name or catalog reference. Flag every service where the two outcomes differ, then sort those mismatches into three groups: a check that was translated incorrectly, a data gap in the catalog, and a true difference in how the rule defines the standard. Only the first two groups should block cutover.
Entity ownership drift
Scores are only as accurate as the catalog behind them. During the overlap, ownership changes made in OpsLevel may not reach catalog-info.yaml files, and the reverse is also true. Choose one place where ownership edits are made during the transition, and run a recurring comparison of owner fields so a service does not score well in one system and belong to a different team in the other.
Self-hosted OpsLevel network needs
The self-hosted OpsLevel edition documents that its instance must be reachable over the internet for push-based integrations, and it is installed through Replicated with a license file from OpsLevel. In an isolated or tightly controlled network, confirm with OpsLevel which integrations depend on inbound access, and whether pull-based alternatives exist, before assuming both systems can run side by side in the same enclave.
Deciding when to switch reporting
Move leadership dashboards to Tech Insights only after several consecutive review cycles show agreement on the services in scope, and after the team owning each rubric signs off on its translated checks. Keep OpsLevel reports available for a defined read-only period so historical trends can be compared. Put the switch date and rollback conditions in the migration plan before the parallel run starts.
Tech Insights platform upkeep
Running Tech Insights during the transition means maintaining a Backstage instance, its database, and the tech-insights and tech-insights-maturity plugins alongside the existing OpsLevel tenant. Confirm the Backstage release line your team will follow and how plugin versions are pinned, because a plugin upgrade can change how a fact is stored or evaluated. Plan these upkeep tasks as recurring work, not one-time setup.
What teams ask before replacing OpsLevel rubrics
How much effort does migrating OpsLevel rubrics to Backstage take?
The effort depends mainly on how many checks you have, how much custom logic each one contains, and which data sources they read. Start by counting checks and grouping them by data source. Checks that read a single field from a catalog entity are usually simple to express as facts and rules. Checks that call external APIs, combine several systems or encode team-specific judgment take longer because each one needs a data source, a test and an owner. No public figure applies to your portfolio, so ask any implementation partner for a written breakdown of checks by complexity before agreeing to scope.
Can our own engineers migrate the rubrics without outside help?
Yes, if you have engineers who can write TypeScript plugin code, model facts and checks in the Tech Insights plugin, and read the Backstage documentation closely. Teams with a small number of checks and an existing Backstage instance often do this in-house. Outside help is more useful when you need a repeatable export process from OpsLevel, a shared set of fact definitions across many teams, or a test suite that proves each migrated check still gives the same answer. Decide this by comparing your current skills with the list of tasks in your written migration plan.
What skills does a self-hosted Backstage rubric setup require?
Plan for four areas: Backstage plugin development, Node.js application operations, PostgreSQL administration and ongoing plugin upgrades. Backstage uses PostgreSQL in production and gives each backend plugin its own logical database through Knex, so someone must own backups, migrations and capacity. Node.js support follows the versioning policy, which currently covers two adjacent even-numbered releases, so runtime upgrades will recur. Ask any vendor or partner which of these skills they will supply and which you must keep in house after handover.
Does Backstage have a paid edition I need to buy?
No. Backstage is an Apache License 2.0 framework, and the project itself offers no paid edition. The costs you still carry are infrastructure to host it, the engineering time to build and maintain your instance and plugins, and any support contract you choose to buy from a vendor or partner. Ask each partner to separate one-time build work from recurring hosting, upgrade and support work, so you can compare the two models on equal terms.
How do Backstage release cadence and security backports affect maintenance?
The main release line ships monthly on the Tuesday before the third Wednesday of each month, and the next release line ships weekly on Tuesdays. Plan a regular upgrade slot in your operating calendar rather than treating upgrades as occasional projects. The versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last 6 months if feasible, while other security fixes may be backported. That means an instance that falls more than six months behind may lose that protection, so schedule upgrades before the window closes.
Which quotes should we request before choosing a rubric migration approach?
Ask for quotes that follow from a written scope and list each component separately. Request the number of checks in scope, the data sources each one reads, the fact and rule definitions, the test approach, the hosting assumptions and the handover plan. Ask for recurring items separately from one-time work, including plugin upgrades, Node.js and PostgreSQL maintenance, and Backstage release tracking. Compare these against an internal estimate built from the same list, so the decision rests on like-for-like assumptions.
Will migrated checks give the same results as OpsLevel rubrics?
Not automatically. The Tech Insights plugin evaluates facts and checks against catalog entities, and the tech-insights-maturity plugin adds maturity rankings and categories, but your OpsLevel rubric logic must be re-expressed in those terms. Some OpsLevel checks may map cleanly while others need new data sources or changed definitions. Run old and new results side by side for a period, record every difference and agree in advance which team owns each one.
What the cost of replacing rubrics is made of
The Backstage software carries no licence fee, so the cost of replacing OpsLevel rubrics sits in hosting, build effort, plugin upkeep and support. Hosting means a Kubernetes cluster or virtual machine plus a PostgreSQL database, which Backstage uses in production. Build effort covers translating each rubric check into a Tech Insights fact and rule, wiring the data sources, and adding the team-level progress views. Ask whoever prices the work to itemize these lines separately, so you can see which ones your own engineers absorb and which go to an outside partner under a fixed scope.
Most of the translation and parallel-run work is one-time. Expect to pay for it once, while the old OpsLevel checks and the new Tech Insights rules report side by side until ownership data and scores agree. Recurring costs are the ones to budget for over time. Backstage ships a main release line monthly and a next release line weekly, so someone must test upgrades, update plugins and keep Node.js versions aligned with the versioning policy. Community plugins such as tech-insights-maturity need the same attention, and security fixes for high and critical vulnerabilities must be applied promptly. Costs rise with the number of custom checks, data sources and plugins, and fall when rubrics are kept simple.
The OpsLevel subscription is a separate line that does not disappear with the migration. If you keep a commercial edition running during the parallel period, the vendor's self-managed license still applies, and OpsLevel's self-hosted edition needs a license file and the 16 CPU and 16 GB minimum. Confirm with OpsLevel the notice period, data export terms and the date the subscription ends, and ask whether any export or read access is included after cancellation. Those dates, not the Backstage build plan, usually decide how long the two costs overlap.
How DeployOpen scopes and delivers a rubric migration
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For an OpsLevel maturity rubric migration, that means turning your existing checks into Backstage Tech Insights facts and checks, running them against your catalog, and handing your teams a working maturity view they can operate.
How we scope
- Inventory every OpsLevel rubric, level and check, with owners and the services each one applies to.
- Classify each check as a fact, a rule-based check, or a check to retire, and record the reason in writing.
- Agree in writing which Backstage deployment, data sources and team dashboards the fixed-scope engagement covers.
How we build
- Recreate rubric levels as Tech Insights maturity categories, using the tech-insights-maturity community plugin where it fits.
- Define facts and checks from the exported OpsLevel data, then test each rule against a sample of known services.
- Wire checks into your catalog-info.yaml conventions so ownership data and maturity results stay in sync.
How we hand over
- Document every fact, check and rule with its source, owner, and the catalog entities it evaluates.
- Walk your platform and team leads through the team-level progress views and how to read them.
- Provide a runbook for adding, changing and retiring checks, so your staff can maintain the rubric after handover.
How we support
- Ongoing support, plugin upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Ask for the support scope to name which Backstage releases and plugin versions it covers.
- Confirm with your own platform team who approves check changes and how rubric updates reach production.
