Migrate from Fivetran to Meltano

Migrate from Fivetran to Meltano: what the move involves

Each Fivetran connection is rebuilt as a Meltano extractor and loader pair declared in `meltano.yml`, and a small team can do that work in-house or with an implementation partner. The usual trigger is a renewal where MAR-based charges have grown, a residency rule that requires data to stay on your own infrastructure, or a wish to stop depending on one vendor's connector catalog. Before any build starts, export the current Fivetran configuration (the sibling page on exporting Fivetran configuration covers how) and use it as the inventory of sources, destinations, schemas and sync frequencies. Each row in that inventory becomes one extractor, one loader and one set of selection rules in the project.

The work usually falls to data engineers who are comfortable with a command line and Git, plus one named owner for scheduling and run monitoring. Meltano is distributed under the MIT license, so the code you run carries no license fee. Meltano Open is the self-hosted base you install and operate, while Meltano Cloud is the managed service built on it, priced by compute usage and offering pipeline monitoring and alerts. Choosing between them is a decision about who runs the scheduler, the state store and the on-call rota. Confirm with Meltano which features each tier includes before you commit to a design.

Effort and risk are concentrated in three places: Singer taps from Meltano Hub vary in maturity, so each source needs a test against a sample of real data before you rely on it; incremental state needs to be understood, because the first run performs a full import and later runs resume from the saved bookmark; and whoever maintains a broken tap after go-live is now your team, not Fivetran. Ask any partner for a written scope that lists each source, the tap version and maintenance owner, the scheduler and alerting design, and the reconciliation checks you will run against Fivetran output before switching off the old pipelines. Duration depends on source count and connector quality, so ask for it to be estimated per source rather than accepting a single figure.

Which Fivetran capabilities map to Meltano, and which need rework

This table maps the Fivetran features you rely on to the Meltano pieces that replace them, and marks each row as clean, needs rework or gap. Read the rework and gap rows as work your team owns after cutover. Confirm connector-level behavior for each tap against its README before you commit to a source.

Fivetran capability	Meltano equivalent	Status and what to check
SaaS and database sources	Singer taps found in Meltano Hub, added with meltano add	Needs rework. Coverage differs per source, and each tap has its own maturity. Check each tap's README for supported streams, auth method and known limits.
Warehouse and lake destinations	Loaders (targets) that write to databases, warehouses and data lakes	Needs rework. Confirm the target's load mode, column typing and table naming so downstream dbt models still resolve.
Incremental replication	Replication state stored after each successful sync, with the first run doing a full import	Clean for most taps. Confirm that the tap supports the bookmark key you expect, and plan a full resync for any table without one.
Environments and pipeline definitions	meltano.yml with dev, staging and prod environments, versioned in Git	Clean. Your Fivetran connections move into reviewable code, but you must recreate every setting by hand or from an exported snapshot.
Scheduling	Your own scheduler, such as cron or an orchestrator you already run, invoking Meltano jobs	Needs rework. Meltano runs the pipeline but does not own the schedule, so retries, alerting and backfills belong to your scheduler.
Managed schema drift handling	Taps and targets handle schema changes according to their own code	Gap. Fivetran adjusts schemas for you. With Meltano, confirm drift behavior per tap and test how new columns and type changes reach your warehouse.
Managed connector maintenance	Community-maintained or self-maintained Singer taps	Gap. Fixing a broken API change or a deprecated endpoint is your team's job, or a vendor's under a separate retainer.
Built-in monitoring and alerts	Available only in Meltano Cloud, per Meltano's documentation. Open-source Meltano needs your own logging and alerting	Gap for self-hosted Meltano. Plan logs, run status checks and row-count reconciliation before cutover.

How Meltano represents a Fivetran connection

In Fivetran, a connection bundles a source, a destination and a schema configuration into one object managed in the Fivetran interface. In Meltano, the same job is split into two plugins: an extractor that pulls data from the source and a loader that writes it to the destination. Extractors cover SaaS APIs, databases, files and custom sources, while loaders write to databases, data warehouses, data lakes and vector databases. Each Fivetran connection you inventory should become one extractor and one loader pair, and the first task is to record that pairing for every connection so none is lost in translation. Run meltano init to create the project, then use meltano add followed by the plugin name, such as meltano add tap-github, to record each plugin in meltano.yml along with its configuration and selection rules.

