Platform Engineering 2026: Should We Abandon Our Self-Hosted Backstage for Managed Solutions?

General
1

We’ve been self-hosting Backstage for 18 months, and I’m facing a decision I’ve been postponing: do we keep investing in our DIY developer portal, or do we bite the bullet and move to a managed solution?

The Reality Check

Our platform team started strong. We had grand visions of creating a best-in-class developer portal with custom integrations, bespoke workflows, and deep customization. We sold leadership on “flexibility” and “control.”

18 months later, here’s what we actually have:

  • A Backstage instance that requires 2 engineers to maintain (40% of our platform team)
  • Plugin upgrades that break every quarter
  • Adoption hovering around 12% because we’re too busy maintaining infrastructure to build features developers want
  • A backlog of 47 “nice to have” integrations we’ll never build

According to recent data, Backstage’s true cost of ownership is around $150,000 per 20 developers. We’re tracking slightly higher because we underestimated the plugin ecosystem complexity.

The Build vs. Buy Calculus Has Changed

In 2022, DIY made sense—Backstage was new, managed solutions were immature, and we needed custom integrations. But in 2026, the equation is different:

Managed Backstage solutions like Roadie now offer:

  • Automatic upgrades without breaking plugin compatibility
  • Enterprise-grade reliability out of the box
  • Built-in integrations that would take us months to build
  • A fraction of the cost of a dedicated team

Meanwhile, our DIY approach means we’re spending 40% of platform engineering capacity on table stakes functionality instead of building the unique Golden Paths that would actually differentiate our developer experience.

Gartner predicts 80% of large software orgs will have platform teams by 2026, up from 45% in 2022. But the real question isn’t whether to invest in platform engineering—it’s where you invest your limited platform engineering capacity.

The Uncomfortable Truth

Here’s what I’ve realized: The developer portal is not our differentiator. Our competitive advantage isn’t in having a custom-built catalog UI. It’s in the domain-specific templates, the intelligent deployment pipelines, the compliance-aware workflows that reflect our industry’s unique requirements.

But we’ll never build those if we’re stuck maintaining a framework.

Recent surveys show 91% still self-host vs 9% on managed platforms, but this ratio is shifting as organizations recognize the operational burden. The maintenance reality is brutal: every Backstage release, every plugin version, every upstream API deprecation requires attention.

The Decision Framework

I’m using this lens:

Build if:

  • Your portal requirements are genuinely unique (not just “we like it our way”)
  • You have 3+ dedicated platform engineers to sustain it long-term
  • Portal customization is a core business differentiator
  • You’re Google/Netflix/Spotify-scale where DIY economics work

Buy/Managed if:

  • You’re under 500 engineers
  • Your platform team is stretched thin
  • Your differentiators are domain-specific, not UI-level
  • You’d rather focus on Golden Paths than dependency management

What I’m Leaning Toward

I’m 80% convinced we should move to managed Backstage. The cost is $8-15/developer/month vs our current $150k/year in engineering time (for our 200-dev org). That’s not even close.

But I’m hesitating because of sunk cost bias, team pride, and the perception that “buying = giving up.” The engineers who built our portal feel ownership. Moving to managed feels like admitting defeat.

Has anyone made this transition? How did you handle the team dynamics? Did you regret the switch, or wish you’d done it sooner?

For those still self-hosting: what would it take for you to switch? And for those on managed solutions: what convinced you to skip the DIY phase entirely?

2

David, this resonates deeply. I made this exact transition 8 months ago at my previous company, and it was one of the best architectural decisions we made—but the human side was harder than the technical migration.

What Convinced Me to Switch

The breaking point was when we needed to upgrade our Backstage instance to get a critical security patch, and it took 3 weeks because of plugin compatibility issues. During those 3 weeks, my platform team couldn’t work on the service mesh migration that was blocking two product teams.

That’s when I realized: we were optimizing for the wrong layer of the stack.

Your framework resonates, but I’d add one more dimension: opportunity cost. Every hour maintaining Backstage is an hour not spent on:

  • Building deployment guardrails that prevent production incidents
  • Creating self-service workflows that reduce ticket toil
  • Implementing compliance automation that makes audits painless

