Migrate from Fivetran to Airbyte

Migrate from Fivetran to Airbyte: what the move involves

A move from Fivetran to self-hosted Airbyte usually starts with a renewal, MAR cost pressure, or a residency requirement that makes a vendor-run pipeline hard to keep. The work is typically carried out by the data platform team, sometimes with an implementation partner, and it consists of four pieces: matching each Fivetran connector to an Airbyte connector, reconciling destination schemas and table names so existing dbt models keep resolving, planning the initial resyncs, and running both systems in parallel until the downstream results agree. The effort is driven less by the number of pipelines than by the number of connectors that have no direct equivalent and by how many dbt models, exposures and dashboards depend on the exact names and column types Fivetran produced today.

Before any connector is rebuilt, confirm the licensing position with your legal team. Airbyte Core, the platform, is under the Elastic License 2.0, while Airbyte's connectors and Connector Development Kit are under the MIT license. The Airbyte license FAQ sets out what ELv2 allows for internal operations and client work, and what it does not allow, such as offering Airbyte to third parties as a hosted ELT service. Connector availability, version support and specific source behavior should be checked against the Airbyte connector catalog in your own environment, not assumed from the Fivetran list. Connectors that are missing or behave differently in Airbyte need a decision on whether to build a custom connector, keep a different ingestion path, or accept a change.

Self-hosting moves the operating work onto your team. Someone must own the Kubernetes cluster and the Helm deployment described in the Airbyte deployment guide, size and scale sync workers, handle upgrades, manage secrets and credentials for each source, monitor failed syncs, and respond to schema changes at the source. Fivetran's per-connection billing and managed maintenance are replaced by compute, storage and engineering time. Ask for a written scope that lists each connector, its owner, the target schema, the cutover date and the rollback plan, and confirm who will be on call for pipeline failures during the parallel run.

Which Fivetran capabilities map cleanly to Airbyte

This table sorts the main Fivetran capabilities into clean matches, items that need rework, and likely gaps when moving to self-hosted Airbyte. Read each row as a planning question: a clean match still needs a connector check for your specific sources, and a rework or gap row needs a decision before cutover. Connector coverage is the first thing to verify, because Airbyte's catalog does not automatically include every connector Fivetran manages.

Fivetran capability	Airbyte equivalent	Status	What to confirm or change
Managed connectors for common SaaS and database sources	Airbyte source connectors from its catalog	Needs check	Confirm each source and version in Airbyte's catalog, and test authentication and API limits in your environment
Fivetran-managed connectors with no catalog match	No direct equivalent guaranteed	Gap	Decide between a custom connector built with the Airbyte Connector Development Kit, another tool, or keeping that source on Fivetran during transition
Destination loading into warehouses	Airbyte destination connectors for your warehouse or lake	Needs check	Confirm the destination connector supports the load mode you need and test write permissions on a non-production schema
Schema naming and table layout	Airbyte namespace and stream naming settings	Needs rework	Fivetran table and column names will often differ, so build a mapping layer or update dbt sources and staging models
Column and schema change handling	Schema change detection and sync settings in Airbyte	Needs check	Review how new, renamed or dropped columns propagate to your destination before enabling automatic changes
Incremental sync with cursors	Incremental modes per stream, where the source supports them	Needs check	Confirm cursor fields and deduplication behavior per stream, then reconcile row counts against Fivetran output
Historical resync on first run	Initial full sync in Airbyte	Needs rework	Plan the first load window and compute impact on the source system, and avoid duplicate tables during parallel runs
Downstream dbt models and BI references	Models and sources you maintain	Needs rework	Repoint dbt sources to the new table names and run tests before any production switch

What to export and rebuild from Fivetran

Leaving Fivetran is mostly a rebuild exercise. The configuration you can export gives you a plan, but historical data, sync state and downstream jobs do not move on their own. Each card below covers one item to capture before you cut over to self-hosted Airbyte.

Connection and destination configuration

Export your connection, destination and schema settings through Fivetran's REST API or the Terraform provider, and keep the snapshot in version control as the inventory for your Airbyte connections. Confirm which fields each export includes, since credentials and some secrets are typically returned masked or omitted. Before committing, remove API keys, tokens, passwords and account identifiers, and store secrets in your secrets manager. Use the snapshot to list every source, destination and sync frequency you must recreate.

