Migrating From No Portal to Backstage in 2026

The Phase-by-Phase Breakdown

Phase one (1 to 2 months) is selection and deployment. Vendor evaluation if going managed (Roadie, Coderpath, or similar). Self-hosted deployment work if going self-hosted: Kubernetes cluster, Postgres database, TechDocs object storage, CDN, monitoring and alerting setup. Identity provider integration regardless of path (SAML or OIDC against your SSO provider). The deployment work for self-hosted typically takes 4 to 6 weeks; on managed it takes 1 to 2 weeks because the runtime is provided.

Phase two (2 to 3 months) is catalogue and golden-path work. Catalogue bootstrap covers identifying services, mapping owners, populating dependency relationships, integrating with source-code repositories so the catalogue stays current automatically. First golden-path templates cover the most common service-provisioning shape in your organisation (typically the microservice-with-CI-and-observability pattern). First plugin set covers identity provider, source code, CI, observability, and incident management integrations. This phase is where most of the platform-team work happens.

Phase three (2 to 4 months) is pilot team adoption. Three to five teams onboard to the portal first, with active platform-team support: office hours, internal documentation, sample-PR walkthroughs, feedback iteration. The pilot phase produces real adoption signal: which features get used, which do not, what additional work the broader rollout will need. Pilot teams often surface unanticipated requirements that change the rest of the rollout plan.

Phase four (2 to 3 months) is broader rollout. The remaining engineering teams onboard with lighter platform-team support based on the pilot-phase materials. Ownership data cleanup happens here (the catalogue inevitably contains errors that get surfaced as more teams use it). Scorecards may be introduced here if part of the plan. The phase ends when the portal is the default tool for the workflows it was designed to support, not just an option engineers can take or leave.

The Adoption-Work Investment

The most consistent migration mistake is over-investing in technical implementation and under-investing in adoption work. The failure mode: the platform team builds an excellent Backstage with a comprehensive catalogue, well-authored golden paths, multiple plugins integrated, polished UX. The platform team announces the portal at engineering all-hands. Adoption sits at 5 to 15 percent for the next two years because the portal is treated as an option engineers can take or leave rather than a default they should use.

The mitigation is investing in adoption work upfront and treating it as roughly 30 percent of the year-one effort. Concrete tactics: identify 3 to 5 pilot teams with willing leads and onboard them deeply (weekly check-ins, office hours, hands-on help with their specific use cases). Author internal documentation that walks engineers through the common workflows (creating a service, finding ownership, accessing runbooks) rather than documenting the portal abstractly. Establish gradual mandatory adoption for specific workflows (new service creation through scaffolder, on-call rotation in portal, post-incident review in portal) rather than relying on voluntary adoption. Measure adoption by workflow, not by login count, so the platform team can identify and address gaps where the portal is not picking up traction.

Hiring vs Consultancy: The Long-Term Intent Question

The hire-or-consult decision should be driven by long-term intent rather than year-one cost. If you intend to keep a platform engineer permanently to operate the portal and broader platform engineering work, hire upfront and have them lead the migration. The hire takes 8 to 16 weeks but produces long-term capability that will pay back over years. The migration is also better-scoped because the hire will own the result long-term, which produces appropriate decisions about what to invest in.

If you do not intend to keep a platform engineer permanently (typical for smaller organisations or for organisations evaluating whether the portal investment is worth committing to), use a consultancy for the migration. The engagement is faster but produces no long-term capability. Plan explicitly for what happens after the consultancy hands off; either ongoing managed-Backstage operations through Roadie or equivalent (the lowest-risk handoff) or an internal engineer who takes over operations as a part-time responsibility (works for smaller organisations, breaks down at scale).

The wrong choice is to use a consultancy and then hope an existing engineer can pick up portal operations afterwards. This leaves the organisation with an unmaintained portal in 18 to 24 months because the engineer who inherited operations has no allocated capacity and the framework upgrade tax is real. For more on the consultancy paths specifically, see Frontside cost for the fixed-fee approach and Liatrio cost for the broader DevOps-transformation approach.

Self-Hosted vs Managed Starting Point

For most organisations the right starting point is managed Backstage (Roadie, Coderpath, or similar). The reason: starting managed lets you focus year-one investment on the work that produces organisation-specific value (catalogue, golden paths, adoption) rather than runtime operations. Moving from managed to self-hosted later is a real engagement (typically 3 to 6 months of platform-team work and a $40,000 to $100,000 cost) but not a fundamental re-engineering; the catalogue, golden paths, adoption work transfer cleanly because they are organisation-owned content rather than runtime artefacts. For organisations that already have a capable platform team and a clear preference for in-house operations, starting self-hosted is also viable; the year-one cost is higher but the long-term self-hosted advantage compounds. For a detailed cost breakdown of each path, see Backstage cost for self-hosted and Roadie cost for managed.