Moving from Self-Hosted to Managed Backstage: A 4-Week Migration Playbook

vp_eng_keisha · March 23, 2026, 8:22am

After all the strategic discussion about DIY vs managed and future predictions, I want to share something immediately actionable: our actual 4-week migration playbook.

This is for teams who’ve decided to migrate from self-hosted to managed Backstage and need a concrete execution plan.

Context: What We Had

Our starting point (December 2025):

Self-hosted Backstage running for 18 months
23 custom plugins (varying quality and usage)
15% voluntary adoption among 80 engineers
5 engineers spending 30-50% time on maintenance
Integrations: GitHub, AWS, Datadog, PagerDuty, Okta

Our goal: Migrate to managed platform without disrupting developer workflows

Week 1: Audit Current State

Goal: Understand what you actually have before migrating

Day 1-2: Catalog Everything

Custom plugins:

List all 23 plugins
Document what each does
Measure actual usage (analytics or logs)
Surprising finding: 15 plugins had <10% usage

Critical integrations:

GitHub (source control)
AWS (infrastructure)
Datadog (observability)
PagerDuty (on-call)
Okta (SSO/auth)

Current metrics:

Adoption rate: 15%
Active users: 12 of 80 engineers
Most-used features: Service catalog, documentation
Least-used: Custom dashboards, homegrown plugins

Day 3-4: Developer Survey & Interviews

Survey questions (sent to all 80 engineers):

Do you currently use the internal developer platform? (Yes/No/Sometimes)
If yes, which features do you use? (Checkboxes)
If no, why not? (Free text)
What would make you use it more? (Free text)
On a scale 1-10, how satisfied are you with current platform?

Key insights from 45 responses:

“Too slow” (28 mentions)
“Confusing to find things” (19 mentions)
“Often broken or buggy” (17 mentions)
“Documentation outdated” (14 mentions)
“Doesn’t help with my actual workflow” (12 mentions)

Interviews with 10 developers (mix of users and non-users):

Non-users: “I tried it once, it was slow, never went back”
Light users: “I check service catalog sometimes, but that’s it”
Heavy users: “I want to love it, but too many bugs and it’s always breaking”

Day 5: Document Success Criteria

Define what success looks like:

60% voluntary adoption within 3 months
<5 second page load times
<1 outage per quarter
4 engineers freed to work on Golden Paths
Developer NPS score >40

Key decision: We need metrics dashboard to track this

Week 2: Vendor Evaluation & Trial

Goal: Choose the right managed platform for your needs

Day 1-2: Vendor Research

Evaluated options:

Roadie: Managed Backstage, enterprise focus, proven EdTech customers
Spotify Portal: Official Spotify offering, GA since Oct 2025
Others: Cortex, Port (different approaches, not Backstage-based)

Evaluation criteria:

Integration support (do our critical integrations work?)
Custom plugin support (can we migrate our 8 critical plugins?)
Enterprise features (SSO, audit logs, SLAs)
Pricing (transparent, predictable)
Support quality (24/7, SLAs, dedicated account team)
Customer references (talk to similar companies)

Day 3-4: Trial Setup with 10-Person Pilot

Selected 10 developers:

3 current platform power users
4 occasional users
3 non-users
Mix of teams and seniority levels

Trial goals:

Test critical integrations
Migrate 2 sample plugins
Get feedback on UX
Measure performance
Identify migration blockers

Trial results (Roadie):

All integrations worked out of box
Custom plugin migration path clear
Page loads <2 seconds (vs 8-15 seconds self-hosted)
Pilot developers said “this is way better”
One plugin needed rework (API changes)

Day 5: Decision & Contract

Decision: Roadie

Integration support best for our stack
Enterprise features met compliance needs
Customer references were very positive
Pricing: $150K/year (vs $1M TCO for self-hosting)

Signed contract with:

3-year commitment (20% discount)
Dedicated account manager
24/7 support
Custom plugin migration assistance
Quarterly business reviews

Week 3: Migration Execution

Goal: Move everything to managed platform without breaking workflows

Day 1: Export Data

What we exported:

Service catalog metadata (YAML files)
Documentation (Markdown)
User configurations
Integration configs (can regenerate)
Custom plugin code

Tools used:

