A slow query, a licence renewal or a rising cloud bill can start the same conversation: should we move to a different data platform? The useful first question is more specific: which requirement can the current system no longer meet, and what evidence shows why?
Migration can be the right answer. So can targeted optimisation, a change in operating practice or modernising one part of the architecture. A defensible decision compares those options against the same requirements.
Separate the symptom from the requirement
“The warehouse is slow” describes an experience, not a diagnosis. A useful requirement might be that a particular reporting dataset must be ready by 07:00, including validation, while a defined number of users run interactive queries. That gives you something to measure and test.
Record the affected process, its users, current behaviour and required behaviour. Include freshness, correctness, availability, governance and recoverability as well as speed. The platform decision is downstream of those requirements.
Establish a baseline before comparing platforms
Choose representative workloads and observation periods. Capture input volumes, elapsed time, resource consumption, concurrency and failure behaviour where your system exposes them. Include busy periods and dependencies rather than relying on one isolated query.
For cost, distinguish the existing contractual commitment from costs that would actually change. Add operating effort, storage, data movement, licences and support where relevant. Record what you do not yet know. A precise-looking total built on untested assumptions is still uncertain.
When optimisation deserves the first investigation
Optimisation is a strong candidate when the platform can meet the required capabilities but execution is inefficient. Potential causes include unsuitable SQL, poor estimates, data skew, unnecessary processing, scheduling contention or configuration that no longer fits the workload.
Test a bounded change against the baseline. Check correctness as well as runtime, and repeat under comparable conditions. If a small, maintainable improvement meets the requirement, a larger migration may not be justified by that problem alone.
For Teradata examples, see our guides to spool-space investigation and the performance-tuning engagement process.
When selective modernisation is a better fit
Some constraints sit around the database rather than inside its engine. Manual deployment, fragile orchestration, missing quality checks or unclear ownership can make a capable platform difficult to operate.
Replacing a pipeline, standardising transformations or improving monitoring may address those issues without moving every workload. Be explicit about the boundary: which component changes, which interfaces stay stable and who operates the result?
Selective modernisation still needs validation and rollback planning. A smaller change has a narrower scope; it does not automatically have no risk.
When migration is worth testing
Migration deserves serious evaluation when requirements cannot reasonably be met by the current architecture, when commercial or support constraints change the options, or when a broader strategy requires capabilities the present environment cannot provide at an acceptable cost.
State the expected benefit in testable terms. “Move to the cloud” is a location decision. “Meet this workload and recovery target within this cost and operational model” is a proposition you can investigate.
A representative proof of concept should include difficult workloads and edge cases, not only the easiest demonstration. Validate business semantics, data types, numeric precision, duplicate handling and operational recovery. For one concrete path, read our Teradata-to-Snowflake migration scope.
Compare the options on the same terms
| Decision area | Evidence to request |
|---|---|
| Business fit | Which requirements does the option meet, and which remain unresolved? |
| Performance | Representative measurements, concurrency assumptions and correctness checks. |
| Cost | Transition costs, parallel operation, ongoing consumption and internal effort. |
| Delivery risk | Dependencies, conversion complexity, validation coverage and rollback conditions. |
| Operating model | Required skills, ownership, monitoring, recovery and support arrangements. |
| Uncertainty | Assumptions that still need measurements, commercial clarification or a proof of concept. |
Platforms such as Teradata, Oracle, SQL Server, PostgreSQL, Databricks, Snowflake and Microsoft Fabric differ in architecture and operating model. A feature checklist cannot establish which one is best for a particular workload. The comparison needs your requirements and a representative implementation.
Include the cost of getting there
The target platform bill is only part of a migration decision. Budget for dependency discovery, data-model and SQL changes, pipeline work, reconciliation, parallel running, training and handover. Identify work the internal team must perform while keeping the existing system operational.
Also consider the alternative. Staying can carry its own costs and risks, including deferred maintenance or capability gaps. Independence means examining both options fairly, rather than assuming either that new is better or that familiar is safer.
Write down the decision and its conditions
A useful recommendation names the preferred option, the evidence supporting it, unresolved risks and the next validation step. It should explain what would change the recommendation.
For example, a recommendation might be to tune the existing workload first, then reassess if the agreed processing window remains unmet. Another might be to test a target platform against defined workloads before committing to a wider migration. These are decision patterns, not reports of particular client results.
Prepare for an independent assessment
- The business decision and deadline.
- The systems and workloads affected.
- Current measurements and required outcomes.
- Known contractual, access and governance constraints.
- The people who will own and operate the result.
You do not need every answer before starting. You do need to distinguish established facts from assumptions and agree how the important unknowns will be resolved.
DWHPro offers independent platform assessments and data engineering delivery. The recommendation can be to improve what you already have. Discuss the decision you need to make.