These are the platform capabilities that actually move the business needle. A catalog UI? That’s table stakes.

Handling Team Dynamics

This was the hardest part. Two engineers had spent 6 months building custom plugins, and moving to managed felt like throwing away their work.

Here’s what worked:

  1. Reframed it as unlocking capacity, not admitting failure. “We’re not giving up—we’re reallocating engineering talent to higher-value problems.”

  2. Let them own the migration. The engineers who built the DIY portal evaluated vendors, designed the migration plan, and led the cutover. They became experts in the managed platform.

  3. Redirected their energy immediately. Week 1 post-migration, they started building the custom integrations we’d been deferring for a year. Within 6 weeks, developer satisfaction scores jumped 40% because we were finally shipping features.

The Unexpected Benefits

Beyond the obvious cost savings, we gained:

  • Faster onboarding: New platform engineers could contribute immediately without learning Backstage internals
  • Better vendor relationships: Our managed provider’s roadmap aligned with our needs—they built features we would’ve had to DIY
  • Reduced bus factor: No more “only Sarah understands the plugin architecture” risk

The Honest Assessment

Would I self-host again? Only if I had 5+ dedicated platform engineers AND portal customization was genuinely core to our competitive advantage. For 99% of companies, that’s not true.

The 91% self-hosting stat you cited is misleading—it’s a lagging indicator. Most of those teams are where you are now: questioning the DIY decision but hesitant to switch due to sunk cost bias.

Your 80% conviction is justified. The team pride concern is real, but channel that pride toward building differentiated platform capabilities, not maintaining OSS frameworks.

One caution: Don’t cheap out on the managed solution. We evaluated 4 vendors. The cheapest option had terrible support and we would’ve regretted it. Roadie and Red Hat Developer Hub were the finalists—we went with Roadie for their Backstage-native approach.

What specific concerns are in your remaining 20% of doubt?

3

I’m going to offer a counterpoint, because I think the “DIY is dead” narrative oversimplifies a nuanced decision.

We self-host Backstage for 400+ engineers, and it works—but the key word is works, not thrives. I’m not evangelizing our approach; I’m just sharing why we haven’t switched yet and what would change my mind.

Why We’re Still Self-Hosting

1. Regulatory Constraints
We’re in financial services. Our compliance team requires that all developer tooling runs in our VPC with specific audit logging, data residency guarantees, and SOC 2 Type II controls that we directly manage. Some managed solutions meet these requirements, but the procurement process is 6-9 months of vendor assessments.

2. Deep Customization
Our developer portal isn’t just a catalog. It’s integrated with:

  • Our internal compliance workflow engine (every deployment requires specific approvals based on data classification)
  • Custom cost attribution that maps cloud spend to business units using our GL codes
  • Proprietary security scanning that enforces policies unique to our industry

These aren’t vanity features—they’re business-critical workflows that would be expensive to replicate via API integrations with a managed platform.

3. Team Size Justifies It
We have 6 platform engineers. That’s enough capacity to maintain Backstage AND build differentiated capabilities. Your 5-person team with 2 dedicated to maintenance? That’s a different story.

Where I Agree With You

Your 40% capacity going to maintenance is the red flag. That’s unsustainable.

David, your adoption rate is 12%. That’s the real problem. Low adoption means developers aren’t getting value, which means your platform team is maintaining infrastructure nobody wants. Even if you switched to managed, would adoption improve? Or is the problem deeper—wrong features, poor UX, lack of champion users?

Before you switch, diagnose: Is low adoption because you’re too busy maintaining to add features? Or because the portal solves the wrong problems?

If it’s the former, managed makes sense. If it’s the latter, switching providers won’t fix it.

The Middle Path Nobody Talks About

There’s an option between “full DIY” and “fully managed”: Backstage-as-a-Service for infrastructure, but you own the customization layer.

Some vendors (Port, OpsLevel) offer this model: they host the core platform, you plug in your unique workflows via APIs and plugins. You get reliability and upgrades without losing deep customization.

What Would Make Me Switch