Backstage CLI for catalog export
GitHub for code backup
S3 for data backup

Time: 4 hours

Day 2: Reconnect Integrations

Roadie advantage: Most integrations had pre-built connectors

Setup time:

GitHub: 15 minutes (OAuth app)
AWS: 30 minutes (IAM roles)
Datadog: 10 minutes (API key)
PagerDuty: 15 minutes (API token)
Okta SSO: 45 minutes (SAML configuration)

Total: 2 hours vs. days we spent initially

Day 3-4: Migrate Custom Plugins

8 critical plugins (abandoned the 15 with low usage):

Compliance dashboard: Migrated as-is (3 hours)
Deployment approval workflow: Migrated with minor changes (4 hours)
Cost tracking integration: Replaced by Roadie’s cost plugin (0 hours - better!)
On-call schedule widget: Migrated as-is (2 hours)
Service ownership directory: Replaced by native Backstage catalog (0 hours)
Custom docs template: Migrated (2 hours)
API gateway integration: Reworked for new API (6 hours)
Security scan results: Migrated (3 hours)

Total plugin migration: 20 hours over 2 days

Surprise: 3 of our “critical” plugins were better handled by Roadie’s built-in features

Day 5: Parallel Running & Testing

Setup:

Old self-hosted: still running
New managed: fully configured
Internal DNS: both accessible

Testing with 20 developers (pilot expanded):

Verify integrations work
Test custom plugins
Load test with realistic usage
Collect feedback

Issues found:

One plugin API endpoint misconfigured (fixed in 30 min)
Two users confused by slightly different navigation (documented)
Performance excellent (avg page load 1.8 seconds)

Week 4: Adoption Campaign & Cutover

Goal: Get developers to actually use the new platform

Day 1: All-Hands Demo

30-minute session:

Why we’re migrating (UX, reliability, free up engineers for Golden Paths)
Live demo of new platform
Performance comparison (side-by-side with old)
Q&A

Attendance: 68 of 80 engineers

Reception: Positive - “Wow, it’s actually fast now”

Day 2-3: Team-by-Team Onboarding

Scheduled 1-hour sessions with each team (8 teams):

Personalized demo of features relevant to their workflow
Hands-on: “Try deploying your service”
Answer questions
Collect feedback

Key tactic: Show them the Golden Paths we’d built on top (which were always there but no one used because platform was too slow)

Day 4: “Golden Path of the Week” Showcase

Launched weekly demo series:

Week 1: “Deploy to production in 3 clicks”
Week 2: “Automated compliance checks”
Week 3: “On-call scheduling made easy”
Week 4: “Finding service owners in 10 seconds”

Format:

15-minute Zoom recording
Posted in Slack
Written tutorial in docs

Engagement: 40+ developers watched first week

Day 5: Cutover & Decommission

Friday afternoon cutover:

DNS switched to new platform
Old platform set to read-only
Communication: “New platform is now primary”
Rollback plan ready (switch DNS back if issues)

Weekend monitoring: Zero issues

Monday: Old platform decommissioned

The Results (3 Months Post-Migration)

Adoption Metrics

Before (self-hosted):

Voluntary adoption: 15%
Active weekly users: 12
Page load time: 8-15 seconds
Outages: 2-3 per month

After (managed):

Voluntary adoption: 60% (and climbing)
Active weekly users: 48
Page load time: <2 seconds
Outages: 0

Engineering Impact

Engineers freed: 4 engineers now working on Golden Paths (from 5 on maintenance)

New Golden Paths built (in 3 months freed capacity):

Automated testing framework
Zero-downtime deployment pattern
Compliance-as-code templates

Team satisfaction: +38% on internal survey

Developer Feedback

Quotes from survey:

“Finally feels like a real product, not a side project”
“I can actually find what I need now”
“The onboarding docs are so much better”
“Love that it just works - I don’t think about the platform anymore”

Net Promoter Score: +42 (up from -15)

Key Lessons Learned

Lesson 1: User research before migration

The developer survey revealed that speed and reliability mattered way more than features. This insight shaped our entire migration approach.

Lesson 2: Don’t migrate everything

15 of 23 plugins had <10% usage. We only migrated the 8 that developers actually used. This saved enormous time and reduced complexity.

Lesson 3: Communication > technical execution

