Snowflake Migration Services
Snowflake Migration Services for Teradata, Oracle, Redshift, and On-Premises Warehouses
STX Next is a Snowflake Select Services Partner. We migrate Teradata, Oracle, Redshift, SQL Server, Hadoop, Synapse, BigQuery, and on-premise warehouses to production-grade Snowflake, starting with a 1-2 week migration assessment that scopes your full project before you commit.
Why migrate now?
Legacy warehouses become expensive not only because of infrastructure cost, but because of operational drag: slow batch windows, hard-to-change SQL, manual access-control maintenance, fragile ETL jobs, duplicated business logic, and inconsistent reporting definitions.
A Snowflake migration is an opportunity to reduce that drag while moving to a managed, governed, and scalable analytical platform.
Our approach
Tomasz Jędrośka
Head of Data Engineering
We do not treat migration as a simple lift-and-shift. We assess source complexity, convert schemas and SQL, re-engineer legacy procedures and ETL workflows, rebuild data pipelines, and modernize transformation logic into a governed Snowflake and dbt-based analytics engineering layer where appropriate.
Our migration approach combines Snowflake-native capabilities, dbt, CI/CD, data validation, access-control redesign, and parallel-run cutover planning - so the target environment is not only moved to Snowflake, but easier to maintain, govern, scale, and optimize after migration.
Which stack are you migrating from?
Teradata
Proprietary SQL dialect, BTEQ/FastLoad scripts, macros, stored procedures, join indexes, and workload-management assumptions. SnowConvert can accelerate SQL conversion, but procedural logic, performance-critical queries, and operational scripts still require manual review and re-engineering.
Oracle / Oracle Exadata
PL/SQL packages, Oracle-specific functions, materialized views, scheduler jobs, and multi-terabyte schemas. Procedural logic is assessed case by case and may be reworked into Snowflake SQL/Scripting, dbt, Snowpark Python, or orchestration workflows depending on purpose and complexity.
SQL Server / SSIS
T-SQL objects can often be accelerated with conversion tooling, but stored procedures, SQL Server Agent jobs, and SSIS packages need workflow-level redesign. Pipelines are typically rebuilt using a combination of ingestion tools, Snowpipe/COPY INTO, dbt, and orchestration such as Airflow or cloud-native schedulers.
Amazon Redshift
Cloud-to-cloud migration is usually simpler operationally, but distribution keys, sort keys, column encodings, workload management, SQL patterns, and Spectrum/external table usage need remediation for Snowflake’s virtual warehouse model.
Hadoop / Hive
HDFS data movement, Hive metastore dependencies, legacy Spark/Hive jobs, partitioning assumptions, and scheduler dependencies require redesign. Workloads may be rebuilt as dbt models, Snowpark jobs, external Iceberg patterns, or orchestrated pipelines depending on volume, latency, and transformation complexity.
Azure Synapse
Strong Azure ecosystem overlap. Active Directory SSO and Power BI direct-query reconfiguration are the main friction points.
Google BigQuery
SQL dialect differences are manageable. Primary complexity is BI connector reconfiguration and IAM mapping.
On-prem PostgreSQL
PostgreSQL SQL is close to Snowflake SQL. Main work is pipeline rebuild and access control setup. Complexity increases when stored procedures, triggers, CDC, or downstream applications depend on database-specific behavior.
On-prem MySQL / MariaDB
Suitable for consolidation migrations where MySQL is one source among several. Complexity increases when stored procedures, triggers, CDC, or downstream applications depend on database-specific behavior.
What we do not recommend
We do not recommend moving every table, report, stored procedure, and batch job to Snowflake unchanged. Many legacy warehouses contain unused assets, duplicated logic, and historical workarounds. Our migration approach separates what should be migrated, what should be redesigned, and what should be retired.
What Our Snowflake Migration Service Covers
Before any data moves, we assess schema complexity, SQL dialect usage, stored procedures, ETL/ELT pipelines, BI dependencies, data volumes, security model, performance-critical queries, and cost baseline. You receive a migration scope, source-system complexity score, conversion risk register, phased roadmap, validation strategy, and target Snowflake cost model.
This runs as a standalone fixed-scope service before committing to full migration.
Full migration from Teradata, Oracle, SQL Server, Redshift, Hadoop, Azure Synapse, or on-prem databases to Snowflake. Scope covers schema conversion using SnowConvert where applicable, data type mapping, historical data loading via Snowpipe or COPY INTO, and row-level validation against source counts. We run source and target environments in parallel until the validation checklist passes.
Initial migration phases are scoped around data volume, source-system complexity, validation requirements, and downstream dependencies. For many mid-sized environments, the first production-ready domain or representative migration slice can be delivered within several weeks, but full warehouse migration timelines should be confirmed after assessment.
Legacy ETL jobs built for overnight batch processing are redesigned around actual business latency needs.
Some workloads remain batch-based with COPY INTO or Snowpipe; others move to CDC, Kafka connectors, Fivetran, or Snowpipe Streaming where low-latency access is justified. Each pipeline includes schema-change handling, error capture, retries, monitoring, and data quality checks before data reaches the curated layer.
Post-migration, raw data needs a reliable transformation layer to become analytics-ready.
We build Bronze-to-Gold Medallion logic in dbt, covering dimensional modeling, schema tests, source freshness checks, and CI/CD deployment via GitHub Actions or dbt Cloud.
The output is a version-controlled, testable transformation codebase your team can maintain through controlled testing, review, and promotion workflows. This is built into the migration scope, not added later.
Migration is the right time to redesign access control.
We configure Snowflake role hierarchies, ownership models, masking policies for PII, row access policies, secure views, object tagging, data classification patterns, and audit logging. For regulated clients, this includes architectures aligned with GDPR and HIPAA data governance requirements and documentation suitable for internal risk, security, and audit teams.
After cutover, cost surprises are one of the most common migration risks.
We right-size virtual warehouses, configure auto-suspend and resource monitors, define refresh-frequency tiers, review query patterns, consolidate redundant pipelines, and evaluate external or Iceberg tables for high-volume archival data where storage economics justify the added design complexity.
Monthly monitoring is available as a retained engagement with defined scope and response expectations agreed upfront.
Snowflake migration use cases by industry
Replacing Overnight Batch Reporting With Real-Time Data
A financial services firm running regulatory reporting off a Teradata warehouse migrated to Snowflake to eliminate overnight batch latency. Risk models that previously ran on 24-hour-old data were refreshed every 15 minutes post-migration using Snowpipe Streaming. Dynamic column masking and row-level security replaced a custom-built access control layer that had required manual maintenance across every new data domain.
Claims Analytics After an Oracle Migration
An insurance carrier with a decade of claims data in Oracle Exadata migrated to Snowflake to cut infrastructure costs and bring analytics in-house. The migration covered schema re-modeling, multi-terabyte historical data loading, and a full governance rebuild including PII masking and HIPAA-compatible audit trails. Claims processing teams moved from waiting 6 hours for a report refresh to querying live data directly in Tableau.
Consolidating IoT and ERP Data Off a Hadoop Cluster
A manufacturer aggregating IoT sensor data, production line events, and ERP exports from a Hadoop cluster migrated to Snowflake to reduce operational overhead and give plant-level teams access to governed, queryable data. Hive jobs were rebuilt as dbt models running on Snowflake compute, and Kafka connectors replaced nightly file exports from production systems. The team went from managing three separate infrastructure layers to one managed platform.
Unified Data Model After Migrating Off a Custom ETL Stack
A US-based ePharmacy migrated their data platform to Snowflake, replacing brittle custom ETL scripts with a unified data model built on dbt. Product catalog, pricing, and fulfillment data that previously required separate pipelines per business unit was consolidated into a single governed layer, giving analytics teams consistent definitions across reports for the first time.
How this differs from a standard Snowflake implementation
A greenfield Snowflake implementation starts with a target platform design. A migration starts with risk: legacy SQL, stored procedures, ETL dependencies, downstream reports, access models, and business processes that cannot break during cutover. Our migration service focuses on source-to-target mapping, conversion feasibility, parallel run, validation, and controlled cutover - while still using the same Snowflake architecture principles around governance, cost control, dbt, and workload isolation.
Common migration risks we address early
How a Snowflake migration engagement works
Five steps, each with a concrete deliverable. This maps directly to the timeline component on the existing Snowflake LP.
Migration Assessment
We audit your existing warehouse: schema size, stored procedure complexity, downstream dependencies,2 data volumes, and ingestion patterns. You receive a written assessment covering migration scope, a risk register identifying most common migration failure points specific to your stack and a phased project plan with timeline and cost model.
Deliverable: Migration scope document, risk register, phased project plan with cost model.
Architecture Design & Cost Modelling
We design the target Snowflake environment: virtual warehouse layout, storage configuration (Snowflake-managed or external Iceberg tables), role hierarchy, cloud deployment, and ingestion architecture. We produce a cost projection based on available data volumes, query patterns, workload assumptions, and current infrastructure cost baseline.
Deliverable: Target architecture document, cost projection versus current spend, project approval package.
Proof of Concept or Pilot Migration
Before migrating the full warehouse, we run a PoC or pilot on a representative slice of critical data. This validates schema conversion, ingestion approach, query performance, governance design, and BI connectivity. The output is a go/no-go recommendation with concrete migration risks and remediation actions.
Deliverable: Functional PoC or pilot environment, query performance benchmarks, conversion findings, go/no-go report.
Full Migration & Pipeline Build
Full migration executes in two-week Scrum sprints. This covers historical data loading, schema conversion, pipeline rebuild (Snowpipe, Kafka connectors, or Fivetran depending on latency requirements), dbt transformation layer with CI/CD deployment, governance configuration, and BI connector reconfiguration. Source and target environments run in parallel until the cutover validation checklist passes.
Deliverable: Production Snowflake environment, all pipelines live, dbt models with CI/CD, governance configured, source-to-target reconciliation signed off, data-quality test results, query-output comparison, connectors and downstream BI validated.
Cutover, Handoff & Optimization
Cutover is scheduled during a low-activity window with a tested rollback procedure in place. Post-cutover, we deliver runbooks, dbt model documentation, access control documentation, and onboarding sessions for your data team. Optional retained support covers monthly cost optimization, architecture guidance as data volumes grow, and incident response for production pipeline issues.
Deliverable: Runbooks, model documentation, access control documentation, cutover checklist, rollback plan, post-cutover monitoring report, trained internal team. Optional: retained monthly support SLA.
Let's talk
Schedule a chat with Head of Data Engineering and one of our senior engineers to discuss your Snowflake migration needs.
FAQ
How long does a Snowflake migration take?
For a mid-sized warehouse (1–10TB, 200–500 tables, 3–5 downstream BI tools), a full migration typically runs 8–14 weeks from completed assessment to production cutover. STX Next starts with a migration assessment and, where useful, a PoC or pilot migration before committing to a full migration plan. Larger environments with complex stored procedure estates (Teradata, Oracle) or 20+ downstream consumers typically require 12–18 weeks for full migration and pipeline rebuild.
Which source systems does STX Next migrate from?
STX Next migrates from Teradata, Oracle, Oracle Exadata, SQL Server, SSIS, Amazon Redshift, Hadoop (Hive), Azure Synapse, Google BigQuery, on-prem PostgreSQL, and MySQL/MariaDB. Migration complexity varies by source stack. Teradata and Oracle carry the highest complexity due to proprietary SQL dialects and procedural code that requires manual re-engineering alongside automated conversion tools. PostgreSQL, MySQL, and Redshift migrations are often less complex than Teradata or Oracle migrations, but complexity increases when stored procedures, triggers, CDC, downstream applications, or platform-specific performance patterns are involved.
Does STX Next handle SQL conversion from Oracle PL/SQL or Teradata BTEQ?
Yes. SQL and procedural code conversion is part of the standard migration scope. STX Next uses SnowConvert for automated dialect conversion where applicable and handles manual re-engineering for stored procedures, macros, and proprietary functions that automation cannot cover. The migration assessment maps all procedural code and flags items that require manual attention before the full migration scope is agreed.
Can you migrate from Redshift or BigQuery to Snowflake without downtime?
In many cases, we can design a low-downtime migration by running source and target environments in parallel, keeping incremental loads active, validating query outputs, and switching downstream consumers only after the validation checklist passes. Whether true zero-downtime cutover is realistic depends on source-system architecture, data freshness requirements, CDC availability, and downstream application dependencies.
What does Snowflake migration cost?
Migration cost depends on source stack complexity, data volumes, the number of downstream systems, and whether pipeline modernization and dbt transformation layer build are in scope. STX Next produces a cost model during the Architecture Design phase (Step 2), based on actual data volumes and query patterns, compared directly against current infrastructure costs. A fixed-scope Migration Readiness Assessment (1–2 weeks) is available before committing to a full engagement.
Is STX Next a certified Snowflake partner?
Yes. STX Next is a Snowflake Select Services Partner with delivery experience across financial services, insurance, manufacturing, healthcare, and eCommerce. STX Next is also an AWS Advanced Tier Services Partner and holds ISO/IEC 27001 certification for information security management.
How does STX Next handle GDPR and HIPAA compliance during a Snowflake migration?
For regulated clients, governance configuration is part of the migration scope. STX Next configures Snowflake role hierarchies, masking policies for PII, row access policies, secure views, object tagging, data classification patterns, and audit logging. The target architecture is designed to align with GDPR and HIPAA data governance requirements, with documentation suitable for internal risk, security, and audit teams.