Schema and table naming

Fivetran writes tables and columns with its own naming conventions and adds system columns for sync metadata. Record the exact schema names, table names and column names in each destination, because dbt models, BI extracts and grants reference them directly. Airbyte uses its own normalization and naming rules, so test each source against the destination before cutover. Confirm whether your Airbyte destination setting reproduces Fivetran's names or whether dbt sources need renaming.

Historical data and initial resyncs

Decide which historical data stays in the warehouse from Fivetran's tables and which must be backfilled by Airbyte. A full initial sync from the source can be slow and can put load on production systems, so plan the window and the source limits in advance. Keep Fivetran's historical tables untouched until the new pipelines pass your row count checks. Ask Airbyte's documentation which sync modes and state behavior apply to each connector you plan to use.

Incremental sync state and cursors

Fivetran tracks its own replication state, cursors and deleted-row handling for each table. Airbyte keeps separate state for each connection, so it does not inherit Fivetran's position in a source. Record the last synced cursor or timestamp for each table before cutover, and identify tables where a full resync is safer than resuming. Confirm how each connector handles hard deletes and late-arriving records, because gaps there show up later as wrong totals in downstream models.

Sync schedules and alerts

Fivetran schedules syncs and sends failure notifications through its own settings, which the configuration export may or may not capture in full. Document each sync frequency, timezone assumption and notification recipient, then recreate them in your orchestrator or Airbyte's scheduling. Route failure alerts into the channels your on-call team already watches. Confirm during parallel running that a deliberately broken connection produces an alert before you trust the new setup.

Downstream dbt, orchestrators and access

List every dbt source, model that reads raw tables, orchestrator DAG, reverse ETL job, and BI dataset that depends on Fivetran's output. Map each dependency to its new Airbyte table, and note the warehouse roles and grants that let those jobs read the data. Trigger dependent jobs only after the first successful Airbyte sync, and rerun dbt source tests during parallel running. Missing one dependency is the most common cause of a broken report after cutover.

The migration sequence from inventory to decommission

This sequence moves each Fivetran connection to a self-hosted Airbyte connection in controlled stages, so every cutover is backed by reconciled data and a documented rollback. Each step produces a named artifact that the next step depends on.

Inventory connections and downstream dependencies
Export the connection, destination and schema configuration from Fivetran, then list every destination table and the dbt models, dashboards, reverse ETL jobs and applications that read from it. Record each sync schedule, historical load depth and the owner of each connection. The output is a connector inventory with one row per connection and a dependency map showing which downstream assets break if a table name or column type changes. The step is done when the data platform owner and each downstream team have signed off on the inventory.
Map each connector to an Airbyte equivalent
For every Fivetran connector, confirm whether Airbyte offers a source connector with the same object coverage, authentication method and incremental cursor support. Mark each mapping as direct, partial or no match, and note any object that must be rebuilt as a custom connector using the Connector Development Kit. Confirm current coverage against Airbyte's connector catalog rather than relying on the source name alone. The output is a connector map that records the Airbyte connector version, the sync mode and the gaps that need a decision.
Deploy self-hosted Airbyte in your environment
Install Airbyte into your own Kubernetes cluster using the Helm chart and the documented values, with secrets held in your existing secrets store and the destination credentials scoped to the write schemas only. Configure logging, backups of the Airbyte configuration database and access control before any source is connected. The step is done when a test connection to each destination succeeds and a restore of the configuration backup has been rehearsed. Confirm the deployment model and supported Kubernetes versions with Airbyte's current deployment guide.
Pilot with one or two low-risk connectors
Choose one or two connectors whose tables have few downstream consumers and a clear source of truth, then run the Airbyte sync into a scratch schema alongside the existing Fivetran output. Compare the initial historical load and several incremental runs against Fivetran's tables, checking column types, primary keys, deleted-row handling and timestamp time zones. The output is a pilot report listing every difference, each with a fix or an accepted deviation. The pilot is complete when the data owner has accepted the differences in writing.
Run both pipelines in parallel with separate schemas
Keep Fivetran writing to its existing schemas while Airbyte writes the same connectors to parallel schemas with a clear suffix or prefix. Point a copy of the dbt project at the Airbyte schemas, using a source name that can be switched by a single variable, so the models run unchanged against either input. Monitor sync failures, API rate limits and warehouse load over a full business cycle. The output is a parallel run log and a reconciled schema diff that lists every table, column, name and type difference that dbt models must absorb.
Reconcile row counts, freshness and transformed outputs
Compare row counts, primary key uniqueness, null rates on key columns and the latest timestamp per table between the two schemas, then compare the outputs of the key downstream models and reports. Set agreed tolerances for expected differences such as in-flight records at sync time. Document any discrepancy and its root cause, including Fivetran-specific columns that Airbyte names differently. The output is a reconciliation report signed off by the data owner and the owners of each dependent report.
Cut over with a signed-off checklist
Switch the production dbt sources and any downstream consumers to the Airbyte schemas in a single controlled change, and pause the Fivetran connections rather than deleting them. Keep the Fivetran schemas intact so you can point consumers back if a defect appears. The cutover checklist should record the change window, the rollback steps, the people on call and the monitoring alerts that confirm success. The output is a signed-off cutover checklist and a dated record of the switch.
Decommission Fivetran after the retention period
After the agreed retention period in which the paused Fivetran connections remain available for rollback, delete the connections, revoke the Fivetran service credentials and remove the destination write grants. Confirm the final invoice and contract terms with Fivetran's account team, and export a final copy of the configuration for your records. The step is done when the connections no longer appear in Fivetran, access is revoked and the decommission record is filed with the data platform documentation. Set the retention period with your own risk owners, since no duration is prescribed here.