The migration itself was smooth. The hard part was getting developers to try the new platform. Treating it like a product launch (demos, onboarding, showcases) made the difference.

Lesson 4: Managed platforms often have better solutions

3 of our “critical” plugins were replaced by better built-in features. Don’t assume your custom solution is better than what vendors provide.

Lesson 5: Measure everything

We instrumented adoption, performance, satisfaction. This data proved the migration was successful and justified the investment.

Common Questions

Q: What about plugins that can’t migrate?
A: API integration is usually an option. Or question if you really need it (remember our 15 low-usage plugins).

Q: How do you handle compliance/security concerns?
A: Enterprise managed platforms (Roadie, Spotify Portal) have SOC2, often better security than you can build.

Q: What if the managed platform doesn’t have a feature?
A: Ask yourself: Is this truly critical, or just nice-to-have? Can you use their API to build it?

Q: How do you convince leadership?
A: ROI in business terms. Our case: Save $850K/year, free 4 engineers for innovation, improve developer experience.

Next Steps for Teams Considering This

Week 1 audit: Do this even if you’re not sure about migrating. Understanding current state is valuable regardless.
Pilot trial: Most vendors offer free trials. Test with 10 developers before committing.
Build business case: Use Michelle’s framework. Calculate TCO vs managed cost + opportunity cost.
Plan adoption campaign: Technical migration is table stakes. Adoption requires product launch approach.

Happy to answer questions about any part of this playbook!

eng_director_luis · March 23, 2026, 8:24am

Keisha, this is pure gold. I’m literally printing this out for our platform team planning meeting next week.

The Questions I’ve Been Asking

Your playbook answers so many questions I had from your earlier post. Let me dig into a few specifics:

Custom Plugin Migration

You mentioned 8 critical plugins took 20 hours total to migrate. That’s way faster than I expected.

Specific question: The “Compliance dashboard” that migrated as-is in 3 hours - did Roadie provide tooling/support for this, or was it straightforward because Backstage plugin architecture is consistent?

Context for my situation: We have 6 custom plugins for financial services compliance reporting. These are THE reason we’ve been hesitant to move to managed (fear of vendor lock-in, customization limitations).

Your experience suggests these might be easier to migrate than we think.

The Integration Timeline

Day 2: Reconnect integrations - total 2 hours

This is shocking to me. We spent WEEKS on integrations when we built our self-hosted platform.

Question: Did Roadie’s pre-built connectors “just work,” or did you hit issues with:

Firewall rules / VPN access
IAM permissions / security policies
Data residency requirements
Audit logging requirements

Financial services context: We have very strict requirements around:

All API calls must be logged with retention
Data must stay in US regions only
Multi-factor auth for sensitive operations
SOC2, PCI-DSS compliance

Did managed platform handle these, or did you need to configure/customize?

The Adoption Campaign Deep Dive

“Golden Path of the Week” showcase is brilliant. Can you share more details?

Specifically:

Who created the content? (Platform team, or developers using the paths?)
What format worked best? (Video, written tutorial, both?)
How did you promote it? (Slack, email, all-hands?)
What was engagement like? (Views, completion rate, questions?)

I want to steal this approach. We have Golden Paths that developers don’t know exist because our current platform is so painful they never explore.

Building the Business Case

You mentioned: “Save $850K/year, free 4 engineers for innovation”

Can you break down that $850K?

Salary savings from maintenance reduction?
Opportunity cost of features not built?
Infrastructure cost difference?
Something else?

Why I’m asking: I need to build our business case, and concrete numbers from a real migration are more credible than hypothetical estimates.

What I’m Taking to Leadership

Based on your playbook:

Week 1 audit: Doing this immediately (even before getting approval to migrate)

Survey our developers (steal your questions)
Measure actual plugin usage (I bet we have low-usage plugins too)
Document current metrics (adoption, performance, satisfaction)

Pilot approach: Request budget for 30-day Roadie trial

10-person pilot with mix of users/non-users
Test our 6 compliance plugins
Measure performance vs current
Build data-driven business case

Migration estimate: If we proceed, I can now estimate 4-6 weeks based on your timeline (we have more integrations but similar scope)

One More Question

Change management with platform team: You had 5 engineers maintaining the platform. How did they react to the decision to move to managed?

