SyncSpur | Cutting Over from Stitch or Airbyte to Fivetran Without Paying for History Twice

Every ELT migration starts the same way. The current tool works, mostly, but someone is tired of babysitting it — a connector that silently stops on schema changes, a Kubernetes deployment nobody wants to own, or a vendor whose Salesforce connector is three API versions behind. Fivetran is the destination. The question is how to get there without breaking the dashboards that finance looks at every Monday morning, and without a surprise invoice from an initial sync that re-reads a billion rows.

This is the runbook we use on migration engagements. It assumes you are moving one source at a time, which you should be.

0. Inventory before you touch anything

Make a spreadsheet — genuinely, a spreadsheet — with one row per pipeline in the old tool. Capture:

Source system and the exact tables/streams selected.
Destination schema and table names.
Sync frequency and sync mode (full refresh, incremental append, incremental dedupe).
Approximate row counts and monthly change volume per table.
Downstream consumers: dbt models, BI dashboards, reverse ETL syncs, anything reading the raw schema directly.

That last column is the one that decides your migration order. A source with a single dbt model behind it is a good first cutover. The source that feeds the executive dashboard goes last, after you have learned the sharp edges on something cheap.

1. Expect the schema to be different, and plan for it

The single biggest misconception in these projects is that Fivetran will land data the same shape your old tool did. It will not, and pretending otherwise is how you end up rewriting forty dbt models under time pressure.

Concrete differences you will hit:

Naming. Fivetran normalises to lowercase snake_case and truncates or de-duplicates names that collide. CustomerID becomes customer_id.
Metadata columns. Fivetran adds _fivetran_synced, _fivetran_deleted and, on some connectors, _fivetran_id. Airbyte's _airbyte_ab_id / _airbyte_emitted_at disappear. Anything ordering by an Airbyte metadata column needs rewriting.
Soft deletes. Fivetran marks deleted source rows with _fivetran_deleted = TRUE rather than removing them (unless you enable hard deletes on supported connectors). If your old pipeline was append-only, your row counts will not match and your models may need a WHERE NOT _fivetran_deleted filter.
Unpacking. Some connectors that Airbyte lands as a raw JSON blob arrive in Fivetran as typed columns, or as separate child tables. Nested API objects are the usual culprit.

The cheap way to discover all of this is to sync one small source into a scratch schema first and diff it against the old output. Do that before you write a migration plan for thirty tables.

2. Land Fivetran in a parallel schema, not on top of the old one

Never point Fivetran at the schema your old tool is writing to. Two writers on one table is a data-corruption incident waiting for a Friday afternoon.

Give Fivetran its own destination schema — fivetran_salesforce alongside the existing stitch_salesforce, for example. In the connection setup, the destination schema is set at creation time and is painful to change afterwards, so decide the naming convention up front and apply it everywhere:

<source_system>            e.g. salesforce
<source_system>_<instance> e.g. postgres_orders_prod

Once cutover is done you can rename the old schema out of the way and, if you want the clean name, use views rather than moving data.

3. Control the initial sync bill

Fivetran charges on monthly active rows. The initial sync counts every row it reads — historical rows included. On a source with hundreds of millions of rows this is the most expensive month of the pipeline's life, and it is largely controllable.

Three levers, in order of impact:

Select only the tables and columns you actually use. Come back to that inventory spreadsheet. In most migrations 30–50% of the tables selected in the old tool have no downstream consumer at all; they were selected because someone clicked select all in 2021. Deselect them in the Fivetran schema tab before the first sync, not after.

Set a historical sync window where the connector supports it. Many SaaS connectors let you choose how far back to pull on the first sync. If your dashboards only look at 24 months, do not pull nine years of closed opportunities.

Run the first sync early in your billing month so that if you need to reconfigure and re-sync, the re-read falls inside the same MAR month rather than starting a fresh one. Rows are counted once per connection per month, so a second sync of the same rows in the same month is free; the same sync on the 1st of the next month is not.

One thing that does not help: pausing the connection part-way through the initial sync. Whatever it has already read is already counted. If you are unsure of the volume, ask your account team for a MAR estimate on the source, or test with a single high-volume table first. Guessing here is expensive.

4. Run both pipelines in parallel