What drives the cost and duration of the move

This table lists the factors that change how much effort and time a Fivetran to Airbyte move takes, and how each one can be kept under control. Read it as a checklist for scoping: the license cost is zero under the open Core edition, so most of the spend comes from infrastructure, implementation and the work of keeping pipelines running. Use it to frame the questions you ask in a written scope.

Driver	Why it changes cost or effort	How to keep it down
Number of connections	Each connection needs a matching Airbyte connector, source credentials, destination mapping and validation, so effort scales with the count.	Group connections by source type, migrate low-risk ones first and retire unused connections before the move.
Source API complexity	Sources with rate limits, nested objects or inconsistent cursors take longer to configure and may need custom connector work.	Check each source against the Airbyte connector catalog early and flag gaps for a written decision.
Historical volume and initial resync	Full historical loads consume source API quota, worker time and destination compute, and can run for days on large tables.	Plan resync windows off-peak, throttle large tables and confirm which history must be carried over.
dbt model count and naming dependencies	Every downstream model that references a renamed table or column must be found and repaired, which drives testing time.	Inventory references in the dbt project, map old and new names in a table and keep names stable where possible.
Destination schema changes	Airbyte normalization can create different table and column names or types than Fivetran produced, which breaks reports and models.	Compare schemas on a sample of rows and agree naming rules before the first full sync.
Kubernetes and Helm operating skill	Airbyte is built for Kubernetes and is documented for Helm, so a team without this skill spends more time on setup, upgrades and troubleshooting.	Confirm in-house skill or budget for outside help, and test upgrades in a non-production cluster first.
Length of the parallel run	Running Fivetran and Airbyte side by side doubles source load and pipeline cost until row counts and models are reconciled.	Set exit criteria for reconciliation and keep the parallel period only as long as those criteria require.
On-call and ongoing operations	Self-hosted pipelines need alerting, failure handling and connector upgrades, which are paid staff time that recurs after cutover.	Ask for runbooks, alert thresholds and a named owner for each pipeline before cutover.

How the move differs by team size and starting point

A small team with a handful of sources and one warehouse usually has the simplest migration, but it also carries the most work per connector because nobody else owns the pipelines. Connector matching is largely a manual exercise: each Fivetran connection is compared with an Airbyte connector for the same source, and the team checks the fields and tables it actually reads rather than every object the source exposes. Deployment is normally a single machine, where abctl or Docker is the documented route for a local or single-host install.

