Performance problems are the rule, not the exception
We move because the platforms differ, then expect identical behaviour. Results usually match. Performance never does.
There is a contradiction sitting at the centre of every migration and almost nobody says it out loud.
We move to a new platform precisely because it is different — and then we expect everything to behave exactly the same. Different architecture, different optimiser, different storage, different concurrency model, different everything. That difference is the entire business case. And then the acceptance criteria say: same results, same performance.
The first half of that expectation is usually met. Results generally do match, or the differences are explicable. Which is exactly what makes the second half so dangerous, because a team that has seen the numbers reconcile reasonably concludes the migration is sound — and is then blindsided.
The second half is never met. I have never been involved in a migration that did not have at least one significant performance problem, and usually several. Not a slightly slower query. A workload that matters, missing its window, with a business owner asking what has been done to their platform.
Treat that as the base rate. Performance problems are not a risk to be mitigated on a migration. They are a certainty to be planned for.
Why tuning does not travel
The queries running on the old platform are not neutral SQL. They are the end product of years of tuning against one specific combination of optimiser, storage, memory model, indexing strategy, physical layout, statistics regime and hardware. Every awkward workaround, every hint, every index that exists for one report, every physical design choice made in response to a problem someone hit in 2016 — all of it is accumulated adaptation to a platform you are about to replace.
That adaptation is a real asset and it is completely non-transferable. Worse, it is largely invisible: nobody documented why the hint is there, and the person who added it has gone. Some of it will be neutral on the target. Some will be actively harmful — a hint that forced the right plan on the old optimiser can force a terrible one on the new.
So the expectation to set with stakeholders, early and repeatedly, is not “it will perform the same.” It is: this workload was tuned for a platform we are leaving, and it will need to be tuned for the one we are moving to. That is not a defect. It is the work.
Only full volume tells you anything
Performance problems surface at real data volumes and real concurrency, and essentially nowhere else.
This is not merely a matter of degree. Behaviour changes qualitatively with scale: the optimiser makes different choices as cardinality rises, parallelism thresholds get crossed, memory allocations stop being sufficient and operations spill, join methods flip, partition pruning starts or stops being effective. A query that looks healthy against a 5% subset can fall off a cliff at 100%, and nothing in the subset result predicts it.
So a scaled-down performance test is not a weak version of a real one. It is a different test that answers a different question, and it will give you false confidence rather than partial confidence. Full-scale performance testing, against representative volumes and the real concurrency shape, is not optional on a large platform. If the programme cannot afford a full-scale test environment, that is a finding to escalate, not a constraint to work around quietly.
Test the concurrency shape, not just the queries: the morning report burst, the overnight batch overlapping the early users, month-end landing on top of ordinary load. Single-query timings tell you little about a platform that will be shared.
Plan the rectification, do not call it contingency
This is where most plans fail, and it is the most actionable point here.
Because performance problems are certain, the time to fix them belongs in the plan as a named, resourced workstream with a duration — not as contingency, not as a line in the risk register, not as something the team absorbs. Contingency is for things that might happen. This will happen.
Be realistic about the duration, because fixes are not always easy. Some are: gather statistics, add an index, adjust a parallel degree. Others require rewriting SQL that no one fully understands, changing a physical design decision that other things depend on, or reworking a batch sequence that has run unchanged for a decade. The distribution has a long tail, and you will not know which problems you have until full-scale testing finds them.
Two further points to protect the workstream:
Statistics are the first thing to check. A disproportionate share of post-migration performance problems are stale, missing or unrepresentative statistics on the target — particularly after a physical transport, where the data arrived without the usual gathering path. Rule this out before anyone starts rewriting anything.
Expect the plans to differ, and treat that as normal. A different optimiser with different statistics and different parallelism will produce different execution plans. Some will be faster, some slower. The objective is not to reproduce the old plans; it is to meet the business requirement. Teams that set out to make the new platform behave like the old one spend enormous effort fighting the thing they paid to acquire.
Capture the baseline while you still can
Capture a performance baseline on the source before you move. Elapsed times and resource profiles for the critical queries, the batch window and the concurrency peak. You cannot demonstrate parity against a baseline you did not take, and after cutover the source is frozen or gone. This is done early or not at all, and it is routinely forgotten.
Agree what parity means before you test. “As fast as before” is not a specification, and it is neither always achievable nor always necessary — some of these workloads have windows measured in hours and business requirements measured in minutes. Set acceptance thresholds per workload group, with the business owner, in advance. After cutover every regression becomes an escalation, and without agreed thresholds you have no basis for saying which ones actually matter.
A note on the apparent contradiction
Discovery before the business case argues that performance makes a poor headline acceptance criterion. This section argues that performance problems are certain and must be planned for. Both are true, and the tension between them is instructive.
Performance is a bad criterion for judging whether a programme should proceed, because it is the question a migration team is best equipped to answer and it tells you nothing about scope, dependencies or the consumption layer — which is where programmes actually fail. It is simultaneously a certainty as an operational problem, because tuning does not travel.
The failure mode is using early performance results as evidence that the migration is going well. They are not evidence of that. They are evidence about performance, on the workloads someone thought to test, at whatever scale was available.