Almost every data migration we run reduces to the same sentence: "We're on a legacy tool, the license and infrastructure cost keeps climbing, only one person understands it, and we want a modern stack that anyone who writes SQL can maintain."
The specifics change — ODI, Oracle, Informatica, Talend, Postgres, Teradata, SSIS — but the destination rarely does: a serverless warehouse (BigQuery or Snowflake), managed ingestion (Fivetran / Airbyte / Datastream), and dbt for version-controlled, tested transformations.
This page is the map. The shared method first, then the specific guides.
Two kinds of migration hiding in one request
People say "migrate our data stack" to mean two genuinely different projects:
A. Replacing an ETL tool — moving off ODI, Informatica, Talend, or SSIS. The data may already be in a decent warehouse; what you're really replacing is the transformation and orchestration layer. These almost always land on dbt + an orchestrator, and the work is converting mappings/jobs into SQL models.
B. Replacing a warehouse — moving off Oracle, Teradata, Netezza, Redshift, or an over-loaded Postgres. Here the work is schema conversion, data-type mapping, moving the data, and rebuilding the procedural logic. These land on BigQuery or Snowflake.
Most real migrations are a bit of both. Knowing which one dominates your project tells you where the effort — and the risk — actually sits.
The shared method
Whichever migration you're running, the sequence is the same. It's the part that doesn't fit in a keyword, and it's the part that determines whether the project succeeds.
-
Audit before you build. Catalogue every job, mapping, or table: sources, targets, transformations, schedule, and — the column everyone skips — who actually consumes the output. A meaningful share of any legacy estate is orphaned: it runs on schedule, burns compute, and feeds a report nobody's opened in months. Retire it. Never migrate dead weight.
-
Separate extraction from transformation. Legacy tools bundle extract, transform, and load into one job. The modern stack splits them: managed connectors extract, the warehouse stores, dbt transforms. dbt does not extract — internalizing that early prevents the most common design mistake.
-
Rebuild logic in layers, don't port 1:1. Staging models clean and cast; mart models join and aggregate. Visual mappings and stored procedures often hide join logic that only works by accident — rewriting in SQL surfaces the assumptions you didn't know you had.
-
Make testing the default. Legacy tools had quality checks nobody enforced.
dbt testruns in CI and blocks merges on failure. Teams catch more data-quality bugs in the first week than the old tool caught in a year. -
Parallel-validate — always. Run both systems side by side for two to four weeks. Compare row counts, aggregate values to the cent, and the same dashboards on both. Cut over only when the numbers match for a full week. This is the step teams skip to hit a deadline, and the one that costs the most when skipped.
-
Cut over, then decommission. Repoint BI, retire the old jobs, and only then turn off the servers and licenses. The savings are real — but they land at decommission, not at go-live.
The guides
Replacing an ETL tool → dbt
- Talend → dbt — the original playbook. Also: Talend vs dbt and what nobody tells you first.
- Informatica → dbt — PowerCenter/IICS mappings, mapplets, Update Strategy, and pushdown optimization mapped to dbt.
- ODI → GCP — see below (it's both an ETL-tool and a platform move).
Replacing a warehouse
- Oracle → Snowflake — data-type traps, PL/SQL rebuild, CDC, parallel validation.
- Oracle → BigQuery — the serverless destination, partitioning instead of indexes, Datastream CDC.
- Postgres → BigQuery — splitting analytics off an over-loaded transactional database.
Platform migration (both at once)
- ODI → GCP — Oracle Data Integrator to a native Google Cloud stack: Knowledge Modules to dbt, agents to Cloud Composer, Oracle warehouse to BigQuery.
Coming to this hub
The same method extends to the rest of the legacy landscape — the guides we're adding next:
- Teradata → Snowflake / BigQuery
- Redshift → Snowflake / BigQuery
- SQL Server → Snowflake / BigQuery
- SSIS → dbt
If you're facing one of these before its guide lands, we've almost certainly run it — ask us directly.
The honest part
The hardest part of any of these migrations isn't technical. It's getting the team to stop thinking in the old medium — visual mappings, stored procedures, a tuned Oracle box — and start thinking in SQL layers under version control. The knowledge transfers. The specialist muscle memory becomes SQL. The tooling gets out of the way, and the person who built the old pipeline is usually the best person to rebuild it — once they see the new shape.
We've run these across Snowflake, BigQuery, and Databricks — from 20-job estates to 200+.
Facing a migration off a legacy stack? Book a discovery call and we'll tell you which of the two migrations you're actually running, and what it looks like for your tools.