Feature Overview (aka. Goal Summary)

This feature covers the migration of Red Hat Developer Hub (RHDH) from the "old" frontend architecture to the New Backstage Frontend System. This is a major architectural shift initiated by the upstream CNCF Backstage project to move toward a more declarative, extensible, and modular integration model.

For RHDH, this migration is critical to maintaining upstream alignment and enhancing our Dynamic Plugin capabilities.

Goals (aka. expected user outcomes)

• Developers experience a more consistent UI performance and faster load times due to the modular nature of the new frontend system.

• Internal RHDH Engineering reduces technical debt by aligning with the upstream @backstage/frontend-plugin-api.

• Custom Plugin Developers have a clear, documented path to migrate their existing frontend plugins to the new system, ensuring their internal portals remain functional post-update.

Requirements (aka. Acceptance Criteria):

• As a Platform Engineer, I want the RHDH core to initialize using the New Frontend System framework, so that I can leverage the latest upstream features and security patches.

• As a Platform Engineer, I want the Dynamic Plugin Mechanism to be fully compatible with the new system, ensuring that plugins loaded at runtime can correctly register "extensions" (routes, sidebar items, etc.).

• As a Developer, I want all core RHDH plugins (Catalog, Scaffolder, Software Templates, TechDocs, RBAC, Orchestrator, Lightspeed, etc.) to be fully migrated and functional, so that my daily workflow is uninterrupted.

• As a Security Engineer, I want to ensure that the migration does not introduce vulnerabilities in how dynamic code is executed within the new declarative framework.

• As a Plugin Developer, I want access to a "Migration Guide" that details how to wrap legacy components into the new createExtension and createPlugin APIs.

Out of Scope

• Visual Redesign: This is an architectural migration; changing the UX/UI theme or branding is out of scope unless required by the new framework.

• Support for "Legacy-only" Plugins: We will not provide a long-term shim for plugins that refuse to migrate to the new API after the transition period.

Customer Considerations

• Dynamic Plugin Compatibility: Many customers rely on RHDH specifically for its ability to load plugins dynamically. We must verify that the "Discovery" phase of the new frontend system can successfully hook into our dynamic loading logic.

• RBAC Alignment: We need to ensure that the Role-Based Access Control (RBAC) plugin correctly hides/shows extensions based on the new frontend permission hooks.

Documentation Considerations

• Release Notes: Must clearly state the version where the new system becomes the default.

• Migration Guide: A dedicated section in the RHDH documentation for migrating custom frontend plugins, including "Before vs. After" code snippets.

• Configuration Schema: Updated documentation for app-config.yaml to show how to enable/disable extensions and change UI layouts using the new declarative syntax.