Were they:

Relieved (no more maintenance burden)?
Resistant (worried about job security)?
Excited (can work on Golden Paths)?
Mixed?

And how did you handle the transition? Did all 5 move to Golden Path work, or did some move to different teams?

Context: I want to navigate this sensitively with our team. These are smart engineers who’ve invested time in the self-hosted platform.

Thank you for sharing so transparently. This playbook is exactly what teams need when making this decision.

cto_michelle · March 23, 2026, 8:24am

Keisha, this playbook is executive-ready. I’m sharing it with our board as an example of how to execute technical migrations with business discipline.

The Executive Perspective

What makes this playbook excellent from a CTO/exec perspective:

1. Clear Success Criteria (Week 1, Day 5)

You defined success metrics BEFORE starting:

60% adoption in 3 months
<5 second load times
<1 outage per quarter
4 engineers freed
Developer NPS >40

Why this matters: Most technical projects don’t define success upfront. Then they can’t prove they succeeded.

Question for you: Did you present these criteria to executive leadership before getting migration approval? Or define them for your own tracking?

2. ROI in Business Terms

Your results section translates technical wins to business value:

“4 engineers freed to work on Golden Paths”
“60% adoption vs 15%” (4x improvement)
“Zero outages vs 2-3 per month”
“Developer NPS +42 vs -15” (57 point swing)

Board conversation: “We spent $150K to free $800K in engineering capacity and 4x adoption. ROI is clear.”

3. Risk Mitigation

You had rollback plan (Day 5, Week 4):

DNS switch (easy to revert)
Old platform kept in read-only
Weekend monitoring
Clear communication

Why this matters: Boards worry about risk. Showing you planned for failure builds confidence.

The Change Management Excellence

Week 4: Adoption Campaign is textbook change management:

All-hands demo: Build awareness (68 of 80 attended - excellent!)
Team onboarding: Hands-on, personalized to each team’s needs
Weekly showcases: Ongoing engagement and education
Feedback loops: Continuous iteration

This isn’t IT project management. This is organizational change management.

Question: Did you have a dedicated person/team running adoption campaign, or did platform engineers do it?

Context: I’m thinking about whether platform teams need a “Developer Relations” or “Internal Product Marketing” role.

The Communication Framework

Your framing in the all-hands demo is perfect:

“Free up engineers for Golden Paths” (positive, strategic)
vs.
“Self-hosted platform is failing” (negative, blame)

“Performance comparison: 1.8s vs 8-15s” (concrete, measurable)
vs.
“New platform is better” (vague, unsubstantiated)

Leadership lesson: Frame changes in terms of gains (what we’ll enable) not losses (what failed).

Questions for You

Q1: Executive Sponsorship

Who sponsored this migration at exec level? VP Eng, CTO, CEO?

Why I’m asking: Major migrations need exec sponsorship. Curious how you secured it and what level of visibility this had.

Q2: Budget Approval

How did you get budget approved?

Specific questions:

Did you present business case with ROI projections?
What metrics were most persuasive to leadership?
Did you need board approval for 3-year contract?
How did you handle “but we already invested in self-hosted” sunk cost objection?

Q3: Measuring Long-Term Success

It’s been 3 months. What metrics are you tracking at 6 months, 12 months?

My hypothesis:

6 months: Adoption should be 70%+, Golden Paths built should show usage
12 months: ROI proven (freed engineers built X features driving Y revenue)

Am I thinking about this right?

What I’m Stealing

Week 1 audit approach: The developer survey questions are excellent. I’m using this for our observability platform evaluation.
Pilot with mixed users: 3 power users, 4 occasional, 3 non-users. Smart way to get diverse feedback.
Golden Path of the Week: This is marketing/engagement excellence. Could apply to any internal platform.
Success metrics dashboard: Tracking adoption, performance, satisfaction in real-time.

The Broader Lesson

This playbook shows that technical migrations are 30% technical, 70% people/process.

Week 1-2: Research and planning
Week 3: Technical migration (went smoothly!)
Week 4: Change management and adoption (the hard part)

Most engineering teams over-invest in technical execution and under-invest in adoption. Your approach gets the balance right.

Thank you for documenting this so thoroughly. This should be the standard playbook for managed platform migrations.

