What you can export from Quickbase, and what you must rebuild
Quickbase exports table data one table at a time, in CSV, TSV or XML, and each export is subject to size limits that you must confirm in Quickbase's current documentation before you rely on them. Attachments do not travel with the table export. They need a separate route through Pipelines, delivered in parts. Formulas, relationships, forms, reports and Pipelines logic are not carried in a data file, so each one must be written down and rebuilt in the target platform. If a renewal, a price change or a residency concern is driving the move, start this inventory now, because copying the records is usually the quick part and the rebuild takes the longer effort.
For each application, list every table and record its row count, its attachment fields, and its field types, including formula, lookup, user and relationship fields. Check each table's export size against the limits in the current documentation, and split any table that exceeds them. Export a small test table first and open the files in a spreadsheet to confirm that dates, multi-line text, numbers and user fields arrive intact. Baserow's pricing page lists CSV, Excel, XML and JSON import, so the file formats map to an import path, but you should test whether link fields between tables survive the import before you commit to a plan. Store the exports in an encrypted location that your team controls, with checksums recorded for each file.
Ask your Quickbase administrator for a full export while the subscription is still active, and confirm in writing what the vendor retains after termination, for how long, and how you can retrieve attachments afterward. Document every Pipelines flow, user role and access rule, since these decide who sees which records in the new system. Then reconcile before you cancel: compare row counts, totals for key numeric fields and a sample of opened attachments between each source table and its imported copy. Repeat the check after the rebuilt forms and reports are live, because a migration that moves the data correctly can still fail on the logic around it.
Which Quickbase data can you export, and in which format
This table maps each category of Quickbase data to its export route, file format and documented limit, with the place where each export runs. Confirm every limit against Quickbase's current documentation before you plan the migration. Records and field values export in a single pass per table, while attachments, users, roles and app metadata each need a separate step.
| Data type | Export method | File format and documented limit | Where it runs |
|---|---|---|---|
| Table records | Table export from the app, one table at a time | CSV, TSV or XML per table; 500 MB limit, to confirm | Quickbase interface, by a user with export rights |
| Field values | Included in the table export | Same file as records; confirm how formula and lookup fields export | Quickbase interface, same run as records |
| Attachments | Pipeline that downloads files in parts | Parts under 100 MB each; 150 MB limit noted, to confirm which applies | Quickbase Pipelines, built and run by an administrator or builder |
| Users and groups | Admin console user and group lists | Typically CSV; confirm available formats and limits | Quickbase admin console, by a Quickbase administrator |
| Roles and access rules | Role and permission settings captured from the admin tools | Not part of record exports; document manually or confirm an export option | Quickbase admin tools, recorded before the contract ends |
| App and table metadata | Field definitions, relationships, forms and reports | Usually not in data files; confirm XML or API options with Quickbase | Quickbase app settings or API, by an administrator or developer |
| Reports, dashboards and automations | Inventory of definitions and logic | Not in table exports; capture definitions as documentation | Quickbase app builder, reviewed with the app owners |
What does not export from Quickbase and how to rebuild it
A Quickbase export carries table data and, within limits, attachments. The logic around that data, including formulas, relationships, reports, forms, permissions and automations, has to be documented from the application and rebuilt in the target tool. Confirm each item with your Quickbase administrator before the contract end date so that nothing is discovered after access closes.
Formula and lookup logic
Formula fields, lookups and summary calculations are stored as definitions in the app, and the export holds only their computed values. Export the table values first, then have your administrator list every formula field with its expression and the table it belongs to. In Baserow, formula fields and lookup, rollup and collaborator fields are not imported from Airtable, so expect to rewrite these by hand. In Grist, formulas can be written in Python, which means existing expressions need translation rather than copying.
Relationships between tables
Reference fields that link one table to another come out as text or ID values, not as working links. Ask your administrator for a map of every parent and child table and the key field that joins them. Rebuild each link as a link-to-table field in the target tool, then re-run a sample of records to confirm the joins return the same rows as the Quickbase report. Relationships are the most common source of silent data mismatch after migration.
Reports and dashboards
Quickbase reports hold filters, grouping, sorting and column choices that are configured in the app and do not travel with the CSV file. Ask for a list of each report, its purpose, its filter criteria and the people who rely on it. Recreate each one as a view with the same filters and sorts, and compare row counts for a fixed date range. Dashboards built from several reports need a separate design decision in the target tool.
Forms and the application builder
Forms, page layouts, navigation and the app's user interface are not part of any data export. Record which forms are used for data entry, which fields are required, and which default values or validation rules they apply. Rebuild these as forms or interfaces in the target tool. Test each form with a real user from the team that uses it, because field order and validation behavior often change between platforms.
User permissions and access rules
Role assignments, table-level and record-level access rules, and field security do not export with the data. Ask your administrator for the full permission matrix by role, including which users can see or edit specific records. Baserow's role-based permissions are listed on its Advanced plan, and Grist's access rules need to be written against your model, so confirm which controls each target edition provides before mapping roles.
Pipelines automations
Pipelines move data between Quickbase and other systems on a schedule or trigger, and their logic lives in the platform, not in the table export. Ask your administrator to list every active pipeline with its source, destination, schedule and field mappings. Rebuild each one as an automation in the target tool or in a workflow engine such as n8n, then run both in parallel for one reporting cycle before turning off the Quickbase pipeline.
The sequence for a complete Quickbase export
This sequence turns a Quickbase application into a verified, documented set of files before any migration work starts. Each step ends with a check that someone else can repeat, so the export can be audited and compared with the target tables later. Confirm current export limits and options with Quickbase before you begin, because they can change.
Inventory every table, field and relationship
The application administrator lists each table in the Quickbase application with its fields, field types, relationships, formulas, and the roles that can see each table. Mark the fields that hold attachments and the fields that depend on formulas or lookups, because those values will need rebuilding after the move and cannot simply be copied. A business owner reviews the list. The step is complete when the inventory matches the application settings and every table has an entry in a shared register.
Confirm each table fits export limits
Compare the expected size of each table with the export size limits in Quickbase's current documentation, and confirm those limits with Quickbase directly before you start. Any table that exceeds a limit must be split into filtered exports, for example by saved criteria or by date range, and each split must be logged so no record is dropped or counted twice. The step is complete when every table has a size estimate, a limit check and a recorded decision to export it whole or in parts.
Export table data in the chosen format
Export each table's records in one format that your target tool can import, such as CSV, TSV or XML, and name each file with the table name and export date. Export from a view that shows every record and every field you need, and check that no view filter hides rows you expect to see. Work in dependency order, with parent tables first, and keep the record keys that link child tables to parents. The step is complete when every table has a file and a log entry with the record count reported by Quickbase.
Retrieve attachments through the documented route
Attachments are not included in the table export, so retrieve them through the route Quickbase documents for files, which runs through Pipelines in parts smaller than the documented limit. Confirm the exact method and part size with Quickbase before building the Pipeline, since the size limit determines how many parts each file needs and how the parts are reassembled. Keep each file's record ID, field name and original file name so every attachment can be linked back to its record. The step is complete when the number of attachments retrieved matches the count of attachment fields in the inventory.
Export schema and field definitions
The data files carry records, not the full design, so export or document the schema separately. Record field names, field types, choice lists, required flags, default values, and the full formula text for every calculated field. Save business rules, form layouts and report definitions as separate documents, with screenshots where text export is not available. The step is complete when someone outside the build team can read the schema document and rebuild one table from it without asking follow-up questions.
Store files in an immutable location with checksums
Copy every data file, attachment and schema document into write-once storage, such as an object store with object lock or a locked backup repository, that follows the organization's retention policy. Generate a SHA-256 checksum for each file and store the manifest beside the files, so each copy can be verified later. Restrict access to the export location to named roles and log every read. The step is complete when a second person recomputes the checksums from the stored copies and every value matches the manifest.
Run record counts and spot checks
Compare the record count in each exported file with the count shown in Quickbase for the same table and filter, and investigate every difference before moving on. Then sample records from each table, including records with attachments, blank fields, long text and linked records, and compare the values by hand with the source. The step is complete when all counts match or each difference has a written explanation, and every sampled record matches its source.
Record the export as the migration baseline
Write a baseline record that lists the export date, the Quickbase application and environment, the files, the checksums, the record counts, and the known gaps, such as formulas, Pipelines logic or forms that will not transfer directly. Name the people who approved the export. Use this baseline as the reference for the import into Baserow or Grist, so each imported table can be checked against the same counts and checksums. The step is complete when the baseline is approved in writing and the migration team can point to it for every table.
How to verify the export before the target is loaded
Baserow's importer accepts CSV, Excel, XML and JSON files, so you can load the exported Quickbase tables directly into a new Baserow table after you have checked the files. Before you import, record the row count of each Quickbase table from the source report, then compare it with the row count shown in Baserow after the import finishes. Field types matter more than row counts, because Baserow assigns a type to each column from the file and the type you pick at import decides how values are read. Test dates and numbers with a small sample first, since locale-specific formats such as day-first dates or thousands separators are a common source of silent change.
- Row and column counts: Compare the source count for each table with the count in the new Baserow table, and confirm the column count matches the fields you chose to export.
- Date and number formats: Import a sample with dates in several formats and confirm each one parses to the value you expect before loading the full file.
- Multi-select values: Check that values containing commas or separators survive the CSV export, because a list stored as one cell can split into several options.
- Attachment links: Expect the exported file to carry attachment references rather than the files themselves, so confirm the attachment pipeline output is linked to the right rows.
- Expected differences: Quickbase formulas, lookups and summary fields arrive as plain values or are dropped, so document these as recalculated or rebuilt rather than as data loss.
Before loading production data, confirm with a row-by-row sample that no field silently changed type, and keep the Quickbase export unchanged as the reference copy.
Grist imports and exports CSV and Excel files, and each Grist document is based on SQLite. That makes verification straightforward, because you can open the imported document, export it again and compare the result with the original Quickbase files, or read the underlying SQLite data with a standard tool if your audit process requires it. Grist formulas support full Python syntax, so calculated Quickbase fields need to be rewritten as Grist formulas rather than copied across. Plan the comparison around the column types Grist infers, because a column that arrives as text instead of a number or date will break later calculations.
- Row counts per table: Export the imported Grist table back to CSV and compare the row count with the Quickbase export, noting any blank rows the source contained.
- Field types and inference: Review each column's type in Grist after import, and correct numbers stored as text or dates stored as strings before building formulas on them.
- Date and number formats: Compare a sample of dates and decimal values between the two files, checking the decimal separator and the date order used in the export.
- Multi-select and choice values: Confirm that choice lists keep their separators and that values with embedded commas stay in one cell.
- Attachment links: Check that attachment references point to files you have stored separately, since Grist does not recreate Quickbase attachment fields from a CSV alone.
A useful final check is a round trip: export the verified Grist table, then compare that output with the original Quickbase export to confirm that only the expected formatting changes remain.
Some verification steps apply to both targets and should be done before either import starts. Keep the original Quickbase exports unchanged in a read-only location, because they are the reference for every later comparison. Agree on a list of tables and the number of rows expected in each, and record the export date and the user who ran the export so the evidence can be reproduced. Quickbase exports are limited to 500 MB per table for CSV, TSV or XML, and attachments are only available through Pipelines in parts under 100 MB, so a table that was split or a file that was downloaded in parts must be reassembled and counted before the comparison starts.
- Reference copy: Store the untouched export files with checksums so any later change is detectable.
- Row and table inventory: Maintain a sheet listing each source table, its expected row count and the target table that receives it.
- Split exports: Confirm that any table exported in parts has the same total rows as the source report once the parts are combined.
- Attachment inventory: Match each attachment file to the record that references it, and record any file that failed to download.
- Sign-off record: Keep the comparison results with the migration ticket so reviewers can see what was checked and by whom.
Before you treat a migration as complete, have the data owner sign off on the reconciled counts and the list of expected differences.
No import from Quickbase files runs without edits, so the goal of verification is to separate expected changes from defects. Expected differences usually include formulas, lookups and summary fields that become values or must be rebuilt, user and group references that map to new accounts, and formatting such as locale-specific dates that the target reads differently. Record each difference with the source field, the target field and the reason, and decide in advance whether each one is accepted, corrected or blocked. Changes to record values, dropped rows, altered numbers or broken attachment links are not expected and should stop the migration until they are explained.
- Calculated fields: Quickbase formula results are exported as values, so document which fields must be recreated as formulas in the target.
- User and access references: Records assigned to Quickbase users need a mapping to target accounts, and access rules are rebuilt separately.
- Formatting changes: Dates, currency symbols and decimal separators can display differently, so compare underlying values rather than screen text.
- Relationships: Links between tables may arrive as text, so confirm each relationship in the target before relying on it.
- Blocking differences: Missing rows, changed numeric values and broken attachment references must be resolved before the target is used.
When the list of expected differences is agreed and the blocking items are cleared, the verified data is ready to load into production.
What to plan before the Quickbase renewal or termination
The export itself is the easy part to schedule. The risk sits in the decisions around it: the deadline, who can run the export, what the contract says about your data, and how long the rebuilt apps need to run beside the old ones. Work through these six items before the renewal or termination date is fixed.
Set the export completion date
Work backward from the date your Quickbase access ends. Every table, its attachments, and the Pipelines outputs you still need must be exported before that point, and attachments take extra steps because they run through Pipelines in parts under 100 MB. Build in time to verify row counts against the source. Confirm the exact access end date in writing with your vendor account team.
Name the administrator who runs exports
Identify which named people hold the Quickbase administrator role and can run exports, build Pipelines and change app settings. If only one person holds that role, plan for their absence or departure. Confirm whether your plan level allows the export actions you need, and record who performed each export for your audit trail.
Read the data return and deletion terms
Check your order form and master agreement for clauses on data return, deletion after termination, and any deadline for requesting a copy. These terms are not standard across all contracts, so do not assume them. Ask your vendor to confirm in writing what happens to your records and attachments after access ends, and whether deletion is certified.
Decide retention for exported files
Exported CSV, TSV and XML files carry personal and business data outside Quickbase's access controls. Decide how long each export must be kept, who can read it, and where it is stored on your own servers. Apply the same classification and deletion rules you use for other records, and document them before the first export runs.
Estimate the app rebuild time
Rebuilding relationships, reports, forms and access rules is usually the longest part of the migration, and it can take longer than the data move. List every app, table, report and form, then rank them by how much business process depends on them. Ask your implementation partner for a fixed-scope estimate based on that list rather than relying on a general figure.
Plan a parallel-run period
Keep Quickbase and the replacement running side by side long enough for each team to check that records, calculations and notifications match. Agree on which system is the record of truth during that period and how changes made in one are copied to the other. Only switch off Quickbase after your reconciliation checks pass and the retention copies are verified.
Where exported Quickbase data can land on your own servers
The two self-hosted targets differ mainly in licensing and in which features sit behind a paid edition, so choose the target after you have listed what the export has to carry. Baserow is open core: its non-premium and non-enterprise features are released under the MIT License, while premium and enterprise features fall outside that grant. Grist has an Apache 2.0 core in grist-core, and Grist Labs sells a full edition that adds features such as OIDC and SAML single sign-on and audit log streaming. Both can run on your own servers, so the question is which paid features you need, not whether the data can stay in-house.
The choice matters most for three things: single sign-on, audit logs and automations. Baserow lists single sign-on on its Advanced and Enterprise plans with an activated license, and Grist needs an activation key to connect directly to an identity provider over OIDC or SAML. Grist keeps automations out of grist-core, so confirm whether you need them in the full edition or in an external tool. Write down which of these your Quickbase users depend on today, because that list should drive the export scope: a table with access rules and attachments needs a different path than a plain reporting table. Confirm current licensing terms with each vendor before you commit.
Match the export files to the target. Quickbase exports tables as CSV, TSV or XML, and Baserow's importer accepts CSV, Excel, XML and JSON, so both targets can take table data as long as you export each table within the size limits. Grist documents SQLite as its storage format, which helps if you need to inspect numeric and text data outside the application. Attachments are a separate step in Quickbase and need a Pipeline, so test one attachment-heavy table in each candidate before you settle on a target. For a feature-by-feature view, see the sibling pages comparing Quickbase with Baserow and Quickbase with Grist.
How much effort does a Quickbase data export take, and can we do it ourselves?
How long does a complete Quickbase export take?
The duration depends on the size and shape of your Quickbase estate, so ask for a timeline only after an inventory is complete. The main drivers are the number of tables, the record count per table, the attachment volume, the number of apps involved, and whether relationships, reports and formulas must be documented alongside the data. Table exports are usually the quick part. Attachments, which Quickbase handles through Pipelines in parts, often take the longest because each file must be retrieved, named, checked and linked back to its record. Confirm the export limits that apply to your Quickbase edition in Quickbase's own documentation before you estimate.
Can an internal team export Quickbase tables without outside help?
Yes, many internal teams can export table data as CSV, TSV or XML, provided an administrator has the right permissions and the estate is small. Work that needs more care includes checking exports against the documented size limits, retrieving attachments, confirming that record counts match, and documenting formulas, relationships and reports so they can be rebuilt in the target system. Teams with many apps or a short contract window often find the verification and documentation steps take more time than the exports themselves. Ask your Quickbase administrator which exports they have already run successfully before deciding.
What does the Quickbase administrator and app owners need to provide?
The administrator and app owners carry most of the knowledge that an export engagement depends on. They need to provide:
- An inventory of apps, tables, fields, relationships and reports, with owners named for each
- Export permissions for every table in scope, plus access to any Pipelines that move attachments
- A decision on which records, users and attachments are in scope, including archived data that must be kept
- Approval of the verification method and the person who signs off the final export
Without these decisions, the work stalls on questions that only the business can answer.
What does a fixed-scope exit engagement from DeployOpen cover?
Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. For a Quickbase exit, the written scope typically lists the apps covered, the export formats, how attachments are retrieved and stored, the verification method, and the handover documentation. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue audit reports or certifications. Ongoing support after the handover is available as a retainer.
What does a quote for a Quickbase export depend on?
DeployOpen does not publish a price list. A quote follows from the written scope, so the main inputs are the number of apps and tables, the attachment volume and file sizes, the complexity of fields and formulas, the Pipelines logic that must be moved, and the depth of verification you require. The target platform also matters, because a move to self-hosted Baserow or Grist involves different import steps and rebuild work. Ask for the quote to be split into components such as discovery, export, attachment handling, verification, documentation and any follow-on support, so you can see which parts are one-time and which recur.
How should we handle attachments that exceed the documented limits?
Start by listing which files exceed the limits that apply to your Quickbase edition, then confirm the documented method for each group with Quickbase. Common approaches are retrieving large files in parts through Pipelines, scripting retrieval against Quickbase's API where your plan allows it, and storing the files in a self-hosted S3-compatible object store such as Garage or SeaweedFS. Keep a manifest that links each file to its original record, with a checksum recorded at export and checked after import. Confirm with the target platform how attachments are imported and whether links to external storage are kept in the records.
How do we verify that a Quickbase export is complete?
Verification compares what left Quickbase with what arrived in the target, table by table. Useful checks include record counts per table, spot checks of field values across date, user and numeric fields, a count of attachments with checksums, and a review of relationships and reference fields. Keep the export logs and a signed record of what was checked. The depth of verification drives effort: a sample-based check on a few tables takes far less time than a full field-level comparison across every app. Ask any provider to state the verification method in the written scope before work starts.
How DeployOpen scopes and delivers a Quickbase exit
DeployOpen plans and delivers the export as a fixed-scope engagement inside your own infrastructure, so table exports, attachment recovery and the handover evidence are agreed in writing before work starts. The result is a documented, checked copy of your Quickbase data that your team can use after the contract ends.
How we scope
- Inventory every Quickbase table, report and user group you need to keep, with record counts and attachment volumes
- Agree in writing which tables export directly and which need Pipelines for attachments in parts under 100 MB
- Confirm the target platform, hosting location and who in your organization signs off each export
How we build
- Set up the target environment in your own cloud account, data center or air-gapped network before any data moves
- Run test exports of sample tables and reconcile row counts, field types and relationships against the source
- Script the attachment recovery path and record any table that needs manual handling or a second pass
How we hand over
- Deliver a migration runbook covering export steps, file naming, checksums and the reconciliation results
- Document the access rules and user mappings that were recreated, and list anything that did not carry over
- Provide a written record of the final export set and a dated sign-off for your records and auditors
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover
- Keep a backup and restore check on the exported data so it stays usable beyond the contract end
- Confirm with your compliance team which evidence they need, and prepare it for their independent assessors
