What you can export from Netlify, and what you cannot
If you are facing a renewal, credit pauses or a data residency requirement, you can take three things out of Netlify today: a ZIP of any successful deploy, form submissions as CSV or through the API, and Netlify Blobs through the list method. Deploy-specific blobs are not included in deploy downloads, and project settings, environment variables and DNS configuration need separate handling. Netlify documents each data type separately, so there is no single one-click export of an entire site and its configuration.
Start with the deploy ZIP, which you reach from the detail page of any successful deploy. It contains the built output of that deploy, so it captures the static files you served but not the build commands, plugin configuration or the source repository. Keep your Git repository as the authoritative source of code and confirm that every site you need can be rebuilt from it. For forms, use Download as CSV on each form's detail page, and note that the API also returns spam submissions, which the CSV view may not show. Netlify recommends exporting and deleting submissions regularly when forms collect personal data, so decide your retention period before you export.
Blobs need the most planning. The UI downloads blobs one at a time, so for stores with many entries, script the paginated list() method, which groups results into pages of up to 1,000 entries, and then fetch each key. Because deploy-specific blobs are excluded from deploy downloads, add a separate Blobs API or CLI step for them. Your team owns verification: compare entry counts and checksums against the source, test a restore into your target platform, and record what was exported, when and by whom. Confirm current limits and export options with Netlify support before a contract deadline.
Which Netlify data types have a documented export path
This table compares the three kinds of data a Netlify site usually holds: deploy files, form submissions and Netlify Blobs stores. Read each row for the export method, the format you receive and the limit that affects a full copy. The main takeaway is that deploy downloads do not cover every blob, so a complete export needs a separate step for deploy-specific blobs.
| Data type | Export method | Format | Limits |
|---|---|---|---|
| Deploy files | Download a single file or a ZIP of the whole site from the detail page of any successful deploy | Individual files or a ZIP archive of the deployed site | Only successful deploys are offered; confirm which deploys are retained in your plan |
| Form submissions (UI) | Download as CSV on the form's detail page | CSV of verified form submissions | Covers verified submissions shown in the UI; export regularly before deletion |
| Form submissions (API) | Form submissions endpoint in the Netlify API | JSON from the API | Returns both verified and spam submissions, so filter spam during import |
| Netlify Blobs (list and read) | list() method on the Blobs API, returning all blobs in a store | Format depends on what your application stored | Results come in pages of up to 1,000 entries; loop until all pages are read |
| Netlify Blobs (UI) | Download in the Netlify UI | Format depends on what your application stored | One blob at a time, so it suits spot checks rather than full exports |
| Deploy-specific blobs | Separate export through the Blobs API or CLI | Format depends on what your application stored | Not included when you download a deploy, so script this step and confirm coverage |
Data that does not come out with a deploy download
A deploy download gives you the built site, but Netlify keeps other data in separate places. Each gap below needs its own export step, and the team should inventory them before cancelling anything. Where the supplied documentation is silent, confirm with Netlify before you rely on an export.
Deploy-specific blobs
Netlify's Blobs documentation states that downloading a deploy does not download deploy-specific blobs. If your functions read data scoped to a particular deploy, that data is absent from the ZIP. Export it through the Blobs API or the CLI, and record which store names and keys belong to each deploy. Check a restored copy in a staging environment before you rely on it.
Blobs downloaded one at a time
The Netlify UI downloads blobs only one at a time, which is impractical for stores with many entries. Use the list() method instead, which returns all blobs in a store in pages of up to 1,000 entries. Script the pagination, write each blob to your own storage, and compare the final count against the store's total before you consider the export complete.
Site configuration and settings
The supplied documentation does not describe an export of site configuration, such as build settings, domain configuration or deploy notifications. Inventory these from the Netlify dashboard and the repository's netlify.toml file. Ask Netlify support whether a settings export exists for your plan, and keep a written record of every setting you cannot export.
Environment variables
Environment variables are not covered by the supplied export documentation, so do not assume a deploy download or ZIP includes them. Secrets are a particular risk because values may be visible only once. Confirm with Netlify how values can be retrieved, then move them into your secrets manager on the new server before the first deploy there.
Team members and access roles
The supplied facts do not document an export of team members, roles or access history. Build the list manually from the team settings page and record each person's role. This matters for regulated teams that must show who could publish or read form data. Confirm with Netlify whether member lists can be exported in a machine-readable format.
Billing and invoice history
Billing history, including credit usage and invoices, is not covered by the supplied documentation. Ask Netlify whether invoices and usage reports can be downloaded for your account, and for how long. Keep finance records in your own archive, since they support cost comparisons and any audit of past spending.
The export sequence that produces a verifiable copy
This sequence turns a scattered Netlify account into a dated, inventoried archive of deploys, form submissions and blobs, where every export is checked against a count or a rebuild before the account is changed. Run it before any cancellation, plan change or migration so the copy exists while Netlify still holds the originals.
Inventory every site, deploy and store
Someone with owner access lists every team site in the Netlify dashboard, then records for each site its production deploy, its recent successful deploys, its forms and any Netlify Blobs stores the code reads. Keep the list in a spreadsheet with the site name, site ID, production deploy ID and the date of export. Confirm the list against the sites shown under each team in the account settings, because a site that is not in the inventory will not be exported. The step is done when the inventory has one row per site and one row per form and store, and the owner has signed off on the count.
Download the production and relevant deploy ZIPs
For each site, open the detail page of the production deploy and of each earlier successful deploy you need to keep, then download the ZIP of the entire deployed site. Individual files can be downloaded too, but the ZIP is the complete copy of what was served. Store each ZIP under the site name and deploy ID. Verify by unzipping one archive and checking that the file count matches the deploy's file list in the dashboard and that index.html and the asset folders are present. Only failed or superseded deploys are left out, and the inventory should note which deploys were skipped and why.
Export form submissions as CSV
For each form, open its detail page and choose Download as CSV, which exports verified submissions. Then use the forms API to pull submissions, which also returns spam-flagged entries, and save that output separately so the two sets can be compared. Record the number of rows in each file and the date range covered. Netlify recommends exporting and deleting submissions regularly when forms collect personal data, so note who holds the files and where they are stored. The check is that the verified CSV row count matches the count shown on the form page for verified submissions.
Run paginated Blobs list calls per store
For each Netlify Blobs store, run the list() method through the Blobs API or CLI and follow the pagination cursor until no further pages are returned, because each page holds up to 1,000 entries. Then download each blob by key and save it with its metadata. Repeat this for deploy-specific stores, since the Blobs documentation states that a deploy download does not include them. Do not rely on the dashboard for this step, because it downloads blobs only one at a time. The check is that the number of keys saved equals the total from the paginated listing, and a sample of blobs opens with the expected content type.
Hash files and store them in two places
Generate SHA-256 checksums for every ZIP, CSV and blob file and write them to a manifest with the site, deploy ID, store name and export date. Copy the archive and manifest to at least two locations you control, such as encrypted storage in your own cloud account and an offline copy, and restrict access to named people. Verify by recomputing the checksums from one of the copies and comparing them to the manifest. A copy that fails the checksum check is not a valid export and the file should be exported again.
Reconcile counts against the Netlify dashboard
Compare the manifest with the Netlify dashboard for each site, checking deploy counts, form submission totals and blob key totals against the numbers in the export. Record any difference with a reason, such as a deploy that was deleted or a spam entry that was excluded. The owner signs the reconciliation sheet before the account is changed. The step is complete when every row either matches or has a documented explanation, and the reconciliation sheet is stored with the manifest.
Test the exported site and data restore
Test the copy in an environment you control, not on the production Netlify site. Rebuild or serve the production ZIP locally or in a test container and load a sample of pages and assets, then check forms and any blob-backed features against the exported data. Restore the CSV submissions into a test sheet or database and confirm the row counts and sample records match. Record which features do not work from the export alone, such as Netlify functions or the form handling that Netlify performs, so they can be replaced before cutover. The sequence is complete when the test site renders, the restored data matches the manifest, and the gaps are logged.
Why deploy downloads are not a full backup of your site
A deploy ZIP from Netlify captures the built, published output of one deploy: the HTML, CSS, JavaScript, images and other files that the CDN served at that moment. It does not contain the source repository, the build command and environment settings, the redirect and header rules you wrote, or the team's deploy history and configuration. Those live in your Git provider and in the Netlify site settings, so a team planning an exit should export or record each of them separately. Treat the ZIP as a snapshot of what visitors saw, not as a copy of how the site was made. Also note that deploy-specific Netlify Blobs are not included in a deploy download, so they need their own export through the Blobs API or CLI, as covered elsewhere on this page. Confirm with your developers that the repository is complete and that every branch needed for rebuilds is pushed.
Form submissions are personal data when they include names, email addresses or messages, and that data carries retention duties under whatever privacy rules apply to your organization, such as the GDPR if you serve EU residents. Netlify's guidance is to export and delete submissions regularly when forms collect personal data, so an export that copies everything forever can create a compliance problem of its own. Before you pull a CSV or call the API, decide how long each form's submissions should be kept, which submissions are spam and can be discarded, and where the exported files will be stored and who can read them. Have a privacy or legal owner approve that retention decision in writing, and record the date of each export, the number of records and the storage location. The API returns both verified and spam submissions, so filter them deliberately rather than assuming the CSV matches what you need.
What to plan before the Netlify contract ends
Exporting from Netlify is the easy part when the work is planned in order. The decisions below connect billing status, the frozen production deploy, the target platform, DNS and form endpoints, submission retention and a final export, so nothing is lost after the account stops running.
Confirm the credit balance
Check how much of the monthly credit balance remains and what happens to projects if it runs out. Netlify's credit-based plans pause projects when credits are exhausted, so confirm with Netlify whether a paused project still lets you download deploys, read form submissions and list blobs. Run a test export while the account is still fully active, so a pause cannot block your only copy.
Freeze and document the production deploy
Pick the production deploy you intend to keep and stop merging changes to the branch that builds it. Download the ZIP of that successful deploy from its detail page, record the deploy ID, commit SHA, build settings and environment variable names, and store them with the archive. This gives you a fixed reference point to compare the rebuilt site against.
Choose the target platform
Decide where the site will run, for example self-hosted Coolify or Dokploy with the Static, Nixpacks or Dockerfile build packs. A static export fits the Static build pack, while server-rendered frameworks need Nixpacks, Railpack or a Dockerfile. Confirm that the target supports every feature the site uses, since Netlify Functions and Forms have no direct equivalent on the platform.
Set the cutover with DNS and form endpoints
Plan the date when DNS records move from Netlify to the new proxy, and list every place that posts to a Netlify form endpoint or calls a Netlify function URL. Lower DNS record time-to-live well before the switch, and update form actions and API callers in the same release. Test each form on the new host before pointing production traffic at it.
Plan retention for form submissions
Decide which form submissions to keep, which to delete and where the kept records will live. Netlify recommends exporting and deleting submissions regularly when forms collect personal data, so record who approved each deletion and confirm that the CSV export is complete before removing anything. Map the retention rule to your privacy obligations with your legal or compliance owner.
Schedule the final export after the last change
Run the final export after the last deploy, form change and cutover check, not before. Include deploy-specific blobs through the Blobs API or CLI, because downloading a deploy does not capture them, and verify that the export lists match the counts you expect. Keep the archive in storage you control and confirm it can be read before you close the account.
Questions teams ask before exporting from Netlify
How much effort does a complete export from Netlify take?
The effort depends mainly on how many sites, forms and blob stores you have, and on how much proof your team needs that the export is complete. A single small site with one form can be exported by hand in a short sitting. The work grows with each additional site, because every site has its own deploy history to choose from, its own form list and its own stores. Verification adds more time than the downloads themselves: someone has to compare file counts, check that each form's CSV matches the submission total in the dashboard, and record which deploy was saved. Teams with compliance obligations usually spend more time on that record-keeping than on the transfer. Ask for an inventory of sites, forms and blob stores before estimating anything, because that list sets the scope.
Can our own team export from Netlify without outside help?
Yes, for most content. Your team can download a ZIP of any successful deploy from its detail page, and export verified form submissions to CSV with Download as CSV on each form. Both steps use the Netlify interface and need no code. Netlify Blobs are different. The UI downloads blobs only one at a time, so a store with many entries needs a script that calls the list method and walks through the pages of up to 1,000 entries each. Deploy-specific blobs are not included in a deploy download, so they need a separate export through the Blobs API or CLI. Developers should write and run that script, and someone should review its output. If your team has no one comfortable with the API, plan for developer time from the start.
What access and decisions does the export require from our side?
Before work starts, you need to provide four things. First, a Netlify account role with access to every site and form in scope, plus an API access token if blobs or form data will be pulled by script. Second, the exact names of each blob store, since the list method works per store. Third, a list of the forms that collect personal data, because Netlify recommends exporting and deleting submissions regularly in that case. Fourth, a retention decision: how long exported data must be kept, where it will be stored, and who may read it. Tokens should be scoped to the minimum needed and removed after the export. Your security team should approve where the archive lands before any file is downloaded.
Can we export data from Netlify while credits are paused?
Confirm this with Netlify before you plan around it. Netlify's credit-based plans pause projects when the monthly balance runs out, and the documentation on credit-based pricing plans describes that behavior, but this material does not establish whether dashboard downloads, form exports or API reads remain available during a pause. Do not assume they do. Ask Netlify directly whether a paused account can still download deploys, export submissions and call the Blobs API, and get the answer in writing. If access is restricted, the export has to happen before the balance runs out, which makes the timing part of the project plan.
Does a deploy ZIP contain everything that a site needs to run?
A ZIP of a successful deploy contains the deployed site, meaning the files Netlify served, and you can download individual files or the whole site from the deploy's detail page. It does not automatically capture everything around the site. Deploy-specific blobs sit outside that download, so they must be exported separately. Build settings, environment variables, redirect and header rules, and any functions configuration live in your project and repository, so keep those in version control before the export. Check the archive against the live site by opening key pages and assets. An export that looks complete can still miss a file that the build generated at runtime.
What would a consultant scope in a fixed-scope export engagement?
DeployOpen works from a written scope agreed before work starts. Typically that covers an inventory of sites, forms and blob stores; a decision on which deploys to keep; the deploy ZIP downloads and form CSV exports; a script for blob listing and retrieval using the paginated list method; checks that the exported counts match what Netlify reports; a secure storage location and a retention plan; and a short record of what was exported and when. Items outside the export, such as rebuilding sites on your own servers, are separate scope and need their own agreement. Ask any provider to state what is excluded, and to explain how it will verify completeness. DeployOpen does not publish a price list, so the quote follows from that written scope.
Does exporting Netlify data satisfy our compliance obligations?
An export is one control among several, and it does not make your data compliant by itself. What it does provide is a copy you control and a record of what was taken. Compliance assessors look for evidence that data handling is documented, access is limited and retention follows a stated policy. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ask your auditor which evidence they expect, such as the export log, token handling records and the retention schedule, before the export begins.
How DeployOpen scopes and runs a Netlify data export
DeployOpen treats a Netlify data export as a written, fixed-scope piece of work that inventories what your team needs to keep before anything is downloaded. We then plan the export of deploy archives, form submissions and Netlify Blobs, and hand over the files with a record of what was taken and what still needs manual handling.
How we scope
- Inventory each Netlify site, its successful deploys, forms and Blobs stores before agreeing the export plan
- Confirm which deploy-specific blobs exist, since downloading a deploy does not include them and they need the Blobs API or CLI
- Agree in writing which personal data in form submissions must be exported, retained or deleted, and who approves that
How we build
- Write export scripts that call the Blobs list method and follow its paginated results until every entry is retrieved
- Pull form submissions through the API, including spam-flagged entries, and reconcile counts against the Netlify dashboard
- Store exported ZIP archives, CSV files and blob contents in your own storage with checksums so each file can be verified later
How we hand over
- Deliver a manifest listing each site, deploy ID, form, blob store and file, with counts and checksums for every item
- Document the gaps that remain, such as items that only the Netlify UI or CLI can reach, and how your team should handle them
- Provide a runbook that lets your staff repeat the export or verify a restored copy without DeployOpen involved
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer if the export must run again or the data changes
- Confirm the support boundary and response expectations in the written scope before work starts, since no default SLA is implied
- Ask your DeployOpen contact to add a re-export or verification step to the retainer if your retention rules require periodic checks
