Everyone's talking about migrating CI/CD backends—from Jenkins to GitLab, CircleCI to GitHub Actions, maybe even to something obscure like Tekton. Fine. But then they slap Backstage on top and call it a "developer portal" like it's magic fairy dust that solves all the problems they just created.
I'm seeing a pattern. Teams spend months untangling pipeline spaghetti and migrating secrets, only to immediately introduce a new layer of abstraction and complexity. Backstage is sold as this unified front-end, but let's be real: it's another piece of vendor-ish software (yes, it's open-source, but who's really maintaining it?) that:
* Adds its own configuration hell (catalog-info.yaml files everywhere).
* Becomes the new single point of failure for developer self-service.
* Often just hides the underlying CI/CD vendor lock-in you were trying to avoid, but now with prettier UI.
So, for those who've actually done this: was it worth it? Or did you just trade one set of headaches for another? Specifically:
* How much ongoing developer time does it take to keep the Backstage catalog in sync with your actual, now-migrated, CI/CD pipelines?
* Did your "contract" with Backstage—in terms of maintenance overhead—end up costing more than the perceived developer productivity gains?
* Did it actually reduce vendor lock-in, or did it just add another platform your team is now locked into?
I'm skeptical the juice is worth the squeeze. Prove me wrong.
Just my 2 cents
Trust but verify.
Oh, I feel this so much. We went through a massive GitLab migration last year and immediately started looking at Backstage as the "finishing touch." The allure was real.
But that point about *"just hides the underlying CI/CD vendor lock-in"* hit home. We spent so much energy getting away from a monolithic Jenkins setup, only to build this elaborate Backstage facade that still, ultimately, pointed everything back to GitLab CI YAML files. The catalog-info.yaml files became this weird secondary source of truth we had to keep in sync with our repository structures. It felt like we'd added a documentation tax on every new microservice.
To answer your specific question on ongoing time: it was a huge initial lift to populate the catalog, and then it became a consistency problem. If a team renamed their service repo but forgot the .yaml file, links in Backstage would break. We probably spent a couple of engineering days a month just on catalog hygiene, which wasn't the payoff we'd hoped for.
It did help onboard new hires, I'll give it that. But as a unified front-end for our shiny new CI/CD? Mostly a very pretty directory. Maybe we implemented it wrong, but it often felt like polishing the door handle on a car that still needed a new engine.
Backup first.
Exactly my point. You swapped one concrete tool for another, then added a whole abstraction layer that does nothing but mirror it. That's not a portal, it's a fancy mirror.
The "documentation tax" is real. Those catalog files become technical debt the second your repo structure changes. I've seen teams spend more time keeping Backstage happy than actually using their CI/CD system.
If you need a directory, use your source control's structure. If you need onboarding docs, put them in the repo. Adding another system to manage systems is how we got here in the first place.
Simplicity is the ultimate sophistication