How I Replaced Legacy SSIS with Real-Time GCP Pipelines

How I Replaced Legacy SSIS with Real-Time Data Pipelines (and Saved Costs!)

A few years into working with SQL Server Integration Services (SSIS), I hit the same wall a lot of data teams eventually hit: nightly batch jobs that took longer every month, a server that needed constant babysitting, and a growing list of "just run it again manually" incidents. This is the story of moving that pipeline to a GCP-native setup — what worked, what I underestimated, and what it actually saved.

๐Ÿ“˜ The Starting Point

The original setup was a fairly typical on-prem pattern:

Source SQL Server → SSIS nightly ETL job → Data Warehouse (on-prem)

It worked — until data volume grew. The nightly job window kept creeping later, sometimes bleeding into business hours, and every schema change at the source meant manually re-mapping columns in the SSIS designer.

๐Ÿ”ง The Migration Path

Rather than a big-bang rewrite, I moved piece by piece:

  1. Google Cloud Datastream replaced the extraction step — reading change events directly from the source database's transaction log instead of a nightly full pull (this is Change Data Capture, which I've written about separately).
  2. BigQuery replaced the on-prem warehouse — raw CDC events landed in staging tables, then got merged into analytics tables using scheduled MERGE statements.
  3. Python-based Cloud Functions replaced the custom transform logic that used to live inside SSIS packages — smaller, independently deployable, and version-controlled in Git instead of buried in an SSIS project file.

๐ŸŽฏ The Real Wins

  • From nightly to near-real-time — dashboards that used to show yesterday's numbers now update within minutes of a change happening at the source.
  • No more manual re-runs — Datastream and BigQuery scheduled queries handle retries and backfills automatically, instead of someone needing to manually re-trigger an SSIS job at 6am.
  • Lower total cost — no more maintaining a dedicated SSIS/SQL Server license and server just for the transform layer; BigQuery's on-demand pricing meant we only paid for the compute the transforms actually used.

⚠️ What I Underestimated

  • Schema changes still needed real handling — moving to CDC didn't make schema drift disappear, it just changed how it showed up (see my post on schema evolution). I had to build explicit validation I hadn't needed with SSIS's rigid, manually-mapped structure.
  • Cost visibility took effort — BigQuery's pay-per-query model is cheaper overall, but without partitioning and clustering set up correctly early on, a few early "just testing" queries scanned entire tables and produced a surprising bill. Getting the partitioning strategy right from day one would've saved some early pain.
  • Team ramp-up time — SSIS's drag-and-drop designer was, for better or worse, approachable for less SQL-heavy team members. Moving to a code-first (SQL + Python) pipeline meant investing in some knowledge transfer that I hadn't fully budgeted for.

๐Ÿงญ Would I Do It Again?

Yes — but I'd sequence it differently. I'd set up BigQuery partitioning and cost monitoring before the first real workload landed, not after the first surprising invoice. And I'd document the CDC event handling and schema validation rules earlier, rather than discovering the gaps live.

๐Ÿ”— Related Posts

  • Change Data Capture (CDC): Real-Life Use Cases and Pitfalls
  • Optimizing BigQuery Costs with Partitioning & Clustering
  • ETL vs ELT: Choosing the Right Strategy for Your Workflow

Comments

Popular Posts

BigQuery MERGE Statement – Explained

LRT Masjid Jamek-Bandaraya

Kavalkaran - MGR Tamil movie Part 4