The meltano.yml file is the central record of the project. It lists environments such as dev, staging and prod, and every plugin with its settings, so you can see at a glance which tables a source feeds into which warehouse schema. Confirm that your selection rules reproduce the tables and columns you pull today in Fivetran, because Fivetran's schema settings do not transfer automatically. Keeping this file in Git gives you reviewable changes, a history of who altered a source or destination, and a single place to promote a tested configuration from dev to prod. Secrets should be kept out of the committed file and supplied through your environment or secrets manager, which is the step most teams need to plan before the first commit.

What to export, recreate and rebuild from Fivetran

Start with a complete inventory of what Fivetran holds for you, then rebuild each item deliberately in Meltano. The documented export path through the Fivetran REST API or Terraform provider gives you the configuration inventory, but no export format is guaranteed to be Meltano-ready, so treat the export as a source of facts to translate, not a file to import.

Export connection and schema configuration

Use the Fivetran REST API or the Terraform provider to capture connections, destinations and schema settings as the inventory of what runs today. Record each connector's source type, sync frequency, destination and table selections in one place. Check the export for fields that describe Fivetran's own internals rather than what the pipeline must do, since those have no Meltano equivalent. Confirm the exact export endpoints and resource names against Fivetran's current documentation before you script anything.

Move source credentials into a secrets store

Fivetran holds API keys, database passwords and OAuth tokens for every source. Exported configuration may show that these exist but should never be committed to Git. Create each credential in your secrets manager, then reference it from the Meltano environment rather than writing it into meltano.yml. Rotate credentials during cutover so that a copied secret does not outlive the migration. Ask your security team which store and access policy applies.

Destination and schema naming

Fivetran names destination schemas by connector, and downstream models depend on those names. Decide whether Meltano will write to the same schemas and table names or to new ones, then document the mapping. Loader settings in meltano.yml control where data lands, so a naming change here ripples into every dbt model and query that reads the tables. Confirm the destination schema names with the owners of each downstream consumer before the first load.

Selected tables, columns and filters

Fivetran's table and column selections decide what reaches the warehouse. Rebuild each selection as an explicit rule in the Meltano extractor configuration, including excluded columns that contain personal or regulated data. Compare the selected set against the warehouse tables that actually exist today, because drift in the source can make a selection differ from what analysts expect. Keep a written list of every excluded column and the reason for excluding it.

Incremental keys and replication state

Fivetran tracks how far each table has synced, and Meltano stores its own incremental bookmark after a successful sync. The two states do not transfer, so plan an initial full import for each stream. For each table, confirm the replication key, such as an updated timestamp or primary key, and whether deletes are captured. Missing or wrong keys produce silent gaps, so validate them against source row counts during the parallel run.

Downstream dbt and BI dependencies

List every dbt model, dashboard, scheduled report and reverse ETL job that reads a Fivetran-loaded table, and note the freshness each one assumes. Fivetran's sync timing may be the only thing those assets rely on, so Meltano's scheduler must match or improve it. Map each dependency to its owner so that schema changes and cutover dates are agreed before Fivetran is switched off. Confirm the dependency list with analytics engineering, not only with the platform team.

Migration sequence from inventory to decommission

This sequence moves Fivetran connections into Meltano one source at a time, proving each pipeline against the warehouse before any consumer depends on it. Each step leaves a written artifact, so the cutover and the Fivetran shutdown rest on evidence rather than memory.

