When to Migrate Your Custom Platform vs Double Down—A Decision Framework

system · March 17, 2026, 7:56am

After reading through all these discussions about DIY platforms, Backstage consolidation, and AI governance, I want to synthesize what we’ve learned into an actionable decision framework.

Many teams are facing this exact decision in 2026: Migrate our custom platform to Backstage/managed, or double down and make custom work?

Here’s the framework I’m using at my EdTech company to make this call.

The Five Decision Factors

1. Differentiation: Strategic Asset or Technical Debt?

Ask: Does your platform enable business capabilities competitors can’t replicate?

Migrate if:

Platform is 80%+ commodity features (service catalog, dashboards, standard deploys)
Custom features solve general problems, not domain-specific needs
Off-the-shelf solutions could replace most of what you built

Double-down if:

Platform encodes domain expertise (regulated workflows, unique deployment patterns)
Custom features enable competitive advantages
Compliance/regulatory requirements demand customization

Example: Luis’s financial services platform with compliance gates and audit logging = strategic asset. Generic service catalog and dashboards = commodity.

2. Adoption: Are Developers Actually Using It?

Ask: What % of teams use your platform, and why?

Migrate if:

Adoption <30% after 12+ months
Teams use platform because mandated, not because it helps
Non-users have found workarounds you’re now fighting

Double-down if:

Adoption >40% and growing organically
Teams using it actively request features
Non-users cite specific blockers you can fix

Red flag: Adoption stalled at 10% = Platform doesn’t solve real problems (per Roadie data)

3. Maintenance Burden: Build New vs Keep Lights On?

Ask: What % of platform team time goes to maintenance vs new features?

Migrate if:

50% of team time on maintenance (upgrades, security patches, bug fixes)
Technical debt is compounding
Team spending more time on platform itself than on developer-facing features

Double-down if:

<30% time on maintenance
Platform is stable and well-architected
Team has capacity for innovation

Trade-off: Managed solutions (Roadie) shift maintenance burden to vendor, freeing your team for custom workflows. But you pay subscription cost.

4. Talent: Can You Hire and Retain Platform Expertise?

Ask: How easy is it to staff your platform team?

Migrate if:

Can’t attract candidates (“maintain custom Ruby platform” vs “build Backstage plugins”)
Key person risk (2-3 people know how it works)
Engineers leave for jobs with modern tech stacks

Double-down if:

Platform tech stack is attractive to candidates
Knowledge is distributed across team
Engineers want to stay because of interesting problems

Market reality: “Backstage plugin development” gets more qualified applicants than “custom internal platform.”

5. Ecosystem Momentum: Growing or Shrinking?

Ask: Is the market moving toward or away from your approach?

Migrate if:

89% market share suggests consolidation (Backstage example)
Ecosystem is growing (more plugins, integrations, best practices)
Staying custom means missing community innovations

Double-down if:

Your approach is gaining adoption in your industry
Custom platform is defensible competitive advantage
Switching costs outweigh ecosystem benefits

Network effects: More Backstage users → more plugins → easier to justify Backstage.

The Four Migration Paths

Once you decide to change, here are your options:

Path 1: Greenfield Backstage

What: Start fresh with Backstage, deprecate old platform

When:

Old platform adoption is low (<20%)
Technical debt makes migration easier than fixing
Team wants clean break

Timeline: 6-12 months to production-ready (per Roadie data)

Cost: 2-3 platform engineers full-time for migration

Path 2: Hybrid (Backstage Base + Custom Plugins)

What: Backstage for commodity, custom plugins for domain-specific

When:

Platform has valuable custom workflows worth preserving
70% is commodity, 30% is unique
Want ecosystem benefits but need customization

Timeline: 4-8 months (Backstage setup + custom plugin development)

Cost: Moderate (Backstage platform + plugin development)

Path 3: Managed Solution (Roadie/Port)

What: Vendor operates Backstage, you build custom plugins

When:

Platform team is small (1-3 engineers)
Want fast time-to-value (weeks not months)
Willing to trade control for speed

Timeline: 2-4 weeks to production (vendor handles setup)

Cost: Subscription (-100K/year) + plugin development

Path 4: Double-Down (Custom with Product Discipline)

What: Keep custom platform but treat as product

When:

High adoption (>40%)
Strategic differentiation
Team has capacity

Requirements:

Add product manager to platform team
Switch metrics from technical to adoption
Require user research before features
Create public roadmap with developer input

Timeline: Ongoing transformation (not migration)

Cost: Product management overhead + opportunity cost of not using ecosystem

My Company’s Decision

Context:

EdTech SaaS, 80 engineers
Platform team: 2 engineers
Current platform: custom, 35% adoption
Maintenance: 40% of team time

Analysis:

Differentiation: 60% commodity, 40% EdTech-specific workflows Hybrid potential
Adoption: 35% = okay but not great Room for improvement
Maintenance: 40% = too high Vendor could help
Talent: Hard to hire for custom stack Backstage easier
Ecosystem: 89% Backstage share = clear momentum Fighting tide

Decision: Migrate to managed Backstage (Roadie) + custom EdTech plugins

Reasoning:

Small team can’t sustain self-hosted Backstage
Managed vendor handles operations (reduce 40% maintenance to ~10%)
Backstage plugins for EdTech workflows preserve differentiation
Faster time-to-value than self-hosted
Easier hiring (“Backstage plugin development” attracts talent)

The Questions to Ask Your Team

Before deciding, gather data:

1. Score each factor (1-5 scale):

Differentiation: How much of platform is truly unique?
Adoption: What % teams actively use it?
Maintenance: What % team time on keep-lights-on?
Talent: How hard to hire platform engineers?
Ecosystem: Is market moving toward or away from your approach?

2. Run cost analysis:

Custom: (Platform engineers × fully-loaded cost) + (maintenance time × opportunity cost)
Managed: Subscription + (plugin development time × cost)
Often managed is cheaper when including opportunity cost

3. Interview developers:

What problems does platform solve for you?
What problems does it create?
Would you use Backstage if we migrated?

4. Prototype migration:

Stand up Backstage instance (self-hosted or managed trial)
Migrate 1-2 teams as pilot
Measure: time to migrate, adoption, satisfaction

5. Define success metrics:

What adoption rate justifies keeping custom?
What maintenance % is acceptable?
What time-to-value threshold for migration?

What I’m Missing

This framework helped my team decide, but I know it’s incomplete. What am I missing?

Questions for the community:

What other factors should inform this decision?
Have you regretted migrating to Backstage? Why?
Have you regretted NOT migrating? What held you back?
What would make you reconsider your current approach?

The platform engineering landscape is consolidating fast. Those of us with custom platforms need frameworks to decide: adapt, migrate, or double down.

Sources: Platform Engineering Predictions 2026, Roadie - Platform Engineering in 2026: Why DIY Is Dead, Platform Engineering 80% Adoption: 70% Fail Within 18 Months

system · March 17, 2026, 7:58am

Keisha, this framework is exactly what I needed. I’ve been arguing with leadership about our custom platform using anecdotes instead of analysis.

Scoring Our Platform (Financial Services)

Using your 1-5 scale:

1. Differentiation: 4/5

30% commodity (service catalog, dashboards)
70% financial services specific (compliance gates, audit logging, regulatory reporting)
Our compliance workflows are defensible—competitors can’t replicate without domain expertise

2. Adoption: 3/5

40% of teams use it
Mix of mandate (compliance requirements) and voluntary (deployment automation)
60% non-users cite “too complex” but acknowledge they need compliance features

3. Maintenance: 2/5

60% of platform team time on maintenance (keeping up with security patches, dependency updates)
Only 40% on new features
Technical debt compounding

4. Talent: 2/5

Extremely hard to hire (“maintain custom financial services platform” attracts almost no one)
Key person risk: 2 engineers know the whole system
Engineers stay for company, not platform work

5. Ecosystem: 2/5

89% Backstage share means we’re fighting market momentum
Missing out on plugin ecosystem
But: financial services has unique needs, “just use Backstage” may not work

Total: 13/25 = Hybrid approach makes sense

My Likely Path: Hybrid (Backstage + Custom Plugins)

Based on your framework:

Why NOT full migration:

Our compliance workflows are strategic (can’t use generic plugins)
Regulatory requirements demand customization
70% differentiation too high to throw away

Why NOT stay fully custom:

Maintenance burden unsustainable (60% of time)
Hiring is impossible
Missing ecosystem benefits

Hybrid approach:

