plugin-full-frontend-system-migration

Migrate Backstage plugins from the old backend to the frontend system.

Updated Mar 27, 2026
One-click install
npx skills add https://github.com/transaurus/staging-backstage-backstage --skill plugin-full-frontend-system-migration-transaurus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: plugin-full-frontend-system-migration
Source: https://github.com/transaurus/staging-backstage-backstage/tree/main/docs/.well-known/skills/plugin-full-frontend-system-migration
Command: npx skills add https://github.com/transaurus/staging-backstage-backstage --skill plugin-full-frontend-system-migration-transaurus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Migrating Backstage plugins from the old backend to the frontend system to remove dual support and lock in a single, future-proof deployment path.

Core Features & Use Cases

  • Complete migration of plugin codebase to the frontend system, including route refs, APIs, pages, and internal routing.
  • Removes @backstage/core-plugin-api usage and adopts @backstage/frontend-plugin-api, PageBlueprint, SubPageBlueprint, and ApiBlueprint.
  • Guidance for internal apps that run a single plugin and for published plugins aiming to drop backward compatibility.

Quick Start

Start by migrating route refs and API factories, then convert pages to PageBlueprint and SubPageBlueprint, and finally remove old system code and dependencies.

Frequently Asked Questions about plugin-full-frontend-system-migration

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate Backstage plugins to the frontend system?

Migrate Backstage plugins by replacing core-plugin-api with frontend-plugin-api, converting pages to PageBlueprint and SubPageBlueprint, and moving route refs and APIs to the frontend system to remove dual support.

What is the best way to drop backward compatibility for published Backstage plugins?

Dropping backward compatibility for published Backstage plugins requires migrating route refs, APIs, pages, and internal routing to the frontend system using PageBlueprint, SubPageBlueprint, and ApiBlueprint to lock in a future-proof deployment path.

How does adopting PageBlueprint and SubPageBlueprint work in Backstage frontend migration?

Adopting PageBlueprint and SubPageBlueprint involves converting existing page components into blueprint definitions under the frontend-plugin-api, replacing old core-plugin-api structures to enforce new API ownership rules.

When do I need to remove @backstage/core-plugin-api during frontend system migration?

You need to remove @backstage/core-plugin-api when migrating plugin codebases to the frontend system to eliminate dual support, replacing it entirely with @backstage/frontend-plugin-api and updating API factories.

Can I migrate internal Backstage app plugins that run in a single app to the frontend system?

Internal Backstage app plugins running in a single app can be migrated to the frontend system by updating route refs, APIs, and pages using PageBlueprint and SubPageBlueprint to enforce new API ownership rules.

What are the limitations of migrating Backstage plugins to the frontend system?

Migration limitations include dropping backward compatibility for published plugins, requiring complete replacement of core-plugin-api with frontend-plugin-api, and enforcing strict API ownership rules across route refs and APIs.