Inventory every Fivetran connection and consumer
Export the list of Fivetran connections, their source types, destination schemas, sync frequencies and transformation dependencies, using the Fivetran REST API or Terraform provider if your team has them configured. Record which dbt models, dashboards and reverse-ETL jobs read each destination table, because those consumers define what must match. The output is a connector inventory with one row per connection, its owner, its tables and its downstream consumers. The step is done when a data owner has reviewed and signed off the list.
Pilot one low-risk source in Meltano
Choose a source with a stable, well-documented API and a small table set, then find its tap on Meltano Hub and add it with meltano add. Configure the extractor and a warehouse loader in a development environment, run a full first sync, and confirm the Singer tap's stream selection covers the same tables Fivetran loads. The output is a passing pilot run with logs, plus a note of any fields, types or pagination behavior that differ from the Fivetran connector. Confirm the tap's maintenance status with its maintainers before you rely on it.
Build the meltano.yml project with environments
Turn the pilot into a version-controlled Meltano project, with plugins, extractor settings, loader settings and selection rules declared in meltano.yml. Define dev, staging and prod environments so credentials and target schemas differ per environment, and keep secrets out of the file by referencing your secrets store. Migrate the remaining connections in batches using the same pattern. The output is a Git repository where a reviewer can read every pipeline definition, and the step is done when a clean checkout runs in staging without manual edits.
Schedule runs and verify incremental state
Attach each pipeline to the scheduler you already operate, such as Airflow, cron or your CI system, and confirm that runs execute in the expected order. Meltano stores incremental replication state after a successful sync, so test a failed run and a rerun to confirm the bookmark does not advance on failure and that no rows are skipped. Record the resulting state and the schedule for each pipeline. The output is a run log showing the first full import followed by incremental runs with the expected bookmarks.
Run Meltano in parallel and reconcile tables
Keep Fivetran syncing into its existing schemas while Meltano writes to a separate staging schema, so both outputs cover the same period. Compare row counts, primary key uniqueness, null rates, column names and data types, and sample values for date and currency fields, table by table. Document each mismatch and decide whether to fix the tap configuration or the downstream model. The output is a reconciliation report signed by the data owner for every table, and the step is done when no unexplained differences remain.
Cut over downstream consumers
Point dbt sources, dashboards and reverse-ETL jobs at the Meltano-produced schemas, or rename the target schemas if your models depend on Fivetran's naming. Run the dependent transformations and downstream checks, and keep a rollback path that re-points consumers to the Fivetran schemas until the parallel period ends. Record which consumers moved, when, and who approved each change. The output is a cutover record listing each consumer, its new source and its verification result.
Decommission Fivetran connections
Once every consumer has run successfully on Meltano output through the agreed observation period, pause and then delete the Fivetran connections, and review the contract or plan changes with your procurement team. Export a final copy of the configuration for your records before deletion, and confirm with Fivetran what happens to synced data in its environment. The output is a decommission checklist with dates, the final configuration archive and sign-off from the data owner and the finance contact.

Handling incremental state and scheduling runs

Meltano stores incremental replication state only after a successful sync, so the first run performs a complete import and later runs resume from the saved bookmark. That behavior replaces Fivetran's managed sync history, and it is the part of the migration most likely to produce duplicate or missing rows. If you point a new Meltano project at a warehouse that already holds Fivetran-loaded tables, and the tap has no bookmark yet, the first run will reload history. If you carry over a bookmark that does not match the rows already in the destination, the run will skip data. Decide per stream whether you will accept a full reload into a new schema, or whether you will seed state from the last Fivetran sync time and verify the boundary before cutover.

Scheduling is also yours to operate. Fivetran runs syncs on a schedule it manages, while Meltano runs only when something invokes it, such as cron, Airflow, Dagster or another orchestrator you already run. Plan the schedule, retries, alerting on failed runs and the handling of a run that overlaps the next one. Keep the state store and the warehouse in the same backup and access-control scope, because losing the state store means a full reload. Meltano Cloud adds pipeline monitoring and alerts for teams that want them managed, priced by compute usage according to Meltano's documentation, but the self-hosted path leaves monitoring to you.

Before cutover, confirm each tap's replication method, which fields it uses as the replication key and how it treats deletes. Many Singer taps do not capture hard deletes, so a row removed in the source may remain in the warehouse after migration even though Fivetran would have handled it differently. Run both pipelines against the same window, compare row counts and key coverage per table, and keep a written record of the bookmark value each stream starts from. Check the tap's own documentation or source code for these behaviors, because community taps vary in how completely they implement them.

What drives cost and duration in this move

The cost of leaving Fivetran for Meltano is set less by the license, which is MIT, than by how many connections you move, how many taps need custom work, and who runs the pipelines afterward. Each card below is a component to price separately in a written scope, with a note on whether it is paid once or every month.

Fivetran connections in scope

Start by inventorying every active Fivetran connection, its source, destination, sync frequency and the tables and columns downstream models depend on. Each connection maps to a Meltano extractor and loader pair, so the count sets the size of the build. Connections that are simple, well-documented SaaS APIs take less effort than custom database sources with complex replication. Ask for the connection count and a per-connection estimate in the scope, and confirm which connections are retired rather than moved.

Singer taps needing custom work

Meltano Hub lists the Singer taps you can install, but tap quality varies, and some sources need a fork, a patch or a new tap written from scratch. This is the largest variable in the build. Check each candidate tap against the source's current API version, pagination and incremental keys before committing. Ask the scope to name which taps are used as-is, which need fixes and which need new development.

Warehouse and compute for runs

Self-hosted Meltano runs on compute you provide, and the warehouse bills separately for query and storage. Fivetran's usage-based charges disappear, but full initial imports and frequent incremental syncs still consume CPU, memory and warehouse credits. Ask for an estimate of initial import volume, sync frequency and peak concurrency, and confirm how the warehouse is billed for loads and merges.

