Table of Contents
TL;DR
The true cost of our platform migration was not in the migration budget. It arrived afterward: hundreds of SQL queries that had to be optimized for the new database. The problem was big enough that I had an open checkbook, and I spent it on a team of six database specialists for roughly six months. DBAs are not cheap. The lesson executives need: the query layer is where migration costs hide, and it presents its bill after go-live.
When the performance crisis hit after our big-bang platform migration, the emergency fix bought survival, and survival bought time to find the real problem. The real problem was the query layer. Hundreds of SQL queries, written and tuned over years against the old database, behaved badly against the new one. Each query was logically correct. The data came back right. It just came back slowly, and hundreds of slow queries compound into a platform that cannot carry a business.
Why correct queries go bad
This is the part executives deserve to have explained without jargon, because it is where migration budgets quietly detonate. A database is not a filing cabinet that returns what you ask for; it is an engine that decides how to find what you ask for, and every database engine decides differently. A query shaped to be fast on one engine can be pathologically slow on another, not because anything is wrong, but because the new engine takes a different path to the same answer. Multiply that by every query your business has accumulated over decades, and the migration has silently converted your best-tuned asset into your largest liability.
Nothing in our testing fully exposed this, because the compounding only appears under real production load, all the queries, all the users, all at once. Which is why the bill arrived after go-live, in the barely-tolerable weeks, rather than in any planning document.
Why testing missed it
The fair question is why none of this surfaced before go-live, and the answer is a lesson about what testing can and cannot see. Individual queries tested fine, because a query that takes four times longer on the new engine still returns in what looks like acceptable time when it runs alone against a test copy. The pathology was compound: hundreds of modestly degraded queries, sharing one platform, under full production concurrency, with real data distributions the test sets only approximated. Each ingredient was individually testable; the collision of all of them existed only in production. Load testing as a discipline barely existed for us then. Today it exists and is still routinely skipped, with the same result on the same schedule.
If you want the pre-payment version of our lesson: inventory the query workload before committing to the migration, benchmark a representative slice, the heaviest and most frequent queries, against the target platform with production-scale data, and multiply what you find across the full inventory. The number that exercise produces is the real migration estimate. Ours arrived by invoice instead.
Your migration budget covered the weekend. The real bill was hundreds of SQL queries, six DBAs, and six months.Share on X
The open checkbook
The problem was big enough, and the alternative, a rollback of the entire migration, expensive enough, that I effectively had an open checkbook. I could spend whatever it took. What it took was a team of six database administrators, specialists in the new platform, working for roughly six months, and you have to understand that DBAs of that caliber are not cheap. Six of them, half a year, at emergency rates.
I hired a specialist firm rather than pushing the work onto internal staff, and the reasoning holds up decades later. Query optimization at that depth is a distinct craft: reading execution plans, restructuring joins, redesigning indexes for the new engine’s behavior. My people were experts in our systems; the firm’s people were experts in making this database fast. The combination worked. Query by query, hundreds of times over, the platform climbed out of barely tolerable and into genuinely healthy.
The budgeting lesson
Here is what I tell executives planning a platform migration. Your budget covers the visible work: conversion, cutover, infrastructure, testing. The invisible line item is the accumulated tuning of every query your business runs, an asset that does not transfer between platforms and must be rebuilt on the new one. Price that rebuild before you commit, or price it afterward at emergency rates with the company standing on a struggling platform. We did it the second way. The first way is available to anyone who asks the question in time, and the question is simple: what is our plan and budget for re-optimizing the query layer, and who is going to do it?
A migration that ignores that question has not budgeted the migration. It has budgeted the weekend.
For more from this series, see the The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.