product_david · March 23, 2026, 8:24am

This is a masterclass in treating internal platforms as products. Let me break down the product management excellence in this playbook.

Product Discovery (Week 1)

What you did:

User surveys (45 of 80 responses - good response rate!)
User interviews (10 developers, mixed usage patterns)
Usage analytics (plugin usage, adoption metrics)
Pain point identification (“too slow” = top complaint)

Product lens: This is textbook product discovery. You did user research BEFORE migrating, not after.

The insight: Developers wanted speed and reliability, not more features.

Most platform teams would have migrated features 1:1. You focused on the user problems (speed, reliability) instead.

Feature Prioritization (Week 2-3)

The ruthless prioritization:

23 plugins → only migrate 8
Abandoned 15 with <10% usage
Replaced 3 “critical” plugins with better built-in features

Product framework this maps to:

RICE scoring (Reach, Impact, Confidence, Effort)
High usage + high impact = migrate
Low usage = abandon (even if someone thinks it’s critical)

My favorite part: “3 of our ‘critical’ plugins were better handled by Roadie’s built-in features”

This is the “not invented here” syndrome being overcome by data. Love it.

Product Launch (Week 4)

Launch tactics you used:

Announcement (All-hands demo)
- 68 of 80 attendance = 85% reach
- Live demo = product marketing
- Q&A = address objections
Onboarding (Team-by-team sessions)
- Personalized to each team’s workflow
- Hands-on trial (“Try deploying your service”)
- This is customer success approach
Engagement (Golden Path of the Week)
- Weekly feature showcases
- 15-minute format (respects time)
- Multi-channel (Zoom recording + Slack + docs)
- 40+ developers engaged in Week 1
Feedback loops (Continuous iteration)
- Collect feedback during onboarding
- Monitor metrics
- Iterate based on usage

This is how you launch external products. Most internal platforms just announce in Slack and wonder why adoption is low.

Metrics & Measurement

Leading indicators (predict success):

Trial rate: Did developers try it?
Activation: Did they complete first workflow?
Engagement: Are they coming back?

Lagging indicators (measure success):

Adoption: 15% → 60% (4x growth)
NPS: -15 → +42 (57 point swing)
Performance: 8-15s → <2s (8x improvement)

Product insight: You measured the full funnel, not just final adoption.

Questions About the Product Approach

Q1: User Research Methodology

Your developer survey had 45 of 80 responses (56% response rate). That’s excellent for internal surveys.

How did you achieve this?

Incentives? (Amazon gift cards, etc.)
Executive pressure? (“Please fill this out”)
Good timing? (sent when?)
Survey length? (how many questions?)

I want to replicate this response rate for our internal tool surveys.

Q2: “Golden Path of the Week” Deep Dive

This is brilliant product engagement. More details:

Content creation:

Who created these? (Platform team, or developer advocates?)
How much effort per week? (production time)
Quality bar? (polished or scrappy?)

Distribution:

Posted where? (Slack channel, email, internal wiki?)
How did you drive attendance/views?
Did engagement drop over time?

Measurement:

View count?
Completion rate? (watched full video)
Adoption of specific Golden Path after showcase?

Iteration:

What worked best? (video vs tutorial vs live demo)
What didn’t work? (abandoned formats)

Q3: Adoption Curve

60% adoption in 3 months is excellent. What did the curve look like?

Week 1: X% (launch bump?)
Month 1: Y%
Month 2: Z%
Month 3: 60%

Product question: Was it linear growth, or did you have specific inflection points? (e.g., after certain team onboarded, others followed)

The Product-Market Fit Signal

Your metrics show clear product-market fit:

Before (no PMF):

15% adoption (most developers not using)
NPS -15 (detractors outnumber promoters)
Developers finding workarounds

After (strong PMF):

60% adoption (majority choosing platform)
NPS +42 (promoters outnumber detractors)
“I don’t think about the platform anymore” (friction removed)

The transition: Same category (developer platform), different execution (managed vs self-hosted), achieved PMF.

What This Teaches About Internal Products

Internal platforms should be managed like external products:

Discovery: User research, not assumptions
Prioritization: Data-driven feature decisions
Launch: Product marketing, not just announcement
Measurement: Full funnel metrics
Iteration: Continuous improvement based on feedback