For at least one full business cycle — a week for daily reporting, a month if anything closes monthly — both tools write to their own schemas and you compare. Do not skip this step for the source that matters most.

A reconciliation query that has caught real problems for us:

with old_side as (
  select date_trunc('day', created_at) as d,
         count(*)          as rows_old,
         sum(amount)       as amount_old
  from stitch_salesforce.opportunity
  group by 1
),
new_side as (
  select date_trunc('day', created_at) as d,
         count(*)          as rows_new,
         sum(amount)       as amount_new
  from fivetran_salesforce.opportunity
  where not _fivetran_deleted
  group by 1
)
select coalesce(o.d, n.d) as day,
       rows_old, rows_new, rows_new - rows_old      as row_delta,
       amount_old, amount_new, amount_new - amount_old as amount_delta
from old_side o
full outer join new_side n on o.d = n.d
where coalesce(rows_old,0)  <> coalesce(rows_new,0)
   or coalesce(amount_old,0) <> coalesce(amount_new,0)
order by day desc;

Run it daily during the parallel window. Interpreting the output:

Deltas only on the most recent day are almost always sync-timing, not a defect. Compare at the same watermark.
A constant offset across all history usually means the old tool was missing deletes, or was append-only and holds duplicate versions of updated rows. Fivetran is normally the correct side here.
Deltas concentrated in old history point at a historical sync window difference — expected if you deliberately shortened it in step 3.
Random scattered deltas are the ones to chase. Look for a filter in the old pipeline nobody documented.

Also reconcile a column-level sample, not just counts. Type coercion differences (numeric precision, timestamps landing as UTC versus local) do not show up in a row count and absolutely show up in a revenue figure.

5. Repoint the models, then the dashboards

With the diffs explained, switch consumers over. In dbt, the clean move is to change only your source definitions and staging models, so nothing downstream needs editing:

sources:
  - name: salesforce
    schema: fivetran_salesforce   # was stitch_salesforce
    tables:
      - name: opportunity
      - name: account

In the staging model, handle the metadata differences in one place:

select
    id            as opportunity_id,
    account_id,
    amount,
    created_at,
    _fivetran_synced as loaded_at
from {{ source('salesforce', 'opportunity') }}
where not _fivetran_deleted

Build into a staging environment, run your tests, and diff the final marts against production before you promote. If your warehouse supports zero-copy clones, clone production and build into the clone — it is the fastest way to prove that nothing moved.

BI tools come after the models are proven. If any dashboard queries the raw schema directly, that is the moment to fix it, not to recreate the sin against the new schema.

6. Decommission deliberately

Do not delete the old pipeline the day you cut over. Pause it, keep the old schema readable for 30 days, and only then drop it. Two things go wrong in week three: someone finds a report you missed, or a reconciliation question comes up that needs the old data to answer.

When you do decommission, close the loop properly:

Cancel or downgrade the old tool's subscription — a surprising number of teams pay for both for a year.
Revoke the old tool's credentials in the source systems. A paused Airbyte deployment with live Salesforce OAuth tokens is a security finding.
Remove the old schema's grants, then drop it.
Move the new connection into your Terraform configuration so it is captured as code rather than clicked.

Cutover checklist

Inventory pipelines, tables, consumers, row volumes.
Sync one small source to a scratch schema; document schema differences.
Prune tables and columns nobody consumes.
Create connections in parallel schemas, early in the billing month, with a considered historical window.
Run both tools for a full business cycle; reconcile counts and sampled values daily.
Explain every remaining delta — never wave one through.
Repoint dbt sources; validate marts in a clone or staging environment.
Repoint BI; retire direct raw-schema queries.
Pause the old pipeline, wait 30 days, then revoke credentials and drop schemas.
Codify the new connections in Terraform.

Where this usually goes wrong

The failures we get called into are rarely technical. They are migrations run as a big-bang weekend cutover across twenty sources at once, with no parallel window, discovered on Monday when a number in a board deck moved by 4% and nobody can say which pipeline caused it. One source at a time is slower on paper and much faster in practice.

If you are planning a move onto Fivetran and want the schema mapping, MAR modelling and reconciliation done by people who have run it before, our migration to the Fivetran platform service covers exactly this, and Fivetran cost optimization covers keeping the bill sane once you are live. Get in touch with your source list and we will tell you where the expensive surprises are.