I've lost count of how many migration retros I've sat through that started with "well, the migration itself went fine..." and then spiraled into three paragraphs about why the app got slower right after.
That's the part nobody warns you about. A migration can complete with zero errors, every row accounted for, checksums matching, and still leave you with a database that performs worse than the one you started with. It's not a bug. It's just what happens when you move data without thinking about how that data is going to be used on the other side.
Here's what actually tends to go wrong, and what's worked for me (and teams I've worked with) to avoid it.
1. You migrated the data, not the access patterns
This is the big one. Teams spend weeks mapping tables and columns and almost zero time mapping how the application actually queries that data. You end up with a schema that's structurally identical to the old one, sitting on new infrastructure, still getting hit with the same inefficient queries. The only difference is it's now maybe on a system that's not tuned the same way the old one was.
The fix isn't glamorous: before you migrate, pull your slowest and most frequent queries from the old system and test them against the new schema before go-live, not after users start complaining.
2. Indexes didn't come along for the ride
I've seen this more times than I'd like to admit. A migration script moves every row perfectly, but the indexes either don't get recreated, get recreated with default settings, or get created after a huge bulk load (which, to be fair, is sometimes intentional for load speed, but only helps if you remember step two: actually rebuilding them properly afterward).
No indexes, or wrong indexes, means full table scans on data that used to return in milliseconds. It's an easy thing to check for and an easy thing to forget.
3. Nobody re-baselined "normal"
Before a migration, most teams have a rough sense of what normal query latency, CPU load, and connection counts look like. After the migration, that baseline is gone, and there's rarely a plan to establish a new one. So when performance quietly degrades over the following weeks, there's no alert, because nobody defined what "bad" looks like on the new system yet.
Set your monitoring thresholds again after go-live. Don't just reuse the old numbers and assume they still apply.
4. Data bloat came along uninvited
Migrations are a great excuse to finally clean house, and almost nobody takes it. Old logs, soft-deleted rows, duplicate records, orphaned data from years of schema drift. All of it usually just gets copied over as-is because archiving and cleanup weren't scoped into the migration plan. Six months later, someone's asking why the "new" database is already sluggish.
5. The migration was treated as a one-time event, not a process
The teams that come out of a migration in good shape treat it less like a weekend project and more like an ongoing discipline: plan the schema for how it'll actually be queried, validate performance before cutover, re-establish monitoring baselines, and clean up debt instead of dragging it along. The teams that treat it as "move the data, flip the switch, done" are usually the ones back in a war room three months later dealing with the same database performance issues they thought they'd left behind.
If your team doesn't have the bandwidth to plan all of that internally, that's honestly the exact gap that dedicated data migration & management services are built to close. It's about having someone who's done this enough times to know where the landmines usually are before you step on them.
The short version
A migration isn't done when the data lands. It's done when the new system performs at least as well as the old one under real traffic, and stays that way. If you're mid-migration right now, or eyeing one on the roadmap, it's worth pausing to ask: are we planning for where the data goes, or just how it gets there?
Would be curious to hear what's bitten other people during migrations — indexing gotchas, connection pooling surprises, anything that wasn't obvious until it was a 2am incident.
Top comments (0)