Connector matching: list only the connections that feed dbt models or dashboards, and retire anything unused instead of recreating it.
Deployment: start with abctl or Docker on one host, and move to Helm only when the install must be reproducible or shared.
Parallel run: keep Fivetran active for one reporting cycle and compare row counts for the tables your models read.
Schema naming: pin the destination schema and table prefixes in Airbyte so existing dbt source() references still resolve.
Ownership: name one person who receives sync failure alerts before cutover.

Before cutover, confirm with Airbyte's deployment documentation which setup you will run in production and how you will back up its configuration.

What usually goes wrong in a Fivetran to Airbyte cutover

Most cutover problems come from differences between how Fivetran and Airbyte name, type, and sync data, not from the connectors themselves. The cards below cover the risks that tend to surface after switching, and the checks that catch them before Fivetran is turned off.

Silent schema drift after cutover

Airbyte and Fivetran can map source types, nested objects, and new columns differently, so a table can look complete while a column changes type or disappears. Compare column lists and data types for each stream against the Fivetran tables before cutover, and set Airbyte's schema change handling deliberately rather than relying on defaults. Record the decision for each connection so the next source change is not a surprise. Review the Airbyte connection settings with the team that owns each source.

Table name changes breaking dbt models

Renamed tables and columns are the most common cause of broken downstream models. Airbyte's default namespace, stream names, and normalization output may not match the schema Fivetran created, so dbt sources and staging models can fail or silently read empty tables. Map every Fivetran schema and table to its Airbyte destination name in a written table, and point the dbt source definitions at the new names in a branch. Run dbt build against both schemas and compare the results before switching.

Cursor resets causing duplicates

If an Airbyte connection starts without the incremental state Fivetran held, the first sync can reload history and create duplicate rows in append-mode tables. Confirm which streams use incremental and which use full refresh, and whether the cursor field matches the one Fivetran used. Test each incremental stream on a copy of the destination and count duplicates on primary keys before the production run. Plan the destination write mode for each stream before the first sync.

Long initial resyncs

A first Airbyte sync of a large source can take far longer than the ongoing incremental loads the team is used to, and it can compete with warehouse capacity and source rate limits. Estimate the historical volume per connection from source row counts, then schedule backfills outside peak hours and watch source API quotas. Ask Airbyte and your warehouse provider for documented throughput guidance rather than assuming a duration. Keep Fivetran running until the backfill has finished and reconciled.

Unsupported connector configurations

Some Fivetran connectors use settings, such as specific authentication flows, custom reports, or Hybrid Deployment, that have no direct equivalent in the Airbyte connector you choose. Check each connector's documented options and limitations against the Fivetran configuration exported from your account, and flag any gap in the migration plan. Where a connector has no equivalent, decide whether to build a custom connector with the Airbyte Connector Development Kit or keep that source on Fivetran during transition.

Missing alerts and on-call ownership

Fivetran sends failure notifications and handles retries inside a managed service, so teams often never define who watches sync failures. Once Airbyte runs in your Kubernetes cluster, failed syncs, stalled jobs, database storage, and certificate expiry all need owners and alert routes. Assign a named owner for each connection, route Airbyte job failures and infrastructure metrics to the team's paging tool, and test a deliberate failure before cutover. Document the escalation path in the runbook.

Questions teams ask before migrating from Fivetran to Airbyte

How long does a migration from Fivetran to Airbyte take?

The duration depends mostly on how many connections you run, how many of them have an Airbyte connector that matches the source and destination you use, and how much downstream logic depends on the exact table and column names Fivetran produced. No duration figure is supplied for this migration, so ask any implementation partner for a timeline tied to your connection inventory. Connections with large historical tables take longer during the initial resync, and that work runs in parallel with your existing Fivetran pipelines. Confirm with the partner which connections they will treat as the first cutover group before agreeing on dates.

Can our team migrate from Fivetran to Airbyte without outside help?

A team with platform engineering skills and a clear inventory of its Fivetran connections can often do the work internally, provided it has time to learn Airbyte's deployment model and to test each pipeline. Airbyte is built to run in a Kubernetes cluster and is documented for deployment with Helm, so the team needs someone comfortable operating that layer. Teams without that experience, or without spare capacity during the parallel run, often bring in an outside partner for the deployment and testing. Be honest about which of these you can staff before deciding.

What does the migration require from our data and engineering teams?

