What you can export from Fivetran before leaving
Connection, destination and schema configuration can be exported through Fivetran's documented REST API and its Terraform provider, but synced data itself is not part of that path. If a renewal, a change in MAR-based charges or a data residency requirement has pushed you toward an exit, the first deliverable is an inventory of what Fivetran is configured to do. The export gives you that inventory. It does not give you the warehouse tables Fivetran has written, so keep your warehouse backups and retention policies as the separate recovery path for historical data.
Fivetran's documentation describes the manual route: list connections with GET /v1/connections, retrieve each connection's details and schema configuration, list destinations, and save the results as files. Before anything reaches version control, remove credentials and other sensitive values such as API keys, passwords and tokens from every file. Then commit the sanitized files to a private GitHub repository. Fivetran's documentation also recommends the Fivetran Provider for Terraform for managing configuration as code, so ask your platform team whether a Terraform state already exists that can serve as a second source.
Treat the snapshot as a configuration plan, not a backup. Each connection file should be turned into a row in a migration register that lists the source, the destination, the schema and table selections, the sync frequency and the owner of each downstream model. That register is what you compare against the connectors available in your target tool, and it is where you decide which pipelines to rebuild first. Confirm with Fivetran which fields in your account are returned by the API versions you use, because a snapshot that omits a schema setting will produce a rebuilt pipeline that loads different tables. Record the date of each export so you can tell which configuration was live when a discrepancy appears.
Which Fivetran configuration can be exported and how
This table maps each part of a Fivetran setup to the export method, output format and limits you should confirm before relying on a snapshot. Use it to decide which parts you can capture through the REST API, which need the Terraform provider, and which you must record by hand. The main takeaway is that connection, schema and destination settings are exportable, but credentials and any values you strip must be handled before anything is committed to version control.
| Configuration area | Export method | Output and what to confirm |
|---|---|---|
| Connection details | GET /v1/connections to list connections, then retrieve each connection's details | JSON responses per connection. Confirm current pagination and rate limits in Fivetran's REST API documentation. |
| Schema configuration | Per-connection schema configuration call, run for each connection in the list | JSON describing schemas, tables and column settings. Confirm which fields are returned for your connector types. |
| Destination configuration | Destination listing through the REST API | JSON for each destination, including its group association. Record which destinations hold credentials you must remove. |
| Terraform configuration | Fivetran Provider for Terraform, which Fivetran recommends for configuration as code | HCL resource definitions. Import existing objects and check the plan shows no unintended changes before you rely on it. |
| Credentials and secrets | Not exported as values; remove any that appear in API output | Strip passwords, API keys and tokens before committing. Store them in your own secrets manager for the rebuild. |
| Pipeline sync history and data | Not part of the configuration export | Historical data and sync state stay in Fivetran. Plan initial loads and resyncs in the target tool separately. |
What does not come out of Fivetran and how to cope
The documented REST API and Terraform export captures configuration, not everything a pipeline depends on. Credentials, synced data, historical logs and source-side state stay behind, so each gap needs a plan before you cancel. Confirm every item below against current Fivetran documentation, because what the export covers can change between releases.
Stored credentials and secrets
The export strips passwords, API keys and OAuth tokens on purpose, so committed files contain placeholders rather than working authentication. Each source must be re-authorized in the new tool, or its credentials pulled from a vault such as the one your team already runs. Make an inventory of every connection that uses a secret, record who owns each account, and confirm that service accounts have the read scopes the new connector needs before you rely on them.
Synced row data in the destination
Your configuration snapshot describes pipelines but holds none of the rows they have loaded. The warehouse or lake that Fivetran wrote to is the only complete copy of historical data, especially for sources that no longer retain old records. Treat the destination as the data copy during migration, and check whether the source can supply a full backfill if you need to rebuild a table from scratch.
Historical sync logs
Sync history, error messages and row counts per run live in Fivetran's interface and are not part of the configuration export. Those logs are the evidence you need when a downstream model breaks or an auditor asks how a table was loaded. Export or screenshot the relevant history before cancellation, and store it alongside the migration record, since it may not remain accessible after the subscription ends.
Source-side incremental state
Fivetran tracks where each connector left off, such as a cursor, a log position or a change-data-capture offset. That bookmark is not in the configuration files, so a new tool may start with a full import or, worse, skip records written during the gap. Plan an overlap window, compare row counts for recent periods, and confirm with the new tool's documentation how it initializes incremental replication for each source.
Schema history and destination naming
The export shows the schema configuration you selected, but not how Fivetran has altered tables over time or the naming it applied to them. Downstream dbt models and dashboards depend on exact table and column names, so any drift breaks them silently. Capture the current table list and column definitions from the destination, and compare them against what the replacement pipelines produce before switching anything off.
Export sequence from the REST API to a Git commit
This sequence turns your live Fivetran setup into a versioned, reviewable snapshot of connections, schemas and destinations. The result is the baseline you use to plan the rebuild on your own infrastructure.
Confirm API access and inventory connections
Create an API key with the access level your team is allowed to use, then call GET /v1/connections to list every connection in the account. An administrator on the data team does this, using a workstation or a scripted client that stores the key outside the repository. Done means you have a complete list of connection IDs saved as a working file, which you will compare against the dashboard later.
Retrieve each connection and its schema
For every connection ID, request the connection details and its schema configuration, which record the source type, sync settings, destination binding and which tables and columns are enabled. Save each response as its own JSON file so a failed call affects one connection, not the whole export. Done means every connection has a details file and a schema file, and any failed calls are logged for a retry.
List destinations and map them to connections
List the destinations in the account and record each destination's group, target warehouse and schema prefix. Cross-reference this with the connection files so every connection points to a destination you have captured. Done means a destinations file exists and every connection's destination reference resolves to one entry in it.
Strip credentials and sensitive values
Before anything is written to version control, remove passwords, API tokens, OAuth secrets, private keys, host credentials and any connection-level secret fields from every file. Replace each removed value with a named placeholder, such as an environment variable reference, so the rebuild knows what to supply. Done means each file keeps its structure and every sensitive field is a placeholder, not a value.
Commit the snapshot to a GitHub repository
Create a private repository with restricted access, add the sanitized files in a folder per destination, and commit them with a message that records the export date and the account identifier. Restrict branch protection so changes go through review. Done means the default branch contains the snapshot and the commit history shows who exported it and when. If your policy requires a different Git host, apply the same steps there.
Reconcile file count with the dashboard
Compare the number of connection files in the repository with the number of connections shown in the Fivetran dashboard, and compare the destination count the same way. Investigate any gap, including paused connections or connections in other groups, before you rely on the snapshot. Done means the counts match, or each difference is written down with a reason.
Verify that no secret values remain
Run a secret scan over the repository history for this export, using a scanner your security team already trusts, and search the files for key patterns, token prefixes and password fields. Confirm that every placeholder matches a credential you will supply in the new environment. Done means the scan reports no secret values, and a reviewer has signed off on the commit before the snapshot is used as a rebuild plan.
What to strip before committing the snapshot to Git
The export is not safe to commit as it comes out of the API. Connection and destination objects carry configuration that can include credentials, API keys, OAuth tokens and destination passwords, and a schema or connection payload can also reference host names, service accounts or key identifiers that you would rather not publish. Fivetran's own guidance for exporting connection configuration to GitHub calls for removing credentials or other sensitive values before the files are committed. Treat that as a gate, not a suggestion: every file the script writes should pass a review step before it enters a repository, and the review should cover both the connection detail responses and the destination responses, since either can carry secrets.
Build the removal into the export itself rather than relying on a manual edit. Strip known sensitive keys in the script so they never reach disk, then add a secret scanner in a pre-commit hook and in your CI pipeline as a second check. Scanners such as gitleaks or detect-secrets catch patterns the script did not anticipate, such as a token pasted into a free-text field. Confirm the scanner's rule set covers the credential formats your sources use, and test the hook once with a planted fake secret so you know it blocks the commit. Store every removed value in your vault, indexed by connection ID, so the rebuild has a place to read the real secret from when a pipeline is recreated.
Keep the raw, unredacted export in a restricted location outside the repository, with access limited to the people who need it for the migration and an access log turned on. The redacted copy in Git is the plan for rebuilding; the raw copy is the record you may need if a value was missed. Do not send the snapshot to a new vendor, a migration partner or a consultant until it has been through this review, and when you do share it, share the redacted version and provide secrets through the vault. Ask your legal and security teams how long the raw copy must be retained and when it must be deleted, because that answer depends on your own policies and not on anything in the export.
Questions teams ask before exporting Fivetran configuration
Do I need Fivetran admin access and an API key to export my configuration?
Yes, you need an API key tied to a user with enough rights to read connections, destinations and schema settings across the groups you want to export. Fivetran's export guidance starts with listing connections through GET /v1/connections, then retrieving each connection's details and schema configuration, so a key with narrower permissions may return partial results. Confirm the key's role and the groups it can see in your own account before you start, and record which groups were included so the snapshot is complete.
How long does the export take for a large Fivetran account?
The duration depends on your account, especially the number of connections, destinations and schemas, and the time it takes to retrieve each one. Fivetran's documentation describes the steps but does not give a timing, so run a small test against one group and measure it. Scale that measurement to the full connection count, and confirm the result in your own environment before you schedule the work.
Can my team export the configuration alone, or do we need outside help?
An engineer who is comfortable with REST calls, JSON files and Git can complete the basic export alone. Help is more useful when the account is large, when credentials and sensitive values must be found and removed reliably, or when the export has to feed a rebuild plan that another team will sign off. DeployOpen plans and implements self-hosted platforms in your own infrastructure and can scope that help in writing before work starts, with the final quote following from that scope.
What do we need to prepare before starting the export?
You need four things ready before the first API call:
- Access: an API key with read rights, plus a secure place to store it during the run.
- Inventory: a list of every connection, destination and the business owner of each source.
- Owners: a named person for each source system who can confirm the expected tables and sync frequency.
- A Git repository: a private place to commit the sanitized files and track changes.
Without owners, the snapshot can show what Fivetran was configured to do but not whether that still matches what the business needs.
Should we start from the REST snapshot or from Terraform state?
Start from whichever source is complete and current for your account, then cross-check the other. The REST export gives a point-in-time view of connections, destinations and schema settings, which suits a one-time inventory. Fivetran recommends the Fivetran Provider for Terraform for managing configuration as code, so if your team already runs Terraform, its state and code may be the better long-term record. If the two disagree, treat the difference as a finding to resolve before you rebuild anything.
What drives the total cost and effort of the export and rebuild?
The main drivers are the number of connections and destinations, how many schemas are customized, how many sources have undocumented owners, and how much sensitive configuration must be removed and replaced. Fivetran's export steps are the same for a small and a large account, so the effort grows with inventory size and review time rather than with the export script itself. Ask any provider for a quote that separates the export, the review of each source, and the rebuild of pipelines, so you can see which parts recur and which are one-time.
Is it safe to commit the exported files to GitHub?
It is safe only after you remove credentials and other sensitive values from every file. Fivetran's guidance includes removing credentials before committing the files to GitHub, so check each JSON file for passwords, tokens, hostnames tied to secrets and personal data before the first commit. Use a private repository, restrict who can read it, and keep a record of who reviewed the sanitized snapshot.
What to plan before the Fivetran contract ends
The export is only one piece of leaving Fivetran. The decisions below set the deadline for the export, decide what history you keep, and determine who approves switching off the old pipelines. Settle them before you start rebuilding connections in a self-hosted platform.
Notice period and renewal date
Find the notice period and the renewal date in your Fivetran order form and master agreement. Confirm these terms with Fivetran and your legal team rather than assuming a default, because auto-renewal clauses and notice windows differ by contract. Work backward from the last date you can give notice to set the deadline for a complete export.
Export completion deadline
Set a date by which the REST API export of connections, destinations and schema configuration must be finished and committed to version control. Treat that date as a checkpoint, not the end of the work. Recheck the export after any configuration change made during the migration window so the snapshot does not go stale.
Log and history retention in Fivetran
Decide what Fivetran history you need to keep, such as sync logs, schema change records and connection status history. Confirm with Fivetran how long that data remains available after you stop paying, and export anything your auditors or incident teams may need. Keep these records in your own storage, since they are not part of the configuration snapshot.
Destination warehouse retention plan
Decide how long the tables Fivetran wrote to your warehouse remain available, and who owns them after the connections stop. Note any fields Fivetran added, such as sync metadata columns, that downstream models depend on. Keeping those tables for a defined period gives you a fallback if the rebuilt pipelines miss rows.
Parallel-run window
Plan a period in which the self-hosted pipelines and Fivetran both load the same destinations, so you can compare row counts and schemas. Define the comparison checks in advance, such as totals per table and freshness of key tables. The length of this window should fit inside your notice period with room to fix problems.
Cutover sign-off
Name the people who approve switching off each Fivetran connection. Typically this includes the data platform owner, the owners of downstream reports and models, and someone accountable for security and data residency. Record the approvals in writing so that the decision to stop syncing has a clear owner and an audit trail.
Using the export to choose Airbyte, Meltano or dlt
The export is more than a backup. Its connection list tells you which connector type each source uses, which destination each one writes to, and how each schema is configured, and those three fields decide which target fits each source. Sort the connections into groups by source type first: SaaS applications with a well-maintained prebuilt connector are the easiest to move, while databases with custom replication settings and niche APIs need a closer look before you pick a tool. Keep the destination list alongside it, because a warehouse you already run may favor one target over another. Confirm each mapping in your own environment rather than assuming that a connector exists for every source you use.
Once the sources are grouped, use the sibling pages to test each group against the target you are considering. The Fivetran vs Airbyte comparison is not the right starting point for licensing questions, so check the license terms directly. Airbyte's core is under the Elastic License 2.0, which allows internal use and client work but forbids hosting it as a service for third parties, so if your plan involves offering pipelines to customers, confirm that position with counsel before you commit. The migration pages for Airbyte, Meltano and dlt cover the steps for each target, and the Fivetran cost comparison covers the recurring and one-time charges that the export cannot show you directly.
Record your decision for each connection in the same repository as the exported files, with the chosen target, the owner and the check you will run to confirm that row counts and schemas match. This record becomes the plan for rebuilding pipelines, and it shows which sources can move first and which need a parallel run before you switch Fivetran off. Ask each candidate vendor or project to confirm the connectors for your specific sources and versions, since a connector name in a catalog does not guarantee the fields, authentication method or incremental behavior you rely on.
How DeployOpen scopes and delivers a Fivetran configuration exit
DeployOpen treats the export of Fivetran configuration as the first step of a fixed-scope engagement, not as a standalone script. We agree the connections, destinations and schema settings in writing, then build a version-controlled snapshot and a rebuild plan that your team can review before any pipeline is moved.
How we scope
- Inventory every Fivetran connection, destination and schema setting that the written scope covers before any export starts
- Agree in writing which connections are in scope and which teams own each downstream table and dashboard
- Confirm which secrets, credentials and personal data fields must be removed before any file is committed to your repository
- Fix the deliverables, the review points and the timeline in the written scope, with pricing following from that scope
How we build
- Script the export through the Fivetran REST API, listing connections, retrieving their details and schema configuration, and listing destinations
- Strip credentials and sensitive values from every exported file, then check the output against the agreed redaction rules
- Store the snapshot in your own Git repository and organize it so that each connection can be reviewed and rebuilt separately
- Map each exported connection to a target open-source option and record the gaps that need a decision before cutover
How we hand over
- Deliver the redacted configuration snapshot, the connection-by-connection rebuild plan and the list of open decisions for your team
- Document the export procedure so that your engineers can repeat it and confirm the snapshot matches the live Fivetran setup
- Walk your engineers through the rebuild plan and record which items you accept, change or defer in writing
- Keep an audit trail of the export steps, reviewers and redaction checks as evidence for your own compliance assessment
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer
- Ask for the retainer terms, response expectations and included services in the quote so the scope boundaries are clear
- Confirm with DeployOpen which work is one-time, such as the initial export, and which recurs, such as re-exports after changes
- Ask how configuration drift between Fivetran and your repository will be detected and reported after handover
