Backstage plugin migration at a global enterprise
Backstage’s new frontend system had landed. For a global enterprise running Backstage at scale, that meant migrating an entire plugin ecosystem onto it.
The new system changed how plugins attach to the instance and how they are displayed. Adopting it was the right call. It would keep the platform on the supported path, and it would make plugin development easier to onboard onto. The migration was the bridge to get there.
The problem behind the migration
The change was being made for two reasons:
- Developer experience. Onboarding a new contributor onto a plugin was harder than it needed to be. The new frontend system gave plugins a cleaner, more predictable way to attach inside Backstage, which meant new developers could spend less time learning the surrounding scaffolding and more time on the plugin itself.
- Architectural alignment. The new frontend system was built to follow the direction Backstage itself is heading, which keeps the platform on the actively supported path and ready for future upgrades.
For an enterprise running Backstage at scale, both reasons mattered. The new front-end system was the right destination. Adopting it required migrating the existing plugins to work with it.
One principle stayed clear throughout. The change should happen in the code, not in the experience. At the user level, the plugins still need to behave exactly the same way.
A standard system meeting a different architecture
The complexity of this migration came from the difference between Backstage’s standard frontend approach and the architecture of the client’s platform.
Backstage’s new frontend system defines a standard way for plugins to attach and render. The client’s platform had its own requirements, shaped by how the team had been working with Backstage. The plugins in the ecosystem reflected those requirements.
The migration was about fitting the new frontend system into that setup. Some plugins mapped onto the standard cleanly. Others did not, especially where the way pages were displayed had been built around different requirements.
Where real Backstage experience made the difference
Dewise was brought in through DevTeam TO-GO, a cross-functional team that plugs directly inside the engineering organisation. Backstage is one of the platforms Dewise works with regularly, and that experience is what we were brought in for.
The migration itself was not the hard part. The hard part was fitting a standard frontend system into a platform with its own requirements, across a large plugin ecosystem, without disrupting the teams relying on it every day. That meant understanding both sides well enough to know where the standard could be applied directly, and where the architecture needed the migration handled differently.
The migration itself was not the hard part. The hard part was fitting a standard frontend system into a platform with its own requirements, across a large plugin ecosystem, without disrupting the teams relying on it every day. That meant understanding both sides well enough to know where the standard could be applied directly, and where the architecture needed the migration handled differently.
Those are the things that come from having worked with Backstage before.
Using AI to accelerate the work
The migration was complex partly because of the volume. A large plugin ecosystem, many similar changes, and a timeline that could not stretch indefinitely. AI made a real difference here, but the impact looked different at different stages of the work.
Early stage: mapping the architectural difference
Each plugin sat at a different point of distance from Backstage’s standard. AI helped interpret how the plugins were currently structured and where they diverged from what the new frontend system expected. This significantly reduced the time needed to map the migration path for each plugin.
Later stage: handling volume
Once clear patterns were established, AI was used to apply those patterns across the remaining plugins. Each output was still reviewed, tested, and validated by the team. AI handled repetition. The team handled decisions. That separation made the migration scalable without compromising quality.
What actually changed
The outcome is not just a completed migration. It is a stronger platform.
- The plugin ecosystem now runs on Backstage’s supported frontend architecture
- Onboarding new contributors is faster and more predictable
- The platform is easier to maintain and extend
- Future upgrades are no longer a risk
The migration was the mechanism. The real result is a platform ready for what comes next.
Built for this kind of work
Backstage plugin migration at enterprise scale is complex. It requires more than following a guide. It requires experience with the platform, understanding how enterprise architectures shape it, and the ability to execute without disruption.
This is exactly what DevTeam TO-GO is built for. Embedded teams. Real platform experience. Delivery that holds under pressure.