The work asks for three things from your side. Data engineers need to map each Fivetran connection to an Airbyte connector and confirm the destination schema, naming and sync mode. Analytics engineers need to confirm which dbt sources and models read those tables. Platform or security staff need to provide the Kubernetes cluster, network paths to sources and warehouses, and secret storage for credentials. Plan time for these owners before the engagement starts, because most delays come from waiting on access and decisions rather than from running syncs.

What does the Elastic License 2.0 allow us to do with Airbyte internally?

Under the Elastic License 2.0, which covers the Airbyte platform, your organization can use Airbyte commercially for internal operations, build applications powered by Airbyte data, and use it for client work as a data agency. The license prohibits providing Airbyte to third parties as a hosted or managed service, circumventing license key functionality, and selling Airbyte as an ELT tool or exposing its UI or API to customers. Airbyte's connectors and Connector Development Kit are MIT licensed. Have your legal team read the Airbyte license FAQ against your intended use, especially if you plan to offer pipelines to external customers.

How do we keep dbt models working after switching from Fivetran?

Keep dbt models working by matching the destination contract before you cut over. Compare table names, column names, data types, and the metadata columns each tool adds, such as sync timestamps and deletion flags, since those are often used in incremental filters. Use dbt source tests and a row count and checksum comparison on key tables while both tools write to the same warehouse or to separate schemas. If names differ, add a staging layer that maps Airbyte output to the names your models expect, so the models themselves do not change during cutover.

How should we plan the initial resync and the parallel run?

Plan the initial resync as a separate workload, because Airbyte will read full history for each connection it takes over. Large historical tables and rate-limited source APIs dominate that time, so start with the largest connections early and schedule them outside peak warehouse hours. Run both tools in parallel for a period you agree in advance, comparing outputs for each connection and recording any differences in a cutover checklist. Switch off a Fivetran connection only after its outputs match and the dependent models have passed their tests.

What should a quote for a Fivetran to Airbyte migration include?

A quote should follow from a written scope and list the connections in scope, the source and destination for each, and which dbt models are covered by testing. It should separate one-time work, such as deployment, connector mapping, resyncs and cutover, from recurring work, such as upgrades, monitoring and on-call support. Ask who runs the parallel period, how credentials and networking are handled, what evidence is delivered at cutover, and what happens to connections that have no matching Airbyte connector. DeployOpen plans and implements self-hosted platforms in your own infrastructure and provides fixed-scope engagements agreed in writing, with ongoing support available as a retainer.

How DeployOpen scopes and runs the migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Airbyte inside your own cloud accounts, data centers or air-gapped networks. For a Fivetran to Airbyte move, the work starts with a written scope that lists every connection to migrate, then builds and proves each pipeline against the warehouse tables your dbt models already read.

How we scope

Inventory every Fivetran connection, destination, sync schedule and schema setting before any build work starts.
Map each Fivetran connector to an Airbyte connector and record gaps that need a custom or community option.
Agree deliverables, timelines and the parallel-run period in writing before work begins, since engagements are fixed-scope.
Confirm which dbt models, dashboards and downstream consumers depend on each destination table and column name.

How we build

Deploy self-hosted Airbyte into your Kubernetes cluster using the documented Helm chart and your own values.
Recreate connections, sync modes and destination naming so downstream dbt models resolve without edits.
Plan initial full resyncs and their load on source systems and warehouse credits, agreed with your data owners.
Run Airbyte and Fivetran in parallel and compare row counts, keys and freshness for each table before cutover.

How we hand over

Document each pipeline, its connector version, credentials location, schedule and the owner responsible for it.
Provide a reconciliation report per table showing parity checks, exceptions and the sign-off each one received.
Walk your platform and data engineering teams through upgrades, backups and the runbook for failed syncs.
Deliver a cutover checklist with the steps to disable Fivetran connections and retain its configuration export.

How we support

Offer ongoing support, upgrades and monitoring as a retainer after cutover, scoped separately from the migration.
Review Airbyte upgrades and connector version changes against your dbt models before they reach production.
Confirm with your legal team how the Elastic License 2.0 applies to your internal use and any client data work.
Ask for the retainer terms, response expectations and upgrade cadence in the written quote before signing.

Migrate from Fivetran to Airbyte