When a migration isn't worth it

Nearly every migration we review is justified with a monthly saving and paid for with something the justification never mentions: six months of attention from the team that builds the product. That is the real cost, and it is what decides whether the migration is worth it.

The calculation almost nobody completes

A migration’s break-even point is simple to write and annoying to fill in:

months to recover =
    (team hours × hourly cost
     + months of parallel operation × cost of both systems
     + expected cost of incidents)
    ÷ real monthly saving

The three lines in the numerator are the underestimated ones:

• Team hours. Not only whoever executes the migration. Count reviews, coordination meetings, the time of whoever answers questions about the old system, and the product work that didn’t happen.
• Parallel operation. Every responsible migration runs both systems at once for a while. That overlap is a double bill, and it lasts longer than planned in most cases.
• Expected incidents. This isn’t pessimism: a freshly migrated system has a different failure profile from the one your team knows how to diagnose. Budgeting zero incidents is budgeting badly.

And in the denominator, the real monthly saving is rarely the one in the new vendor’s proposal, because the comparison usually omits data egress, backups, monitoring, and the administration hours the new setup requires.

With the full calculation, the rule we use is: under 12 months the migration defends itself; between 12 and 24 it needs a reason beyond cost; beyond 24 months it has to be justified with something that isn’t money.

Four cases where the correct answer is not to migrate

1. The current system is boring and works. “It’s on old technology” is not a business problem if the system is stable, someone knows how to operate it, and the vendor still ships security patches. Technical debt only costs you when it blocks a change you need to make. If nobody is trying to change that system, the debt isn’t accruing interest.

2. The migration depends on one person. If knowledge of the current system lives in a single head and that person is also executing the migration, you don’t have a plan — you have a risk with a schedule. The correct sequence is to document and distribute the knowledge first, and that is already a project of its own.

3. You’re migrating to avoid making a product decision. This happens more than it seems: the system can’t cope because the data model doesn’t support what the business does today, and instead of redesigning the model the infrastructure gets replaced. The load moves to a bigger server and the real problem is still there, now with a larger bill.

4. The saving is real but small next to the opportunity cost. Saving $4k a month is attractive until you work out that the six months of team time spent achieving it were the six months in which you were going to ship the feature that actually generates revenue.

When the answer is yes, without debate

There are cases where the financial analysis is secondary:

• Vendor end of support. When the version you run stops receiving security patches, migration stops being a cost decision and becomes an exposure one.
• A compliance or contractual constraint the current setup cannot satisfy, such as data residency demanded by a client or by regulation.
• A hard technical ceiling within reach. Not “it feels slow”, but a real limit: the vendor’s largest instance, a maximum connection count, a storage cap. Here the question isn’t whether to migrate but when, and it should be before you hit the ceiling.
• Risk concentration on a vendor with no exit. If losing that vendor would leave you without operations and no rollback plan exists, you are paying for insurance you don’t have.

How to lower the cost of a migration that is going ahead

If the decision is to migrate, three things reduce cost more than any technology choice:

Migrate in vertical slices, not in layers. Moving “the whole database” first and “the whole application” afterwards forces you to keep the two halves talking across the network for months. Moving one complete feature end to end lets you validate the entire path with a small scope and learn before repeating it.

Write the rollback plan before the forward plan, and rehearse it. A rollback plan that has never been executed in a drill isn’t a plan; it’s an intention written under pressure.

Freeze functional scope during the migration. The temptation to “while we’re here, let’s improve X” is why migrations double in duration. If the new system does different things from the old one, you can’t compare behaviour to know whether the migration went well.

---

If you have a migration planned and want the break-even calculation run with your own numbers, get in touch. Sometimes the outcome of the analysis is that you shouldn’t do it, and that is a valid deliverable too.