Your playbook proves this approach works for internal tools.

One Last Question

If you could go back to Week 0 (before migration decision), what would you do differently?

My guess: Start with the user research (Week 1 audit) 12 months earlier, which would have revealed the problems sooner.

But curious what you think.

Thanks for this playbook - I’m sharing it with every product team that works on internal tools.

maya_builds · March 23, 2026, 8:25am

As a designer who obsesses about UX, I want to talk about something buried in your metrics but super important: How did you track where developers got stuck during onboarding?

The UX Question That Matters

Your results show:

60% adoption (vs 15%)
NPS +42 (vs -15)
“I don’t think about the platform anymore”

That last quote is the UX holy grail. The best experiences disappear - you accomplish your goal without thinking about the tool.

But to get there, you need to understand friction points.

Onboarding UX Deep Dive

Week 4, Day 2-3: Team-by-team onboarding

You mentioned “hands-on: Try deploying your service”

UX questions:

Where did developers get stuck? (First login? Finding their service? Understanding deployment flow?)
What questions came up repeatedly? (Indicates documentation or UX gaps)
How long did “first successful deployment” take? (Time to value metric)
Did you observe them or just guide them? (User research observation vs tutorial)

Why this matters: These friction points are where you lose adoption. Understanding them helps you:

Improve onboarding docs
Add contextual help
Redesign confusing flows
Prioritize UX improvements

The Documentation Question

You mentioned: “The documentation is so much better” as developer feedback.

Specific questions:

What made Roadie’s docs better?
- Better information architecture?
- More code examples?
- Search that actually works?
- Videos/screenshots/visuals?
- Contextual help in the UI?
Did you supplement their docs with internal content?
- Team-specific guides?
- Internal workflows?
- FAQs based on your onboarding sessions?

Designer POV: Documentation is UX, not an afterthought. Sounds like Roadie gets this.

The Design System Advantage

Your note: “3 of our ‘critical’ plugins were better handled by Roadie’s built-in features”

I bet part of “better” was design quality, not just functionality.

My hypothesis:

Self-hosted plugins: Functional but inconsistent design (different UI patterns, styling)
Roadie built-ins: Cohesive design system, polished UX, accessible

Question: Did your developers notice design quality difference, or was it purely about functionality/reliability?

Why I’m curious: Design systems are my world, and I see this pattern constantly - built-in solutions from mature products have better design because they have dedicated designers.

The “Golden Path of the Week” Format

My suggestions (as someone who’s designed onboarding experiences):

Video format:

Keep it short (15 min is good, 10 even better)
Show, don’t tell (screen recordings > slides)
Include captions (accessibility + can watch muted)

Written tutorial:

Step-by-step with screenshots
Copy-pastable code examples
Estimated time (“5 min tutorial”)
Link to video for visual learners

Interactive demo (if possible):

Let developers try in sandbox
Guided tour with tooltips
Can’t break anything, safe to explore

Did you try interactive demos, or stick with video + written?

The Feedback Loop Design

Week 4 mentions feedback loops but doesn’t detail how you collected feedback.

UX researcher questions:

How did you collect feedback?
- Survey after each onboarding?
- Slack channel for questions?
- Office hours?
- Usage analytics?
What did you do with it?
- How fast did you iterate?
- Who prioritized feedback?
- How did you communicate changes?

Best practice: Close the loop - tell developers “We heard you wanted X, we built it”

My Offer

I’d love to help teams design adoption campaigns for platform migrations.

Specifically:

Onboarding flow design
Documentation IA and templates
“Golden Path” content format
Feedback collection mechanisms
Visual design for internal tools (yes, they deserve it!)

Why this matters: Your results show adoption jumped 4x. UX was part of that (speed + reliability + discoverability + docs).

Too many platform teams think “it works” is enough. Your playbook shows that “it’s delightful” drives adoption.

One Question

Did Roadie’s design system and UX patterns require any adjustment from your developers?

Like, were they:

Immediately familiar? (“This looks like GitHub/AWS console”)
Needed learning? (“Different from our old platform”)
Confusing at first? (“Where’s the button I used to click?”)

Curious about change management for UI changes, not just platform changes.

Thanks for this incredible playbook. The UX details are what take it from good to great.