Migrating From Backstage to a Vendor Portal in 2026

The Trigger Pattern

Self-hosted Backstage migrations to vendor portals are typically triggered by one of three patterns. First, the platform team that built and operated the self-hosted Backstage has left, scaled down, or been redirected to other work. The framework upgrade tax stops getting paid; Backstage version slips behind upstream by a year or more; security patches accumulate; the portal starts to feel old and engineers' trust erodes. The organisation faces a choice: rebuild the platform team to operate Backstage (slow, expensive, depends on available platform-engineer talent) or migrate to a managed alternative.

Second, the organisation grows past the scale where self-hosted Backstage was the right choice, and the per-seat economics flip toward managed. This is less common than the first pattern but does happen at organisations whose growth shape changed (acquisitions, fast headcount growth, geographic expansion) and the portal was sized for a different organisational reality.

Third, the organisation needs portal capabilities that the self-hosted Backstage does not provide and would be more expensive to build than to buy. Common examples: heavy scorecard requirements (where Cortex's scorecard-first model is genuinely better than Backstage scorecards), strict compliance requirements that need vendor-provided certifications, integration with vendor-specific tools where the vendor offers a deeper portal integration than the open-source Backstage plugin.

Migration Work Detail

The work breaks into four phases. Catalogue export and import: the Backstage catalogue is a known schema (YAML files with entity definitions) and exports cleanly. The import to the vendor portal is straightforward when the vendor has a Backstage-compatible importer, more involved when it does not. Cortex, Port, and OpsLevel all have Backstage catalogue importers; the work is mostly validating that entity types map correctly and that custom entity fields are preserved (the latter is often where information is lost). Typical cost: $20,000 to $40,000 of platform-team time.

Scorecard rewrite: if you have invested in Backstage scorecards (using the soft-card or similar plugin patterns), the rules have to be rewritten in the vendor portal's scorecard rule language. The conceptual translation is usually clean; the syntactic translation is fiddly. The data sources the scorecards consult also need to be re-integrated. Typical cost: $15,000 to $40,000 if you have a meaningful scorecard estate; close to zero if you have not.

Plugin replacement: this is usually the largest line. Backstage plugins do not run on vendor portals; the equivalent functionality has to come from the vendor portal's native integrations or from custom integrations built against the vendor's plugin extension model (where one exists). For each plugin in your Backstage deployment, you face a choice: vendor-native equivalent exists (cheap, just configure it), vendor-supported integration via their extension model (medium cost to rebuild), no equivalent (either accept the functionality loss or budget for ongoing custom work). Typical cost: $25,000 to $80,000 depending on how custom the original Backstage was.

Ownership and discovery work: the catalogue ownership data, golden-path templates, and TechDocs all need attention during migration. Ownership data usually transfers but some manual cleanup is needed. Golden-path templates may need rewriting if the vendor portal's scaffolder uses a different template format. TechDocs migration depends on the vendor; some commercial portals have TechDocs-equivalent capability, some require migration to a different documentation pattern. Typical cost: $20,000 to $40,000 of platform-team time.

When Migration Does Not Make Sense

Three patterns suggest staying on Backstage rather than migrating. First, the platform team is intact and capable. The framework upgrade tax of 4 to 8 engineer-weeks per year is a real but absorbable cost for a healthy platform team; migrating to avoid it transfers cost from internal time to vendor licence, which is not obviously cheaper at small to mid scale.

Second, significant custom-plugin investment has been made that does not have an obvious vendor-portal equivalent. Migrating loses the custom plugin functionality unless the migration also includes rebuilding equivalent custom plugins on the new portal, which doubles the migration cost. Custom plugins that wrap proprietary internal systems are particularly problematic because no commercial vendor offers an equivalent integration; the migration either has to include rebuilding these on the vendor portal's extension model or accept the loss.

Third, strong organisational preference for open-source substrate or against vendor lock-in. Backstage is CNCF open source; migrating to a commercial vendor creates a real lock-in (the catalogue data is in the vendor's format, the plugin integrations are in the vendor's extension model, the future is at the vendor's pricing and product direction). For organisations that value avoiding this lock-in, the right answer to operational difficulty with self-hosted Backstage is to fix the operational difficulty (hire, train, restructure the platform team) rather than to migrate to a different lock-in.

The Managed-Backstage Alternative Path

For organisations where the trigger is operational difficulty with self-hosted Backstage rather than a strategic preference for a different portal model, the Backstage-to-managed-Backstage migration is structurally simpler than the Backstage-to-different-vendor migration. Migrating to Roadie or Coderpath preserves the catalogue investment entirely (it is still Backstage catalogue), preserves the golden-path templates entirely (they are still Backstage templates), preserves most plugins (the managed provider's curated catalogue includes the most common ones; bring-your-own-plugin is supported for the rest), and removes the runtime operations burden that triggered the migration. Typical cost: $30,000 to $80,000 over 2 to 4 months. This is often the right first migration step for organisations whose primary problem is operational rather than capability-related.