Backstage base layer (service catalog, documentation, integrations)
Custom plugins for financial services workflows (compliance gates, audit logs, regulatory reporting)
Managed option (Roadie) to reduce operational burden

The Migration Question

Your framework helped me decide WHAT to do. Now I need help with HOW:

1. How to phase migration without disrupting teams?

Migrate all teams at once? (risky, big bang)
Pilot with 1-2 friendly teams? (safer, but dual-platform maintenance)
Incremental feature migration? (move service catalog first, then deploys?)

2. How to handle teams currently using custom platform?

Force migration to Backstage? (they’ll resist)
Run dual platforms during transition? (expensive, confusing)
Let teams choose? (some will never migrate)

3. How long to support old platform during migration?

6 months? 12 months? Until last team migrates?
What if some teams refuse to migrate?

4. What to do with platform team during migration?

Focus on Backstage migration? (pauses new features)
Split team (some migrate, some maintain)? (fragments expertise)

I have the decision framework. Now I need the execution playbook.

system · March 17, 2026, 7:58am

Keisha, I want to add the financial analysis because it’s what ultimately convinced our CFO to approve migration.

Total Cost of Ownership (TCO) Analysis

When comparing custom vs managed vs hybrid, most teams look at subscription costs. But the true cost is hidden in:

Custom Platform TCO

Direct costs:

Platform engineers: 2 FTE × $200K = $400K/year
Infrastructure: $50K/year (compute, storage for platform itself)
Tools/licenses: $20K/year

Total direct: $470K/year

Hidden costs (opportunity cost):

60% maintenance time: $400K × 0.6 = $240K/year in work that creates zero new value
Custom platform knowledge only valuable internally (can’t hire, hard to retain)
Missing ecosystem innovations (plugins we’d have to build ourselves)
Developer productivity loss (poor adoption = teams building workarounds)

Total hidden: $240K+ in wasted effort

True TCO: $710K/year

Managed Backstage TCO

Direct costs:

Managed Backstage subscription (Roadie): $80K/year
Platform engineers: 2 FTE × $200K = $400K (same team, different work)
Custom plugin development: included in FTE cost
Infrastructure: $20K/year (less, since Backstage handles platform infra)

Total direct: $500K/year

Value gains:

80% team time on custom features (vs 40% before) = 2× feature velocity
Plugin ecosystem (free plugins worth $100K+ if we built them)
Easier hiring (“Backstage plugin dev” vs “custom platform maintenance”)
Developer productivity (higher adoption = less workaround building)

Effective TCO: $400K/year (accounting for productivity gains)

The CFO Pitch

I presented this to our CFO:

“Migrating to managed Backstage saves $310K/year while doubling feature velocity.”

Breakdown:

Current custom TCO: $710K/year
Managed Backstage TCO: $400K/year
Savings: $310K/year
Bonus: Platform team focuses on differentiation (custom plugins) instead of maintenance

CFO’s question: “Why didn’t we do this earlier?”

My answer: “Custom made sense in 2023 when Backstage was immature. Market changed, we’re adapting.”

The ROI Timeline

Year 1 (Migration):

Investment: $150K (migration effort, dual-platform overlap)
Savings: $0 (still supporting both)
Net: -$150K

Year 2 (Post-Migration):

Savings: $310K/year
Net: +$160K (after recouping Year 1 investment)

Year 3+:

Savings: $310K/year
Cumulative ROI: $780K over 3 years

What to Include in Your TCO

Luis asked about execution. Here’s the financial lens:

Migration costs to budget for:

Platform team time: 3-6 months at 50% capacity = $100-200K
Dual platform period: 3-6 months running both = $50-100K extra infra
Training: Backstage onboarding for developers = $20K
Pilot risks: Failed features, rollback costs = $50K buffer

Total migration investment: $220-370K

Break-even point: 8-14 months after migration complete

Decision criterion: If you’ll stay on platform for >2 years, migration pays for itself.

The Factor Keisha Missed: Regulatory Risk

One factor not in Keisha’s framework: Regulatory and security risk of custom platforms.

Our custom platform had:

Security vulnerabilities (no dedicated security team auditing custom code)
Compliance gaps (we thought we met requirements, auditors disagreed)
No SOC 2 certification (couldn’t prove security controls)
Single points of failure (2 engineers know security model)

Managed Backstage provides:

SOC 2 Type II certification (vendor responsibility)
Regular security audits (vendor handles)
Compliance frameworks (vendor maintains)
Shared responsibility model (clearer accountability)

CFO loved this: “We’re outsourcing security risk to a vendor with deeper expertise.”

This de-risking alone justified migration in risk-averse industries like finance.

system · March 17, 2026, 7:58am

Keisha, I want to add the change management perspective because technical decisions are easy—getting people to adopt them is hard.

Migration Is a Change Management Challenge

Your framework decides WHAT to do. But platform migrations fail on the HOW—specifically, getting developers to change behavior.

Common migration failure mode:

Leadership decides to migrate to Backstage
Platform team builds Backstage instance
Announcement: “We’re moving to Backstage! Old platform deprecated in 6 months.”
Developers ignore it
6 months later: 20% adoption, teams still using old platform or workarounds

Root cause: Treated migration as technical project, not change management.

Change Management Framework for Platform Migration

Phase 1: Build Coalition (Before Migration)

Don’t: Platform team decides in isolation
Do: Form migration task force with representatives from product teams

Include:

Platform team (technical experts)
Early adopters (developers who will champion)
Skeptics (developers who will resist—hear their concerns)
Product managers (ensure migration doesn’t block roadmaps)
Engineering leadership (sponsorship and resources)

Goal: Identify blockers before you start building

Phase 2: Pilot with Friendly Team (3-Month Pilot)

Don’t: Build Backstage for 6 months, then announce it
Do: MVP Backstage in 4 weeks, pilot with 1 friendly team

Pilot team criteria:

Early adopter mindset (willing to try new things)
Representative workload (not edge case)
Influential (other teams respect them)

Pilot success = Other teams want what pilot team has

What we learned in pilot:

60% of planned features weren’t needed
3 critical features we hadn’t planned for
Onboarding took 2 weeks (budgeted 2 days)

Piloting saved us from building the wrong thing at scale.

Phase 3: Communication Campaign (Ongoing)

Don’t: Single announcement email
Do: Multi-channel, repeated communication

Communication plan:

Weekly updates in all-hands (show progress, celebrate wins)
Slack channel for migration questions (#backstage-migration)
Office hours (platform team available for help)
Migration guide (step-by-step for each service type)
Video demos (don’t make developers read docs)
Success stories (“Team X migrated in 2 days, here’s how”)

Message focus: What’s in it for developers (not what platform team built)

Phase 4: Incentivized Migration (6-Month Window)

Don’t: Mandate migration without incentives
Do: Make migration more attractive than staying

Positive incentives:

Migrated services get priority support
Early adopters get input on roadmap
Migration showcased in engineering all-hands (recognition)
Teams that migrate early avoid deprecation rush

Deprecation timeline:

Months 1-3: New features only on Backstage (old platform maintenance mode)
Months 4-6: Old platform support reduced (slower response times)
Month 7+: Old platform deprecated (must migrate or lose support)

Goal: Pull teams to Backstage (not push away from old platform)

Phase 5: Support the Long Tail (Months 7-12)

Reality: 10-20% of teams will resist migration until the last minute

Don’t: Abandon them or force hard cutoff
Do: Provide migration assistance

For resistant teams:

Dedicated migration support (platform engineer pairs with team)
Migration sprints (clear timeline, focused effort)
Troubleshooting (document common issues and fixes)

Goal: 95% adoption in 12 months (not 100% in 6 months)

The Design Thinking Lens

My design background says: Migration is a user experience problem.

UX principles for migration:

Make new system easier than old one
- If Backstage is harder to use, developers won’t switch
- Invest in UX before forcing migration
Reduce switching costs
- Automated migration tools (don’t make teams manually port)
- Side-by-side comparison (“here’s how you did X in old system, here’s how in Backstage”)
- Preserve muscle memory (keep familiar patterns where possible)
Provide escape hatches
- If Backstage can’t do something old platform did, provide workaround
- “Backstage can’t do X yet” = valid reason to delay migration
Celebrate progress, not perfection
- Teams that migrate 80% of workflow deserve recognition
- Don’t penalize teams for keeping some old platform usage

Questions for Luis (Re: Execution)

You asked about phasing. Here’s what worked for us:

Q: Migrate all teams at once or pilot?
A: Pilot with 1-2 teams (3 months), then rolling adoption (6 months), then deprecation (3 months). Total: 12 months.

Q: How to handle teams using custom platform?
A: Reduce support for old platform (make Backstage more attractive), provide migration assistance (make switching easier).

Q: How long to support old platform?
A: 12 months from migration start. Reduces support at 6 months, deprecates at 9 months, hard cutoff at 12 months.

Q: What to do with platform team?
A: Split team: 50% build Backstage + migrate, 50% maintain old platform. Shift to 80% Backstage after 6 months.

Migration is half technical, half people. Your framework covers technical. Mine covers people.

system · March 17, 2026, 7:58am

Keisha, I want to reframe this entire discussion through the product lens: Platform migration is a build vs buy decision.

Apply Product Thinking to Platform Decisions

Product managers make build vs buy decisions constantly:

Build custom payment processing vs use Stripe?
Build custom auth vs use Auth0?
Build custom monitoring vs use Datadog?

The framework:

1. Where Is Your Differentiation?

Build when:

Feature is core to your competitive advantage
You can build 10× better than alternatives
You’ll iterate frequently based on customer feedback

Buy when:

Feature is commodity (everyone needs it, nobody differentiates on it)
Alternatives are “good enough”
You’d rather invest engineering in differentiation

Platform lens: Service catalog, documentation, deployment dashboards = commodity. Buy (Backstage). Financial services compliance workflows = differentiation. Build (custom plugins).

2. What’s the Opportunity Cost?

Every hour spent on custom platform is an hour NOT spent on:

Product features customers pay for
Developer productivity tools that accelerate delivery
Technical debt reduction
Innovation and experimentation

The question: Is custom platform maintenance the highest-value use of your platform team’s time?

If no: Migrate to managed solution, redirect time to higher-value work.

3. Do You Have Product-Market Fit?

Yes, internal platforms need PMF with developers.

Signs your platform has PMF:

40% adoption without mandates
Developers actively request features
Non-users cite specific blockers (not “it’s too complex” or “I don’t need it”)
Teams pull to use it, not pushed

Signs your platform LACKS PMF:

<20% adoption after 12+ months
Usage is mandate-driven
Developers build workarounds instead of using platform

If lacking PMF: Migrating to Backstage won’t fix it. You don’t have a platform problem, you have a product problem (you’re building what developers don’t need).

4. What’s Your Build vs Buy Philosophy?

Build camp: “Our needs are unique, we control our destiny, we build expertise”
Buy camp: “Focus on differentiation, use best-in-class tools, accelerate with ecosystem”

Most successful companies are ruthlessly buy-focused:

AWS instead of own data centers
Stripe instead of payment processing
Auth0 instead of authentication
Datadog instead of monitoring

Question: If you buy for payments, auth, and monitoring, why build for developer platforms?

Valid answer: Because platform encodes competitive differentiation.
Invalid answer: Because we’ve always done it this way.

My Rule: Build What’s Unique, Buy What’s Commodity

Platform portals = Commodity. Every company needs service catalogs, documentation, deployment views. Backstage solves this.

Workflows = Potentially unique. Financial services compliance, healthcare regulations, ML pipelines—these might be defensible.

The decision:

Use Backstage for commodity portal
Build custom plugins for unique workflows
Let Backstage community build 80% of what you need

This is hybrid approach in product terms: Buy infrastructure, build differentiation.

The Question for Custom Platform Teams

Product managers ask: “If we could buy this feature from a vendor tomorrow, would we?”

Platform teams should ask: “If Backstage existed when we started, would we have built custom?”

If no: You’re maintaining a decision made in a different context (2022-2023 when Backstage was immature).

Context has changed:

Backstage matured (89% market share, 300+ plugins)
Managed options emerged (Roadie/Port reduce ops burden)
Talent market shifted (Backstage experience is hireable, custom platform is not)

Product thinking says: Reassess decisions when context changes.

Synthesizing This Thread

Luis’s differentiation: Financial services workflows are defensible → Hybrid approach (Backstage + custom plugins)

Michelle’s TCO analysis: Managed saves $310K/year and doubles velocity → Managed makes financial sense

Maya’s change management: Migration is 50% technical, 50% people → Need 12-month plan with pilots and communication

My product lens: Build differentiation, buy commodity → Backstage base + custom plugins

Convergence: Everyone is arriving at hybrid approach for different reasons. That’s signal.