Capability / Snowflake migration
Snowflake Migration Services
A Snowflake migration moves a warehouse and everything that depends on it onto the Snowflake platform without changing what the business understands the numbers to mean. Quorlytic discovers the real dependency set, translates logic rather than transcribing it, reconciles old and new in parallel, and cuts consumers over in phases against a rollback path that has been exercised.
By QuorlyticUpdated
The platform move is the straightforward half. The work is in the stored procedures nobody will claim, the extracts nobody documented, and proving the new number matches the old one.
- 01Discover
- 02Translate
- 03Reconcile
- 04Cut over
The business problem
A Teradata estate, a SQL Server warehouse, a Netezza appliance and a Redshift cluster each present a different problem. Procedural logic, proprietary functions, distribution and indexing strategies, and identity and sequence behaviour all translate differently. Estimating a migration without naming the source is estimating the easy part.
What we build
Query logs reveal consumers the platform team has never met: finance extracts, an application reading a view directly, a reporting tool refreshing overnight. Building the dependency set from logs and lineage rather than from documentation is what makes a cutover plan realistic.
The outcome
A migrated Snowflake platform with reconciliation evidence, tested access and a dated retirement plan for the legacy warehouse
When this is the right engagement
Symptoms that bring teams here.
These symptoms indicate a migration is being contemplated without the discovery that makes it plannable.
The estimate was produced without a query log
Scope is based on the object count, which is the easy half and not the one that slips.
Nobody will claim a set of stored procedures
Business logic with no owner is the single largest source of migration risk.
A licence or support end date is setting the timeline
The deadline is external, so the plan has to be reversible rather than optimistic.
The target was chosen from a demonstration
Nothing has been tested against your workload, concurrency or access rules.
Parallel running is described as a week at the end
Reconciliation is being treated as a formality rather than as the evidence for cutover.
Capability model
The four migration problems.
A Snowflake migration is four distinct problems, and the platform move is the smallest of them. Select one to see what it involves.
01 — Dependencies
Build the true consumer set from query logs and lineage, not from documentation or memory.
What it produces
A dependency map with a named owner per consumer.
What usually goes wrong
- Extracts and applications reading the warehouse directly
- Reports built outside the platform team
- Jobs whose dependencies are implied by a start time
Technologies in this stage
- Query log analysis
- Lineage capture
- Access log review
02 — Logic
Move behaviour faithfully into tested, version-controlled transformations, retiring what the logs show nobody uses.
What it produces
Translated logic with deliberate exclusions and behaviour changes recorded.
What usually goes wrong
- Procedural logic with no direct equivalent
- Dialect differences in null ordering, precision and date arithmetic
- Redesigning the model mid-migration
Technologies in this stage
- dbt
- SQL translation
- Conversion tooling
- Test suites
03 — Platform shape
Configure Snowflake deliberately, because separated compute changes how the platform should be used and priced.
What it produces
A warehouse topology matched to measured workloads, with a cost baseline.
What usually goes wrong
- Warehouse sizing inherited from legacy contention assumptions
- Auto-suspend left at defaults
- Clustering applied without evidence from query patterns
Technologies in this stage
- Warehouse sizing
- Auto-suspend
- Clustering
- Result caching
04 — Evidence
Prove business behaviour is unchanged, and make the cutover decision against an agreed standard rather than under time pressure.
What it produces
A reconciliation report and a release gate agreed in advance.
What usually goes wrong
- Totals compared but not distributions
- Time zone and rounding differences dismissed as noise
- No agreed threshold for what blocks release
Technologies in this stage
- Parallel run
- Reconciliation tests
- Metric comparison
- Sampling
Illustrative reference architecture
Reference architecture
The migration drawn as a sequence of gates rather than a lift. Each gate is a point where the work can still be stopped, which is what keeps the programme reversible until it deliberately is not.
Legacy warehouse
Teradata, SQL Server, Netezza, Oracle or Redshift, with its procedural logic.
- Tables
- Procedures
- Scheduled jobs
- Extracts
Discovery gate
The consumer set, built from logs rather than documentation.
- Query logs
- Lineage
- Consumer owners
Snowflake platform
Warehouses separated per workload, sized from measured patterns.
- Databases
- Warehouses
- Roles
- Policies
Reconciliation gate
Both platforms producing the same outputs for an agreed period.
- Counts
- Aggregates
- Samples
- Key metrics
Access gate
Roles and row-level policies tested with real consumer identities.
- Roles
- Row policies
- Masking
- Service identities
Phased cutover
Consumers moved in groups, each with an exercised rollback.
- Consumer groups
- Rollback window
- Sign-off
Held open until retirement
- Rollback path
- Legacy availability
- Retention requirements
- Dual-running cost
- Consumer communication
The approach
- 01
The source platform decides most of the effort
A Teradata estate, a SQL Server warehouse, a Netezza appliance and a Redshift cluster each present a different problem. Procedural logic, proprietary functions, distribution and indexing strategies, and identity and sequence behaviour all translate differently. Estimating a migration without naming the source is estimating the easy part.
- Dialect differences in date arithmetic, null ordering and precision catalogued
- Procedural logic assessed for translation or redesign
- Physical design assumptions that do not carry over identified early
- 02
Discovery is longer than expected, and skipping it is why migrations slip
Query logs reveal consumers the platform team has never met: finance extracts, an application reading a view directly, a reporting tool refreshing overnight. Building the dependency set from logs and lineage rather than from documentation is what makes a cutover plan realistic.
- 03
Translate the logic, do not transcribe it
A migration is the one moment when removing unused logic is cheap, and the one moment when redesigning everything is most tempting and most dangerous. The discipline is to move behaviour faithfully into tested, version-controlled transformations, retire what the logs show nobody uses, and record any deliberate behaviour change as a decision rather than letting it surface as a defect.
- Unused objects retired on evidence from query logs
- Behaviour changes recorded as decisions with an owner
- Logic moved into tested, version-controlled models
- 04
Snowflake's cost model changes how the platform should be used
Separating storage from compute, and separating warehouses per workload, removes the contention that shaped the legacy design. It also means an inefficient query now has a direct and visible price. Warehouse sizing, auto-suspend behaviour, clustering choices and result caching are decisions to make deliberately during the migration rather than defaults to discover on the first invoice.
- Compute separated per workload so contention and cost are both attributable
- Auto-suspend and sizing set per warehouse from measured query patterns
- Clustering applied only where query patterns demonstrate the need
- 05
Reconciliation is the deliverable that makes the move defensible
Running both platforms in parallel and comparing counts, aggregates, record samples and the business metrics people actually quote is what converts a cutover from a judgement call into an evidenced decision. Time zones, rounding, null ordering and late-arriving data produce most of the early differences, and each has to be resolved as either a defect or a correction.
- 06
Move access and identity before you move consumers
Roles, row-level policies, masking and service identities are the part most likely to be discovered late. Modelling the access hierarchy in Snowflake and testing it with the identities real consumers hold — not with an administrator account — removes the failure mode where cutover succeeds technically and immediately breaks who can see what.
- 07
Retire on a date, not on a feeling
Dual running costs money every day it continues, and without an owner and a date it continues indefinitely. Retirement needs retention requirements satisfied, consumer sign-off recorded, rollback formally stood down and the legacy licence exit planned.
Delivery model
How the work is sequenced.
Four phases, each ending in evidence rather than in a status update.
| Phase | Activities | Decisions made here | What you keep |
|---|---|---|---|
| DiscoverFind every consumer, including the ones nobody listed. |
|
| Dependency map, usage evidence and retirement list |
| TranslateMove logic into a tested form. |
|
| Version-controlled transformations with tests, and a configured platform |
| ReconcileProduce the evidence that cutover is safe. |
|
| Reconciliation report and access test results |
| Cut overMove consumers, then retire on a date. |
|
| Cutover record, cost baseline and a dated retirement plan |
Technology fit
What each technology is here to do.
What is involved, by role. The source platform usually determines more of the effort than the target does.
Source systems
- Teradata
- SQL Server
- Netezza
- Oracle
- Redshift
Dialect, procedural logic and physical design assumptions drive most of the translation work.
Target configuration
- Warehouses
- Roles and policies
- Clustering
- Result caching
Separated compute removes legacy contention and makes an inefficient query directly priced, so configuration is a design decision.
Platform detailConversion
- dbt
- SQL translation tooling
- Python
- Test suites
Tooling accelerates the first pass. Judgement handles what it cannot, and tests are what make either trustworthy.
Proof
- Parallel run
- Reconciliation tests
- Metric comparison
- Access testing
The evidence that business behaviour is unchanged, which is the actual deliverable of a migration.
Transition
- Phased release
- Rollback plan
- Retention policy
- Licence exit
Keeping the move reversible, and then ending that reversibility deliberately on a date.
Technology marks belong to their respective owners. No partnership, certification or endorsement is implied.
Engineering concerns
What has to be answered before it is trusted.
What has to be true before consumers are moved.
- Usage evidence
- Scope decisions based on query logs rather than on what people believe is still used.
- Behaviour parity
- Null ordering, decimal precision, date arithmetic and time zone handling verified explicitly, not assumed to transfer.
- Access parity
- Roles, row policies and masking tested with real consumer identities before cutover, never with an administrator account.
- Exercised rollback
- A rollback that has actually been run in a rehearsal. An untested rollback is a hope with a document attached.
- Cost baseline
- Warehouse sizing, auto-suspend and workload isolation set from measured patterns, with a baseline recorded at cutover.
- Retirement conditions
- Retention satisfied, consumer sign-off recorded and a date agreed, so dual running ends on purpose.
Where it applies
Related work, and why it is related.
What this sits between, and where it hands off.
- Data modernizationThe parent service, and the right page when the target platform has not yet been chosen.
- SnowflakePlatform architecture, workload isolation and cost model — the detail behind the target configuration.
- Data and AI advisoryIf the target has not been tested against your workload, that evaluation belongs before a migration is committed to.
- Financial servicesReconciliation evidence and explainability requirements lengthen the parallel-run phase and make it non-negotiable.
Turn a source object into an acceptance requirement.
A migration assessment needs the behavior a consumer relies on, alongside the source code. In this hypothetical intake, a Teradata batch produces a daily finance extract. Its SQL, scheduler dependencies and restart behavior need separate decisions before a Snowflake implementation can be accepted.
Scope and assumptions: Adapt the intake to the source system, destination design and finance owner's acceptance rules. No executable BTEQ or macro conversion is supplied.
| Dimension | Evidence and proposed decision | Acceptance evidence and sign-off |
|---|---|---|
| Source construct | Collect the batch script, invoked SQL objects, scheduler inputs and failure branches. Separate data transformation from orchestration; do not assume translating SQL preserves the complete job. | Source maintainer confirms the dependency inventory and identifies the restart point used after a partial failure. |
| Dependent consumer | Record the finance extract's business date, delivery condition and downstream report. Retain that contract while evaluating a destination design. | Finance owner supplies a representative accepted extract and the rule that determines which accounting day it represents. |
| Semantic risk | Record missing amounts, numeric scale and the handling of transactions near the business-day boundary. Make the target timestamp type and session settings explicit. | Engineer compares missing-value cases, rounding boundaries and day assignment; finance approves the expected results and tolerance. |
| Recovery decision | Propose a restart design only after establishing what a repeated source batch does to previously written records and delivered files. | A controlled partial-failure and replay test checks for lost or duplicated business records. The operator records the recovery decision. |
| Release gate | Keep unresolved differences attached to this object rather than treating successful execution as semantic equivalence. | Named engineer and business owner sign the evidence record before the change approver considers consumer cutover. |
At narrow widths, scroll the worksheet to read every column. With the table focused, use the arrow keys to scroll.
Worked decision: matching the extract's row count would still leave a wrong business date undetected. If the boundary-case comparison differs, retain the existing consumer path, document the discrepancy and revisit the timestamp mapping before requesting sign-off. This is a proposed test decision, not an observed project result.
- Attach source and target versions, parameters, the input snapshot identifier and result evidence to the same intake record. Use approved, sanitized samples; do not include credentials or confidential extracts in a public brief.
- Snowflake distinguishes timestamp variants and numeric precision/scale. Confirm both source semantics and the destination settings in the representative environment; vendor conversion support alone does not establish acceptance.
For cross-platform validation and cutover planning, use the warehouse acceptance and cutover playbook. Keep the source-specific intake attached to the assessment.
Official references for this example:
Questions
Questions worth asking.
How long does a Snowflake migration take?
It is governed by the dependency set and the amount of procedural logic, not by data volume. Moving data is rarely the constraint; discovering every consumer, translating stored procedures and running a credible parallel period is. We size it after discovery rather than before, because an estimate given before the dependency map exists is an estimate of the easy half.
Can the migration be automated?
Partly. Schema and straightforward SQL translation respond well to tooling, and it is worth using. Procedural logic, physical design assumptions and anything relying on source-specific behaviour need engineering judgement, and the reconciliation that proves the result is correct cannot be automated away. Treat conversion tools as an accelerator for the first pass, not as the migration.
Do we migrate everything?
Usually not, and that is a benefit rather than a compromise. Query logs typically show a meaningful share of objects with no reader in the last year. Retiring those on evidence reduces scope, cost and future maintenance. What is retired is recorded and agreed rather than quietly dropped.
How do we know the numbers match?
Both platforms run in parallel for an agreed period while counts, aggregates, record-level samples and the specific business metrics people quote are compared. Thresholds for what blocks a cutover are agreed in advance, so a difference found late is assessed against a standard rather than debated under time pressure.
Will Snowflake cost more than our current platform?
It depends on workload shape and how the platform is configured, and anyone answering confidently without your query profile is guessing. Separated compute makes cost attributable and elastic, which helps bursty workloads and can penalise inefficient always-on ones. We model it from your measured query patterns during the proving phase rather than from list pricing.
What happens if something goes wrong after cutover?
Each consumer moves in a phase with a rollback path that has been exercised, not merely documented, and the legacy platform stays available until retention, sign-off and a stated rollback window all allow it to be retired. Rollback triggers are agreed before the first consumer moves.
Is Snowflake the right target for us?
Not always. A lakehouse suits large volumes of semi-structured data and machine-learning workloads that need the same files; a warehouse suits governed, concurrent, well-modelled analytical queries. If the target has not been tested against your workload, that evaluation belongs in an advisory engagement before a migration is committed to.
Do you hold a Snowflake partnership?
No. Quorlytic holds no partner status, reseller agreement or certification with Snowflake or any other platform vendor, and none is implied anywhere on this site. Recommendations are based on your workload and constraints, and the decision record states the options considered and why each was set aside.
Next step
Review your Snowflake migration plan.
Bring the source platform and a query log export. Those two things make the first estimate real.