Why teams stick with their own workaround
A team with an existing, working (if imperfect) deployment setup has no incentive to migrate to a shinier golden path unless it is genuinely less effort than what they already have, including the migration cost itself — 'better in theory' rarely beats 'already working and I understand it.'
If adopting the golden path requires more upfront work than staying on the existing setup, most teams will rationally choose to stay, regardless of how well-designed the new path is.
Make it the path of least resistance, measurably
Successful golden paths are adopted by new projects first, where there's no existing setup to migrate away from, and then pulled in by existing teams only once the new-project cohort visibly has an easier time — social proof usually works better than a mandate.
Invest disproportionately in the migration tooling, not just the destination state: an automated or semi-automated migration path removes the single biggest reason existing teams delay adopting something objectively better.
Keep it genuinely optional, loudly
Mandating adoption tends to produce resentful, minimal compliance rather than genuine usage, and it removes the feedback signal you need to know whether the path is actually good — if nobody can opt out, you can't tell adoption from compliance.
The platforms that get adopted fastest are the ones the platform team is visibly still improving in response to real user feedback, which is only possible to see clearly when usage is a genuine choice.
A golden path nobody chooses voluntarily is not a golden path. It is a mandate with better branding.MNB DevOps Practice
Key actions
- Target new projects first, where there's no migration cost
- Invest in migration tooling, not just the destination state
- Keep adoption genuinely optional to preserve the feedback signal
- Treat low adoption as a design problem, not a communication problem