Three scenarios:

  1. Compliance unlocks: If a managed vendor gets our required certifications AND our procurement team pre-approves them, I’d seriously consider it
  2. Team turnover: If we lose 2+ platform engineers and can’t backfill, managed becomes necessary for continuity
  3. Cost comparison shifts: If a managed provider could replicate our custom workflows for <$50/dev/month, I’d evaluate

Advice for Your Decision

Michelle’s framework is excellent. I’d add: Consider the migration cost. Moving 200 developers from a self-hosted portal they barely use (12% adoption!) to a managed one is still an organizational change effort. You’ll need:

  • Data migration planning
  • User re-onboarding and training
  • Custom integration rebuilds
  • Service continuity during cutover

Budget 3-6 months of transition time. If your team is already underwater, can you afford that investment now, or do you need to stabilize first?

My take: Given your team size, capacity constraints, and low adoption, I’d lean toward managed. But don’t let “DIY is dead” industry narratives pressure you. Make sure managed actually solves YOUR problem (capacity constraints), not a generic industry problem.

What’s your current adoption bottleneck? Is it features, UX, or awareness?

4

I’m coming at this from a design perspective, but I think there’s a huge elephant in the room that neither of you mentioned: developers don’t care about your build vs buy decision if the portal doesn’t solve their actual problems.

I’ve watched this pattern play out twice—once at my failed startup, once at my current company:

  1. Platform team builds/buys a developer portal with good intentions
  2. Team obsesses over technical implementation details (DIY vs managed, plugin architecture, etc.)
  3. Portal launches with minimal user research
  4. Adoption is terrible
  5. Team blames “lack of features” and doubles down on building more
  6. Still no adoption, because nobody asked developers what they actually need

David, your 12% adoption rate is screaming this at you. Before you spend 3-6 months migrating to managed, have you actually talked to the 88% who aren’t using it?

What I’ve Learned From Developer Portal Adoption Failures

At my startup, we built a beautiful internal tool portal. Gorgeous UI, great UX, thoughtful information architecture. Nobody used it. Why? Because developers had already built muscle memory around other tools. Our portal solved problems they didn’t know they had, while ignoring the daily friction they complained about constantly.

At my current company, we almost made the same mistake until we did user research. Turns out developers weren’t asking for a “portal”—they wanted:

  • Faster answers to “who owns this service?” (solved with a Slack bot, not a portal)
  • Less time in CI/CD troubleshooting (solved with better observability, not a portal)
  • Clearer onboarding docs (solved with README templates, not a portal)

The portal exists now and is moderately successful, but it’s not the hero. It’s a supporting actor.

The Uncomfortable UX Truth

Michelle, you mentioned developer satisfaction scores jumped 40% after migration. That’s amazing! But I’d bet it wasn’t because you switched from DIY to managed—it was because post-migration, your team finally had capacity to build features users wanted.

The managed vs DIY decision is orthogonal to user value. You can have a self-hosted portal users love, or a managed portal users ignore. The architecture doesn’t determine adoption—user-centricity does.

My Advice

Before you migrate, run a 2-week user research sprint:

  1. Interview 20 developers (include non-users!): What problems do you face daily? How do you currently solve them? What would make your workflow better?

  2. Map current portal features to actual user needs. How many features solve real problems vs “seemed like a good idea”?

  3. Identify the top 3 highest-impact features that don’t exist yet. Are these portal-appropriate, or are they better solved elsewhere (Slack bots, IDE plugins, docs)?

  4. Prototype the top 3 features (low-fidelity). Get feedback BEFORE building.

If you do this research and conclude “we need managed to unlock capacity for these high-impact features,” then Michelle’s advice is spot-on. But if research reveals “the portal concept itself isn’t valuable,” you might need a different solution entirely.

The Sunk Cost Trap

You mentioned team pride and sunk cost bias. I get it—I fought this when my startup failed. We’d spent 18 months building something nobody wanted, and admitting that felt like personal failure.

Here’s the reframe that helped me: The fastest way to honor your team’s work is to learn from it and build something better. Whether “better” means managed Backstage, a different tool, or no portal at all—let user research guide you, not ego or industry trends.

Luis’s question is the right one: What’s your adoption bottleneck? Until you answer that, you’re optimizing the wrong variable.

