01
Warehouse Inventory
Tables, views, stored procedures, load scripts, schedules, consumers and permissions on the source, classified by how they will move.
Snowflake Migration
Snowflake Migration Services: Source by Source, With the Validation to Prove the Numbers Match
Last reviewed by Tyler Eastridge
AceMQ plans and runs migrations to Snowflake from Teradata, Netezza, Hadoop and Hive, Greenplum, Redshift, Oracle, SQL Server and other warehouses, with partner Snowflake specialists in an account you own. We inventory what runs on the old platform, use Snowflake's free SnowConvert AI where it fits, review what it cannot convert, and run old and new in parallel until the results match. AceMQ is an independent provider, not a Snowflake partner.
- source platforms listed as generally available in SnowConvert AI
- 15
- of those sources gets package conversion: Oracle
- 1
- hour to a reply on a quote request
- 1
Is This You?
You probably need this if…
- 01
A Teradata, Netezza, Hadoop or Greenplum renewal or hardware refresh is close and the destination has not been proven
- 02
A converter ran on the SQL and reported a score, and nobody has read what the score leaves out
- 03
The old warehouse holds years of stored procedures, load scripts and reports that no one has inventoried
- 04
Reporting cannot go dark, so a big-bang cutover is off the table
- 05
The finance team wants to know how Snowflake credit use will behave before the old platform is switched off
- 06
Hive tables, Spark jobs and warehouse SQL sit on different platforms and need one plan
- 07
You are choosing between Snowflake, Databricks and staying put, and want the migration effort on the table before deciding
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Snowflake estate when the engagement closes.
Before
Nobody can list every table, job, procedure and consumer on the old platform.
After
A written inventory with each workload given a migration path, a validation method and a place in the order.
Before
A converter's output is treated as finished code.
After
Converted code reviewed by engineers, with every flagged difference resolved, tested or consciously accepted.
Before
Cutover rests on someone saying the new numbers look right.
After
Reconciliation per workload: row counts, aggregates and query results compared against the source before anything is switched.
Before
The old platform stays on because nobody dares to switch it off.
After
A cutover plan with a rollback window and a decommission step for each wave.
Scope
What's covered
- 02
SnowConvert AI Runs and Review
Assessment and conversion runs on the SQL, followed by engineer review of every flagged difference. Snowflake's tool is free; the review is the work.
- 03
Data Movement
Extraction, staging and loading into Snowflake, with the method chosen per source and per table size, and ongoing loads for tables that keep changing.
- 04
Parallel Run
Old and new platforms run side by side, with scheduled reconciliation, until each workload's results match.
- 05
Validation
Row counts, aggregates and sampled row comparison, with a written pass criterion for each workload.
- 06
Spark and Hive Code
Spark code assessed with Snowflake's Snowpark Migration Accelerator where it applies, and Hive tables moved as tables and views.
- 07
Roles and Access
Source permissions mapped to Snowflake roles and grants in your identity provider's groups.
- 08
Credit and Cost Design
Warehouse sizing, auto-suspend and resource monitors set up before load, so the bill during parallel run is predictable.
- 09
Handover
Runbooks for your team, and optional 24/7 Snowflake support afterwards.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 1Scoped per estate
Assess
Inventory the source, run SnowConvert AI's assessment, and read the output ourselves: a completeness score tells you what was parsed, not what will behave the same.
You receive
- Inventory of objects, jobs, schedules and consumers
- Conversion coverage per source and what needs manual work
- Order of work in waves
- Phase 2Scoped per program
Design
Account and database layout, role model, load method per source, warehouse and resource monitor settings, validation criteria and the rollback window per wave.
You receive
- Target design in your Snowflake account
- Load, validation and cutover plan
- Cost guardrails for the migration period
- Phase 3Per wave
Convert and load
Convert code, resolve flagged differences, load data and test reports against the new tables with production-sized data.
You receive
- Reviewed and tested converted code
- Loaded data with reconciliation reports
- List of accepted differences
- Phase 4Until results match
Parallel run
Run both platforms and compare scheduled outputs, fixing differences at the source of the difference rather than hiding them in reports.
You receive
- Daily or scheduled reconciliation
- Signed-off pass criteria per workload
- Go or no-go decision per wave
- Phase 5Planned change windows
Cut over and decommission
Switch consumers to Snowflake in waves with the rollback window open, then retire the source platform with sign-off, so licences and hosting actually stop.
You receive
- Consumers on Snowflake
- Decommission sign-off per source system
- Optional 24/7 support or managed service
What SnowConvert AI converts, source by source
Snowflake's SnowConvert AI converts source database code to Snowflake and, per Snowflake's FAQ, is free. Its About page lists 15 generally available source platforms, and the conversion scope differs sharply between them. Only Oracle gets package conversion, and eight of the sources are converted as tables and views only. That table is where a plan starts.
| Source | Converted by SnowConvert AI | Other documented support | What we plan |
|---|---|---|---|
| Teradata | Tables, views, stored procedures, functions, BTEQ, MLOAD and TPUMP scripts | Extraction script. The AIM Agent lists deterministic conversion and cloud data migration, with AI conversion and code deploy planned. | BTEQ and load scripts are the long tail: inventory them first, they hold the schedule. |
| Oracle | Tables, views, stored procedures, functions and packages | Extraction script. The AIM Agent lists the same support as Teradata. | The only source with package conversion, so also the one where package review matters most. |
| SQL Server and Redshift | Tables, views, stored procedures and functions | Direct database connection, data migration and Snowflake deployment listed, and AI code conversion. | The best-supported routes. Reconciliation still decides when each workload switches. |
| Azure Synapse, Sybase IQ, IBM Db2 | Tables, views, stored procedures and functions | Extraction script for Synapse and Sybase IQ. Db2 appears in the AIM Agent for cloud data migration and validation. | Check the data-movement route per source; it is not uniform. |
| Netezza | Tables and views only | None beyond conversion. | Stored logic is rebuilt by hand. IBM's N3001 appliance support ended 30 April 2023, so the hardware itself can be the deadline. |
| Greenplum | Tables and views only | None beyond conversion. | Functions and procedural code are rebuilt by hand. The source is covered on our Greenplum page. |
| Hadoop and Hive | Hive: tables and views only | Hive is the only Hadoop source on Snowflake's list. | HDFS data, Hive metastore objects, Oozie-style schedules and policies are inventoried and moved separately. |
| PostgreSQL, Vertica, BigQuery, Spark SQL, Databricks SQL | Tables and views only | BigQuery: extraction script and AI code conversion. PostgreSQL: AIM Agent lists extraction, conversion, deploy and data migration. | Logic in routines is rebuilt by hand and tested. |
The table is the reason we do not quote a conversion percentage. For most sources the tool brings the tables and views across and leaves the logic to engineers, and for the sources where it handles procedures it still flags differences. Snowflake's docs describe the flags as errors, warnings and issues (EWIs) and functional difference messages (FDMs), to be resolved manually or with its AI code conversion, which generates tests to verify the converted code. A code completeness score below 100 means missing object references were detected.
Free tool, not a free migration
SnowConvert AI is free. The review of what it flags, the data movement, the parallel run and Snowflake's own consumption charges are not. We say that in the first call so the business case includes them.
Moving data and proving it: parallel run and reconciliation
Data movement and code conversion are separate tracks. Snowflake's AIM Agent for Data Warehouses lays the migration out in stages, connect, init, register, convert, assess and migrate, with deploy, data migration, validation and fixing repeated wave by wave. Its overview page does not say whether the agent is preview or generally available, so we treat it as one input and not as the plan. Our own plan keeps the same discipline: small waves, validation inside each wave, and a decision at the end of each.
- Load method — Chosen per source and per table: bulk load for static history, incremental loading for tables that keep changing during the parallel run.
- Reconciliation — Row counts and aggregates at table level, then sampled row comparison on the tables where money or compliance depends on exact values.
- Query comparison — The reports that matter are run on both platforms and compared, with differences traced to their cause before the report is switched.
- Exit criteria — Each workload has a written pass condition and an owner who signs it. The source is not switched off until every consumer has signed.
For Spark code, Snowflake's Snowpark Migration Accelerator scans source code and notebooks for Spark API calls and converts them to Snowpark equivalents where possible, adding comments where manual work is needed. Its assessment mode is described as a free analysis tool, and the conversion mode is priced under its own terms. We run the assessment, read what it flags and plan the rest.
Keeping credit use predictable while two platforms run
Parallel run means paying for both platforms for a while, so the migration needs cost guardrails before the first load. We set warehouse sizes, auto-suspend and resource monitors in design, load large history on a schedule that does not leave warehouses running idle, and review credit use at each wave boundary, so an overrun shows up at the next wave review and not on the invoice.
Ongoing cost governance and pipeline reliability after the move are covered by Snowflake consulting and 24/7 support, which the same engineers can provide.
Who this is not for
- Anyone expecting one-click migration — Snowflake's own documentation does not claim that all code converts automatically, and neither do we.
- Snowflake partner requirements — AceMQ is an independent provider: it is not a Snowflake partner and holds no Snowflake certifications. If a procurement rule requires a partner, we are not the right vendor.
- Application and BI rewrites — We migrate the warehouse and test your reports against it. Rebuilding dashboards or application code belongs to your teams.
- Estates that should stay put — A warehouse that is healthy, cheap to run and not facing a deadline may not justify a move. We say so after the assessment.
- Teams that want the cheapest tool run — SnowConvert AI is free and Snowflake documents how to run it yourself. We add value where its output needs review and the parallel run needs discipline.
Typical engagements
How these engagements run
Typical engagement scenarios: what the work covers and what it delivers. They describe the service, not past results.
Snowflake Query Spilling and Warehouse Queueing Remediation
Global Insurance Group
Resolving pipeline runtime blowouts caused by queries spilling to remote storage on undersized warehouses while concurrent jobs queued behind them.
Snowflake
dbt
Airflow
TerraformSnowflake Ingestion Pipeline Support
Retail Analytics Provider
Ongoing support for Snowpipe, stream, and task failures including stale streams past their retention window and silent partial-load conditions.
SnowflakeSnowpipeAirflow
S3Snowflake Warehouse Right-Sizing and Credit Consumption Consulting
Global Logistics Provider
Restructuring warehouse sizing, auto-suspend policy, and workload isolation to bring credit consumption in line with the work actually being done.
SnowflakedbtTerraformAirflowSnowflake Clustering and Partition Pruning Assessment
Financial Market Data Provider
Assessment of clustering keys, micro-partition pruning, and table design on large tables where queries had begun scanning most of the data.
SnowflakedbtAirflowTerraform
Airbyte Connector Schema Drift Remediation
Retail Analytics Organization
Diagnosing an Airbyte connection that kept reporting success while the destination table quietly went stale after an upstream schema change.
Airbyte
PostgreSQLSnowflake
KubernetesdbtAirbyte Incremental Sync and Warehouse Cost Support
Subscription Software Provider
Stopping an Airbyte connection that kept dropping out of incremental mode and re-running full refreshes against a large table every night.
AirbytePostgreSQLSnowflake
DebeziumData Pipeline Architecture and Reliability Review
Analytics Platform Team
Mapping an accreted estate of Airflow DAGs, Spark jobs and streaming feeds, and returning a target architecture with a staged, ranked plan.
Apache Airflow
Apache Spark
KafkaSnowflakeSnowflake Iceberg Tables: External Engine Access Rules
Analytics Platform Team
Exposing selected Snowflake-managed Iceberg tables to a second engine through the Horizon Iceberg REST Catalog and setting who can read and write what.
SnowflakeApache IcebergApache Spark
FAQ
Questions about Snowflake migration
Does AceMQ provide Snowflake migration services?
Yes. AceMQ engineers lead the migration with partner Snowflake specialists, in an account you own. We inventory the source, run SnowConvert AI and review its output, move data, run old and new in parallel and cut over in waves with a rollback window. AceMQ is an independent provider, not a Snowflake partner.
Is SnowConvert AI really free, and does it do the whole migration?
Snowflake's FAQ says SnowConvert AI is free and allows full conversion functionality. It does not do the whole migration. Its documentation says differences are flagged for manual or AI-assisted resolution, and for eight of the 15 sources it converts tables and views only. Data movement, validation, the parallel run and Snowflake consumption are separate.
Can you migrate Teradata or Netezza to Snowflake?
Yes, as a scoped program. Teradata conversion covers tables, views, procedures, functions and BTEQ, MLOAD and TPUMP scripts in SnowConvert AI, and Netezza is tables and views only, so stored logic is rebuilt and tested by engineers. The assessment tells us how much of that your estate holds.
How do you control Snowflake cost during the migration?
We set warehouse sizes, auto-suspend and resource monitors in design, schedule large loads, and review credit use at each wave boundary. Parallel run costs money on both platforms, so we state the expected overlap in the plan instead of discovering it on the invoice. We do not promise savings.
Should we move to Snowflake or to Databricks?
It depends on the workloads. We compare both against your jobs, SQL, governance and team skills before you commit, and we run migrations to either. If the answer is to stay where you are, we say so after the assessment.
Let's talk
Scope a Snowflake Migration
Tell us the source platform, the number of tables and jobs, and the date you are working against. We reply within 1 hour and follow with a written assessment plan.
Get in Touch
Talk to a Snowflake Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.