Orchestrator and scheduling

Meltano runs pipelines, but scheduling is handled by a tool you run, such as Airflow, cron or your existing orchestrator. This adds a scheduler to operate, monitor and secure, along with its own infrastructure and upgrades. Decide early whether you will reuse an orchestrator already in place, and include its configuration, secrets handling and retry logic as a scoped deliverable.

Build and test engineering time

The one-time build covers project setup in meltano.yml, environment configuration for dev, staging and prod, incremental state checks and data reconciliation against Fivetran output. Engineering hours are usually the largest one-time cost, and they are spent mostly on testing table shape, types and row counts. Ask for the build plan to list each connection, its test criteria and who signs off on parity before cutover.

Cutover, parallel run and decommissioning

Running Fivetran and Meltano in parallel for a period lets you compare warehouse tables before switching off Fivetran. This phase is one-time but carries risk, because downstream dbt models, dashboards and access grants depend on the old schema. Ask the scope to define the parallel window, the reconciliation checks and the steps that remove Fivetran access and credentials.

Ongoing connector maintenance and on-call

Recurring cost comes from source API changes, tap upgrades, schema drift and failed runs at night or on weekends. Someone on your team owns each tap after handover, and that owner is the person paid for every fix. Ask who is responsible for tap versions, how breaking changes are detected and what response time your team expects for failed syncs.

Monitoring and alerting

Fivetran shows sync status and alerts in its own interface. With Meltano Open, you build equivalent visibility from logs, run history and warehouse freshness checks, or you pay for a managed option such as Meltano Cloud, which is priced by compute usage. Decide which alerts go to which team, and ask for the monitoring stack and its ongoing hosting cost in the written scope.

How the move differs by team size and starting point

A small team with a handful of SaaS sources usually gets the fastest result from Meltano. The project is small enough to live in one Git repository, and most of the work is confirming that each SaaS connector pulls the objects your dbt models depend on. Your main risk is that a community Singer tap covers fewer endpoints or fields than the Fivetran connector you are replacing, so inventory the tables first and check them one by one.

Pick taps from Meltano Hub early: Search the Hub for each SaaS source and note the maintainer, last update and the streams it exposes before you install anything with meltano add.
Keep the project in one repository: A single meltano.yml with dev and prod environments is enough, and every change to a connector goes through a pull request.
Plan for a scheduler you already have: With few sources, a cron job or the scheduler you use for dbt may be simpler than adding a new orchestrator.
Accept that you own the connectors: When a SaaS vendor changes its API, your team patches or replaces the tap, so budget for that work in your own time.

Before you cut over, confirm that every table Fivetran produced exists in the warehouse with matching row counts and that incremental bookmarks advanced after a full run.

Some teams want pipeline monitoring and alerts without running that layer themselves. Meltano Open is the self-hosted foundation with access to 600+ built-in connectors. Meltano Cloud is a fully managed hosted service built on top of it, with pipeline monitoring and alerts, and it is priced by compute usage. The choice is mainly about where orchestration and monitoring run, and it should be made before you design the project layout.

Meltano Open: You host the CLI, the scheduler and the monitoring you build yourself, which keeps data and credentials inside your environment but adds operating work.
Meltano Cloud: Monitoring and alerts come with the managed service, and the compute charge recurs with usage, so ask how it scales with your sync volume.
Data path questions: Confirm with the vendor whether source credentials and extracted data pass through the managed service, since this decides whether it fits your residency requirements.
Exit path: Because the project is defined in meltano.yml and Git, you can keep the same definitions if you later move between the two.
Compare on your own workload: Ask for a written quote based on your number of pipelines and sync frequency rather than relying on general pricing comparisons.

Before you choose, check what alerting your team needs, who receives it out of hours and whether the managed service meets the data handling rules that apply to your organization.

Questions teams ask before moving from Fivetran to Meltano

What does a move from Fivetran to Meltano cost, and what drives the cost?

Meltano Open is MIT-licensed, so the software itself carries no license fee, but the migration is not free. Cost comes from four components: the compute that runs your extractors and loaders, the engineering time to select and configure taps and build the project, the ongoing maintenance of connectors that break when source APIs change, and the scheduler and monitoring you run around it. Fivetran's MAR-based billing ends when you switch off its connections, while your compute and staff time recur. Costs rise with the number of sources, the number of tables per source, and how many taps need custom work. Ask any partner for a quote built from a written list of sources, destinations and table counts, with one-time and recurring items shown separately.

