Migration is an eternal topic in our world. We are always innovating, adding new tools, systems, workflows - that’s the nature of what we do. Or the less sappy side of the coin, we are always acquiring, getting acquired or getting management mandates because they prefer one system over another, or got convinced of one at a Gartner conference;)

The problem with migration though is that it costs. A lot. Far more than people appreciate. In this week's community webinar, Loreli Cadapan,VP of Product at CloudBees and Ajay Chankramath, Platform Engineering Ambassador, and CEO of Platformetrics broke down how and why teams mess up migrations so frequently, why we need to be thinking about modernization instead - and what you need to be doing to not fail.

First, some data from the Migration Index Report that blew my mind.

• Average migration cost: $1.75 million
• Average cost overrun: $315,000 per enterprise (18% over budget)
• 37% of organizations lost a quarter of their migration budget to hidden costs
• 94% saw slower or the same system performance post-migration
• 60% missed estimated revenue opportunities from delayed launches

More than these clear hits of actual $ spent. There are the hidden ones. The integration tax on things like increased cognitive load burning teams out and decreasing productivity, morale hits, even the cost of increased risk exposure.

The platform team is often some of  the most experienced, and highest paid engineers in the org, and most of the time during a migration we switch from being builders and operators to just full time integrators burning brain power (and time) dealing with compatibility issues and maintaining dual systems rather than producing.

So what is the alternative? Thinking modernization NOT migration.

While a migration may concentrate on swapping one tool for another, modernization takes a zoomed out view, working to improve the system as a whole.

For example, changing the URL of your CI server doesn’t improve how value flows through your org... If you lift and shift a crappy, fragmented process onto a new platform, you don’t get rid of the mess, you just spread it.

New tool + old process = expensive old process

Here are some of the tips from the webinar that stuck out to me:

Evaluate capability gaps before replacing tools: Stop asking, “What should we replace tool A with?” Start asking, “What capabilities are we missing?” Focus on outcomes, not products. Identify gaps in areas like policy enforcement, scalable builds, or SLO visibility first then decide if a new tool is actually needed.

Run ROI simulations before committing: Don’t migrate on vibes. Model the reality. Test three paths: wrap what you have with APIs and governance, fully replace it (including dual-stack pain), or selectively migrate capabilities. The hybrid approach is often by FAR most practical.

Migrate capabilities, not products: This isn’t about moving from tool A to tool B. It’s about evolving what your platform can do. Define clear exit criteria for legacy systems. Decide upfront what must be true before the old system gets turned off. Without hard decommission triggers, legacy systems stick around…. and around and around….

Protect developer experience during transition: Most devs didn’t ask for the migration (and probably don’t want to migrate at all ahah) and if it slows them down, they’ll resist it. So mission one is to minimize their inconvenience. Protect their ability to ship with flexibility, with things like safe sandboxes, automated compatibility checks, and clear telemetry. If devs feel supported, the migration stands a chance.

Migrations are an eternal fact of our lives but with all this in mind - we can nail them.

Let’s do it.