Fivetran migration guide

Move off Fivetran without breaking a model.

What changes in your warehouse, what stays the same, and every step from a mapped plan to cutover. Our engineers do the work with you, and Fivetran keeps running until the numbers match.

Weld · migration plan
Example plan · Fivetran connectors
2/5 RECONCILED
  • PostgreSQL logo
    PostgreSQL
    CDC · 42 tables
    Reconciled
  • Salesforce logo
    Salesforce
    18 objects
    Reconciled
  • HubSpot logo
    HubSpot
    Row counts
    Comparing
  • Stripe logo
    Stripe
    Since 2019
    Full history
  • Shopify logo
    Shopify
    Queued
    Mapped
Snowflake logo
Snowflake
Same schemas · dbt runs after each sync
Typical move, depending on scope
2 to 6weeks

Typical move, depending on scope

Migration work, done by Weld's engineers
Free

Migration work, done by Weld's engineers

As far back as each source's API allows
Fullhistory

As far back as each source's API allows

Monthly SLA, with service credits
99.9%uptime

Monthly SLA, with service credits

An animation of the migration. Your apps and databases sync through Fivetran while Weld's migration script maps every connector, then both run in parallel into the same warehouse tables until the row counts match, and finally Fivetran is switched off while Weld keeps syncing and orchestrates the dbt run after each sync. The warehouse cycles through Snowflake, BigQuery, Databricks, Redshift, Postgres, ClickHouse and MotherDuck.

Process

Five steps, in order.
Fivetran runs until the numbers match.

Each step ends in something you can check before the next one starts.

  1. 01

    Map what you run

    Our migration script lists every Fivetran connector, schema and sync frequency you run, maps each to its Weld connector, and finds the dbt models that read from them. Anything Weld does not cover yet is named up front, before any work starts.

    You getConnector map and dbt impact list
  2. 02

    Rebuild with full history

    Weld syncs each source from the beginning, so all the history the source still returns is in place before you rely on it. Destination schemas stay compatible with Fivetran's, so your models read the same tables they read today. Older data only Fivetran holds is kept in your warehouse as an archive.

    You getSource history in your warehouse
  3. 03

    Run both and compare

    Fivetran and Weld load in parallel while we compare row counts and the metrics your team reports on, table by table, until they match.

    You getRow counts that match
  4. 04

    Swap the metadata columns

    Models that use Fivetran's own columns get a small change each (see the mapping below). Weld then runs your dbt project or triggers your dbt Cloud jobs after every sync.

    You getUpdated dbt models
  5. 05

    Cut over

    Dashboards and reports follow the dbt models. You pause the Fivetran connectors, and cancel the contract before it renews.

    You getFivetran paused, then cancelled
In your warehouse

What changes, and what doesn't.
A few lines per model, known up front.

Weld writes the tables and columns your models already read. What changes is Fivetran's own metadata: the plan lists every model that uses it, so each edit is known before the parallel run starts.

models/staging/stg_shopify__orders.sql
1 select
2 id,
3 customer_id,
4 total_price,
5- _fivetran_synced as synced_at
6+ _weld_synced as synced_at
7 from {{ source('shopify', 'orders') }}
8-where not _fivetran_deleted
9+where _weld_deleted_at is null
2 LINES CHANGEDSAME TABLE, SAME COLUMNS
  • Source tables and columnsReverse compatible

    Weld writes the tables and columns your dbt models, dashboards and reports already read, so they keep working.

  • _fivetran_synced_weld_synced

    When the row was last synced. Rename it in the models that order or filter on it.

  • _fivetran_deleted (true/false)_weld_deleted_at (timestamp)

    With Capture deletes on, each full sync keeps the rows the source no longer returns and stamps them with the time that sync found them missing, so deletes show up at the next full sync rather than on every incremental one. Filter live rows with _weld_deleted_at IS NULL. Supported on BigQuery, Snowflake, Redshift, Postgres, SQL Server, MotherDuck and Iceberg; not yet on ClickHouse, Databricks or S3.

  • History mode tables<table>__history

    Same schema as the main table, one row per previous version, recorded from the moment it is turned on. A source cannot replay versions Fivetran already recorded, so those tables are kept as an archive.

  • Historical dataSource history

    The first sync replicates as much history as each source's API returns. Some APIs cap it, Facebook Ads at three years for example, so data older than that stays in the archived Fivetran tables.

Details in the docs: Capture deletes, History tables, Weld managed fields.

What we check

The details that stall migrations.
Covered in the plan, before the parallel run.

  • Databases with CDC

    PostgreSQL, MySQL, MariaDB, MongoDB and SQL Server replicate with log based change data capture, as an add-on. We check replication settings and permissions on each database before the first sync.

    Read the docs
  • Moving warehouse too

    A Weld sync can load into more than one destination, so if you are moving warehouse at the same time, the old one and the new one stay in step until you switch.

  • Column types

    Arrays, enums, JSON and custom types can land differently from tool to tool. The parallel run compares them column by column on the tables your models read.

  • Deletes and history

    For each table we agree whether you need deleted rows kept and past versions recorded, and turn on Capture deletes or history tables to match what your models expect.

  • Sync frequency

    Each source's Fivetran schedule is checked against Weld's, which syncs as often as every 5 minutes. A source that runs faster on Fivetran today is flagged in the plan, and dbt runs after the syncs it depends on.

  • Connectors Weld lacks

    Named in the plan, not discovered at cutover. For a source outside the catalogue, a custom connector you host can feed any API into the same syncs.

    Read the docs
Cost and timing

What you pay while you move.

The migration work is done by Weld's engineers at no cost. The Weld plan runs from the first sync, so during the parallel run you pay for both until you cancel Fivetran. Plan the cutover to land before your Fivetran renewal: a move typically takes 2 to 6 weeks.

Weld commits to 99.9% uptime per calendar month, with service credits. See the service level agreement and security.

Fivetran
Billed as today
Weld plan
Billed from the first sync
Migration work
Weld engineers, free
  • Parallel run: both billed
  • Cutover (dashed line): Fivetran off
  • Renewal (grey line): cancel before it
Next step

Get a plan for your setup.
Every connector mapped, with your Weld price.

Comparing first? Fivetran vs Weld, row by row.