Skip to content
All services
Solution · On-prem → Cloud

On-prem to cloud, wave by wave.

Teradata to BigQuery or Snowflake. Hadoop to Databricks or AWS-native. Informatica to dbt and Airflow. SSIS to dbt and Dagster. Oracle, SQL Server, on-prem PostgreSQL to managed databases. The codified rule library carries the bulk; the dependency mapping is the work.

The shape of this migration

On-prem migrations have less dialect translation than warehouse-to-warehouse pairs and more dependency mapping. The hard work is finding every downstream consumer that nobody documented, every batch script running at 3am that was supposed to be retired three years ago, every reverse-ETL feed pulling data back to an operational system. Discovery does that explicitly — the report enumerates every consumer with a named owner.

What typically breaks first

  • Undocumented batch dependencies. The 3am script that updates a derived table that drives a customer-facing report — nobody on the current team remembers it exists. Discovery finds these via metadata mining and confirms with the platform team.
  • Stored procedures with side effects. Teradata BTEQ, Oracle PL/SQL, SQL Server T-SQL procs that update operational tables alongside analytical ones. These need ownership clarification before they can move.
  • Reverse-ETL feeds. Data flowing from the warehouse back to operational systems (CRM, marketing automation, billing). Discovery enumerates them; the wave plan keeps source + target both writing during parallel run.
  • Legacy BI tools. MicroStrategy, OBIEE, Cognos, SAP BusinessObjects. Few teams want to keep them; most use the migration as the moment to replatform to Looker, Tableau, Power BI, or Sigma. Scope and timeline of the BI re-platform are made explicit in the Discovery report.
  • Network egress timing. Big estates need physical-media ingestion (Snowball / Transfer Appliance / Data Box) for the initial seed plus CDC over a dedicated interconnect for the parallel-run window. Egress timing drives the wave plan.

What you receive at each wave

  • Written inventory: every table, view, stored proc, ETL artifact, BI artifact, downstream consumer with named owners.
  • Dependency map showing batch-flow topology and consumer ownership.
  • Egress plan with physical-media + interconnect provisioning timeline.
  • Translated DDL + DML + ETL artifacts from the rule library + bespoke handlers for the residual.
  • Reconciliation report per wave: row-count parity, schema parity, float-tolerant checksums, query-result diffs on top consumer queries.
  • Parallel-run window: 4-8 weeks of source + target both live with daily diff reports until consumer owners sign off per-dashboard.
  • Cutover document co-signed by your platform lead + ours.

Related reading

How to start

On-prem migrations typically skip the Cost X-Ray and go directly to a Discovery Sprint — the X-Ray is warehouse-scoped, the Discovery Sprint is full-estate-scoped. Book a 30-minute call and we will scope the Discovery against your specific source platforms and target choice.

Questions buyers actually ask

Before you book a call.

What source platforms do you cover? ▾
On the warehouse side: Teradata, Netezza, Hadoop (Hive / HBase / Impala), on-prem Oracle, on-prem SQL Server, on-prem PostgreSQL. On the ETL side: Informatica PowerCenter, SSIS, DataStage, Talend, Pentaho. On the BI side: legacy MicroStrategy, OBIEE, Cognos, SAP BO — typically replatformed to Looker, Tableau, Power BI, or Sigma on the target. Bespoke source pairs (mainframe DB2, Sybase, Vertica) are quoted case by case.
What target options do you support? ▾
AWS (EC2, RDS, Aurora, Redshift, EMR, Glue), GCP (GCE, GKE, BigQuery, Dataproc, Cloud SQL), Azure (VMs, AKS, Synapse, Databricks-on-Azure, Azure SQL), or a managed warehouse on top of any of the three (Snowflake, Databricks, BigQuery). The target choice is part of Discovery — we will tell you when the obvious target is the wrong call.
How long does an on-prem migration realistically take? ▾
Discovery Sprint is 10 business days fixed. Execution depends massively on the estate. A 200-TB Teradata estate with 500 dbt-equivalent transformations and 30 downstream consumers typically executes in 16-24 weeks. A 5-PB Hadoop estate with hundreds of Oozie jobs typically takes 24-40 weeks. The number for your estate is in the Discovery deliverable with the reasoning shown.
How do you handle the parallel-run phase when on-prem and cloud both have to be authoritative? ▾
Wave-based, never big-bang. Each wave: source and target both populated, daily diff reports per table, consumer owners signing off per-dashboard / per-pipeline before the wave cuts over. For audit-regulated estates, the parallel-run window extends to 6-8 weeks per wave. The cutover happens when consumer owners individually sign off, not on a calendar date.
Network egress from on-prem during migration — how is that handled? ▾
Two paths depending on scale. For under ~10 TB, internet egress to cloud over a secure tunnel works. For 10-500 TB, AWS Snowball, GCP Transfer Appliance, or Azure Data Box ships physical media in. For 500 TB+ or ongoing CDC during parallel run, AWS Direct Connect, GCP Partner Interconnect, or Azure ExpressRoute provisioned 1 or 10 Gbps lines. Discovery enumerates the egress plan with the cost and timeline of each option.
What about the on-prem ETL — Informatica or SSIS — does it go to dbt + Airflow? ▾
Usually yes. Informatica mappings become dbt models + Airflow / Dagster DAGs; SSIS packages become dbt models + Airflow tasks. Control flow translates to DAG topology; lookup transforms become dbt models or Airflow sensor patterns. The rule library covers the bulk; complex Informatica reusable transformations and SSIS Script Tasks are bespoke. The Discovery report enumerates every ETL artifact with the chosen path.