How long does a Fivetran to Meltano migration take?

Duration depends on the factors that set the work, not on a fixed figure. The main drivers are the number of sources, whether each source has a maintained Singer tap in Meltano Hub, how many schemas and tables must match Fivetran's output, how much incremental state needs to be reconstructed, and how many downstream models depend on exact table and column names. Parallel running before cutover adds time but reduces risk. Ask for a timeline tied to a written scope, with a separate line for validation against Fivetran output.

Can our in-house team migrate from Fivetran to Meltano without a partner?

A team with Python, Git and warehouse experience can usually run the migration itself, especially for a small number of well-supported sources. The work is hands-on: installing Meltano, adding plugins with meltano add, configuring them in meltano.yml, handling incremental state, scheduling runs, and checking results in the warehouse. Teams with many sources, strict audit requirements or no one available to maintain connectors often bring in outside help for the setup and handover. Decide early whether you need implementation support, a retainer for upgrades, or both.

What skills and access does a Meltano migration require from our team?

You need four things in place before work starts. First, a Git repository and a review process, because pipeline definitions live in meltano.yml and should change through commits. Second, someone comfortable with Python and the command line to install and debug plugins. Third, credentials and network access to each source and to the destination warehouse, with a service account scoped to the write paths needed. Fourth, a named owner who accepts responsibility for failed syncs, connector upgrades and schema changes after cutover. Without that owner, the pipelines will drift once the migration team leaves.

Does Meltano support every connector Fivetran offers?

No, and you should not assume it does. Meltano Hub lists a large number of Singer taps, and the project describes access to more than 600 APIs and databases, but that count does not mean each source has a tap that matches Fivetran's connector in coverage, quality or maintenance. For every Fivetran connection, check the tap in Meltano Hub, read its open issues and last release, test it against a non-production source, and compare the tables and fields it returns with what Fivetran loaded. Sources without a usable tap need a custom extractor or a different tool, and that work belongs in the scope.

How do we check that warehouse tables match what Fivetran produced?

Run both pipelines in parallel against separate schemas, then compare each table on row counts, primary keys, column names and data types, and sample values for timestamps, nulls and decimals. Because Meltano stores incremental state after a successful sync and the first run performs a full import, plan the initial load and confirm that later runs pick up from the saved bookmark. Fivetran adds its own metadata columns and naming conventions, so decide whether downstream dbt models should be adjusted or the new output mapped to the old names. Document the reconciliation results so the cutover decision rests on evidence.

What does Meltano Cloud add over self-hosted Meltano Open?

Meltano Open is the self-hosted, open-source foundation with access to 600+ built-in connectors. Meltano Cloud is a fully managed hosted service built on top of it, and according to Meltano's documentation it adds pipeline monitoring and alerts, priced by compute usage. The trade-off is where your data processing and orchestration run and who operates them. If your requirement is that pipelines stay inside your own cloud account or data center, Meltano Open is the relevant option. Confirm Meltano Cloud's data location, pricing terms and support scope directly with Meltano before comparing it with your own operating cost.

How DeployOpen scopes and runs a Meltano migration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Fivetran to Meltano, we start from a written inventory of your Fivetran connections and warehouse tables, then agree the scope, deliverables and timeline before any pipeline work begins.

How we scope

Inventory every Fivetran connection, destination schema and sync schedule that the migration must replace.
Map each source to a Meltano extractor from Meltano Hub, or record where a custom Singer tap is needed.
Agree in writing which tables, columns and incremental state must match Fivetran output and how mismatches will be judged.

How we build

Create the Meltano project in Git with environments for dev, staging and prod, and define each extractor and loader in meltano.yml.
Configure incremental replication and confirm that the first full import and later bookmark-based runs behave as the scope states.
Wire scheduled runs into the orchestrator you specify and test failure alerts, retries and credential handling in your environment.

How we hand over

Deliver the meltano.yml project, run runbooks and a table-by-table reconciliation report comparing Meltano and Fivetran outputs.
Walk your data engineers through adding plugins, changing selection rules and diagnosing a failed sync on your own systems.
Document the cutover sequence, rollback steps and the decommissioning checklist for Fivetran connections once you approve them.

How we support

Ongoing support, plugin upgrades and continuous testing are available as a retainer after handover.
Agree in the written scope who fixes a broken Singer tap, since community taps vary in maintenance and you may need a patch or replacement.
Ask for a quote that separates one-time build effort from recurring support, compute and monitoring costs in your environment.

Migrate from Fivetran to Meltano