Workload scope
Performance tuning and optimization covers the target-platform changes needed to keep migrated workloads predictable for runtime, cost, concurrency, and service-level expectations.
Shared migration method
Baseline the critical workloads before tuning: business purpose, runtime, data scanned or credits consumed, concurrency, output checks, and service-level expectation. Optimise only after preserving semantic correctness. The migration team should be able to explain each layout, materialisation, and capacity decision in terms of observed access patterns rather than platform folklore.
For warehouse targets, use bounded refresh windows, selective predicates, reusable typed transformations, and intentional concurrency isolation. Record the before/after result and retain a regression threshold so a later release cannot silently restore the original cost or latency problem.
Performance evidence
- Rank dashboard, batch, and API workloads by business criticality and measured cost or latency.
- Verify partition elimination, join shape, materialisation reuse, and bounded apply behaviour with representative parameters.
- Compare output parity alongside runtime and cost; a faster query is not acceptable if it changes the result.
- Alert on agreed regressions and assign an owner for each critical workload baseline.
When to use a pair-specific guide
Use a retained pair-specific page where a platform-specific execution model changes the recommendation—for example Snowflake warehouse credits, Redshift distribution choices, or source-specific SQL and storage patterns. The shared guide remains the canonical optimisation method.
Review points
- Partitioning, clustering, pruning, and scan behavior
- Runtime, cost, and concurrency baselines
- Materialization and pre-aggregation decisions
- Regression gates for critical reports and jobs
Acceptance criteria
A performance tuning & optimization page is complete when the migration team can identify source assets, understand conversion assumptions, review unsupported or ambiguous constructs, run validation checks, and decide whether the workload is ready for cutover.
For each related path, confirm that the child page explains what changes, how conversion works, which patterns are supported, what can drift, and which evidence is required before production traffic moves to the target platform.