(Also, selfishly: if you do user research and share findings, that would be fascinating content! We need more public case studies on why developer portals fail/succeed beyond “look at our tech stack.”)

5

All three of you are raising excellent points, but I want to address the organizational dynamics that David hinted at: how do you get leadership buy-in for what looks like backtracking?

I’ve navigated this twice—once when we abandoned a custom-built CI/CD system for GitHub Actions, and once when we moved from self-hosted Kubernetes to GKE. Both times, leadership initially resisted because “we already invested in the DIY solution.”

The Business Case for Switching

David, your cost comparison ($150k/year engineering time vs $8-15/dev/month managed) is compelling, but you need to translate it into business outcomes leadership cares about:

Don’t say:
“We want to move from DIY to managed Backstage because maintenance is hard.”

Instead say:
"By reallocating 40% of platform engineering capacity from Backstage maintenance to high-impact automation, we can:

  • Reduce deployment cycle time by 30% (enabling faster product iterations)
  • Cut production incidents by 20% through better guardrails
  • Decrease onboarding time from 2 weeks to 3 days
  • Unblock 2 product teams currently waiting on platform capabilities"

Translate engineering efficiency into revenue impact or risk reduction. That’s what gets CFO and CEO approval.

Addressing the “Admitting Defeat” Perception

This is where Michelle’s framing about “unlocking capacity” is perfect. But I’d go further:

Position the switch as strategic evolution, not failure.

At my EdTech startup, I used this narrative:
“In 2022, self-hosting made sense because we needed custom integrations and the managed ecosystem was immature. We learned what works and what doesn’t. Now in 2026, the market has matured. Continuing to DIY would be ignoring market evolution—that’s the real strategic mistake.”

Leadership loves “we’re adapting to market shifts.” It sounds proactive, not reactive.

Luis’s Regulatory Concern Is Real

Luis, your compliance constraints are a legitimate blocker. But I’d challenge: Have you actually evaluated 2026 managed solutions, or are you assuming they don’t meet requirements?

Roadie has SOC 2 Type II, GDPR compliance, and offers private cloud deployments. Red Hat Developer Hub has FedRAMP authorization for government customers. The managed landscape has matured significantly in 18 months.

I’m not saying they definitely meet your needs—but procurement timelines are painful, and you might be surprised at how much has changed. Worth a vendor evaluation.

Maya’s UX Point Is Critical

Maya is absolutely right: low adoption is the real crisis, not DIY vs managed.

David, here’s a forcing function: Before you migrate, define success metrics.

If you switch to managed and 6 months later adoption is still 15%, you’ve solved the wrong problem. But if adoption jumps to 60%+ because your team finally has capacity to build valuable features, the migration was worth it.

I’d recommend this sequence:

  1. Week 1-2: User research (Maya’s 2-week sprint)
  2. Week 3: Build business case with leadership (revenue/risk framing)
  3. Week 4-6: Vendor evaluation (Roadie, Port, Cortex, Red Hat—get demos, check compliance)
  4. Week 7-8: Pilot phase with 20 developers on managed platform
  5. Week 9-12: Full migration if pilot shows adoption improvement

This gives you data to validate the decision before committing fully.

The Hidden Benefit: Retention

One thing nobody mentioned: Platform engineers don’t want to maintain OSS frameworks—they want to build impactful platform capabilities.

I’ve lost 2 strong platform engineers to other companies because they were bored with “keeping the lights on” vs doing creative engineering. Switching to managed didn’t just free up capacity—it improved team morale and retention.

Your engineers who built the portal might actually be relieved if you reframe it as “now you get to build the cool stuff we’ve been deferring.”

My Recommendation

Given what you’ve shared:

  • 5-person team with 40% on maintenance = unsustainable
  • 12% adoption = not delivering value
  • $150k/year cost vs <$40k managed = clear ROI

You should switch. But do Maya’s user research first to ensure you’re building on the managed platform what users actually need.

And David—when you present to leadership, emphasize this: We’re not abandoning platform engineering. We’re focusing our platform engineering investment on differentiated capabilities instead of commodity infrastructure.

That’s a strategic strength, not a retreat.