We started out building on Quickbase, and now we help businesses move off it. This guide is written so you can do it yourself. Where we'd do it differently, we say so, and the last section says plainly what we sell.
Step 1: Decide whether to leave at all
Good reasons to leave:
- Your bill keeps growing as you hire, and the renewal is getting hard to justify.
- The app has become the backbone of the business, and you want to own it.
- Only one person really knows how the app works, and that worries you.
- You keep running into platform limits, like the Pipeline step limit or a workaround you've rebuilt three times.
- You want AI working on your own data and workflows, on terms you control.
When you should not leave Quickbase:
- Your bill is small and steady, and the app does what you need.
- Your team wants to keep building it themselves in a no-code editor every day, and enjoys it.
- You're midway through a large Quickbase project that's about to pay off.
- Nobody on your side can spare a few hours a week during the move to test and answer questions. A migration without someone who knows the work goes badly, whoever does it.
- Your renewal is in the next few weeks. Rushing a cutover to beat a date is how data gets lost. Renew once, then plan the move ahead of the next one.
If you're unsure, write down your yearly Quickbase cost and the three things you wish the app did. Our Quickbase pricing guide helps with the cost.
Step 2: Take inventory of everything
Most migrations that go wrong miss something here: a Pipeline nobody remembered, a formula that feeds a report the owner reads every morning. Before you export anything, write down every piece.
The inventory checklist:
- Apps. Every app in the realm that's still in use, and which ones talk to each other through cross-app relationships.
- Tables and record counts. Note the count for each table now. You'll need it in Step 6.
- Relationships. Each link between tables, plus every lookup and summary field built on it.
- Formula fields. Copy the formula text for each one from the field's properties. Use "Where is this field used?" on the fields page to see which reports, forms, Pipelines and other formulas depend on it (Quickbase: check field usage).
- Reports and dashboards. Which ones people actually open. Report totals and averages aren't stored in any field, so note how each one is calculated.
- Forms. Including form rules, and any forms used on phones.
- Roles and permissions. Every role, what it can see and edit at the table and field level, and who's in it.
- Pipelines. Each one: its trigger, steps, and every outside system it touches.
- Automations, Actions and webhooks. Quickbase has retired these for new setups, but older apps often still run them (Quickbase feature retirements). They're easy to miss.
- Code Pages. Custom HTML, CSS and JavaScript pages under App settings, and anything that calls them (Quickbase: code pages).
- Notifications, custom emails and document templates. Who gets what, and when.
- Integrations. Accounting, email, connected tables, Zapier or Make, scripts using the API, and the user tokens behind them.
- People. Who uses which app, how often, on desktop or phone, and the person who knows why each odd field exists.
If you're on the Enterprise plan, the Solution APIs can export a text description of your apps, called QBL, which includes formula field definitions. Quickbase is clear that QBL "is not the source code of a solution", and it can't export unsupported Pipeline channels or connected tables (Quickbase: QBL and Solution APIs). It's a useful map, not a finished copy.
Step 3: Get your data out
What the standard export gives you
Open a table, choose More > Import/Export, then Export a table to a file. You get CSV, tab-delimited or XML (Quickbase: export data from tables). Know what's in it:
- Values, not logic. Formula fields come out as the value they show today, not the formula behind it. Choose Export data-entry fields if you want only the raw inputs.
- No file attachments. Quickbase says it plainly: "File attachments are not exported."
- Size limits. The compressed export must be under 150MB. Bigger tables need the RESTful API, or splitting into reports and exporting each one.
Do the export for every table, and keep the record ID column. Your relationships depend on it.
Exporting to Excel
For a subset, open a report and select Download report as CSV; Excel opens it directly. Totals and averages shown on the report aren't exported, because they don't live in a field (Quickbase: export data from reports). Quickbase also has an Excel Add-in that imports reports as sheets; it uses one integration read per 1,500 records (Quickbase Excel Add-in). Fine for analysis. For a migration, use full table exports.
Getting attachments out
Two routes, both from Quickbase's own docs:
- A Pipeline. Search records that have a file, loop over them, and upload each file to SharePoint, OneDrive, Google Drive or Box. Add the record ID to the file name so you can match files back later (Quickbase: export using Pipelines). Pipelines handle files up to 100MB, so split big jobs.
- The API. Each attachment has a download URL built from the table ID, record ID, field ID and version. Version 0 is always the latest (Quickbase: upload and download files). Quickbase keeps up to 100 revisions per file (Quickbase limits), so if old versions matter, pull those too.
Mind the API rate limits: about 100 requests per 10 seconds per user token on the RESTful API (Quickbase: rate limiting). A large attachment pull can take hours. Run it overnight.
Getting history out
"History" means different things in Quickbase:
- Log fields (text fields with Log Entries turned on) keep their history inside the field, so it comes out with the export.
- Audit logs can be downloaded as CSV by realm admins, seven days at a time, and how far back you can go depends on your plan (Quickbase: downloading audit logs). Field-level data change logs only exist if someone turned them on for that app, and they don't track formula or summary fields (Quickbase: tracking data changes).
- Backups won't fill the gap. A "Table CSV" restore excludes attachments and schema, and "Restore to Copy" doesn't copy users, roles or attachments (Quickbase: back up and restore).
Download the audit history you need before your account closes. After that, it's gone.
Step 4: Map each part to the new system
Write the map before anyone builds. One line per item from your inventory.
- Tables become database tables. Relationships become foreign keys. Lookups become joins, and summary fields become totals the database calculates.
- Formula fields become code. Each one is rewritten as a calculation. Formulas only run on Quickbase, so they're translated, not copied. Drop the ones nobody uses.
- Reports and dashboards become screens. Rebuild the ones people actually open first.
- Forms become pages that work on desktop and phone. Form rules become validation and screen logic.
- Roles become permissions. Map each role to table, record and field rules. Write down who should see salary, cost or customer fields, then test it with a real login for each role.
- Pipelines and Automations become workflows and scheduled jobs. Each trigger becomes an event in the new system, and each step becomes code. Steps that only existed to work around a platform limit can usually go.
- Code Pages become regular pages in the new app.
- Integrations get reconnected with new credentials. Retire every old user token at cutover.
Step 5: Rebuild
You have three real options.
Another no-code platform (Power Apps, Airtable, Smartsheet, Zoho Creator and others). You or a partner rebuild every app, formula and workflow in the new tool, and you rent it the same way. Good if your team wants to keep building. Our comparison covers the tradeoffs with dated prices.
A developer or dev shop. You get custom software, usually owned by you. Timelines vary with scope, and after launch changes typically go through the developer's queue, billed hourly or on a retainer. Ask any shop who makes changes after launch, how fast, and whether you get the code.
A rebuild you own, with an agent team that stays. That's what we do at Alakazam Labs. Our migration agent teams read your Quickbase app, map every table, formula, report, form, role, Pipeline, automation and Code Page, and rebuild it as custom software you own. Our people check the agents' work while we build. A typical app takes about 3.5 weeks: built and data moved by week 1.5, then two weeks of fine-tuning with your team. Bigger moves with several connected apps take longer; Appalachian Field Service's took about a month and a half.
Whichever you choose, rebuild in the order your team works: the screens people use every day first, admin screens last.
Step 6: Check the data
- Record counts. Compare every table's count in the new system to the counts you wrote down in Step 2. They must match, or you must know why.
- Spot checks. Pick 20 records per important table, including your oldest, your newest and your messiest. Compare every field side by side.
- Formula results. For each rewritten formula, compare its output to the value in your export. A mismatch means a bug in the rewrite, or a quirk in the original worth asking about.
- Attachments. Count the files per record and open a sample.
- Permissions. Log in as each role and confirm what's hidden is hidden.
- Run both systems side by side for a short period. Have a few people do real work in the new app while Quickbase stays the record. Compare the end-of-day numbers people care about, like open jobs, invoices out and hours logged.
Step 7: Cut over
- Pick the date well ahead of your Quickbase renewal, on a quiet day of the week, never at month-end.
- Freeze changes. From a set time, nobody edits Quickbase. Turn off Pipelines so they don't write to old data. Run a final delta export of anything changed since your main export.
- Train people before the date, not on it. Short sessions per role, using their own data. Name one go-to person per team.
- Have a rollback plan. Keep Quickbase read-only, not cancelled, for at least a few weeks. Decide in advance what would make you roll back and who makes that call.
- Switch the integrations and retire the old user tokens.
- Then cancel, once you've downloaded everything you might need: the last full export, attachments and audit logs.
Step 8: After launch, decide who fixes things
This is the question most migration plans skip. In Quickbase, your builders made changes themselves. Whatever you move to, decide now:
- Who fixes a bug on a Tuesday morning?
- How does a staff member ask for a new field or report, and how fast does it happen?
- Who approves changes before they go live?
- Who has the code and the data if you part ways with whoever built it?
How it works with us: the agent team that built your software stays with it. You or your staff ask for a change in plain words, inside the app, and it gets built. You set the rules: changes go live straight away, after your approval, or on a test copy first, whichever you want. You set the rules for what they change, and expert help is there whenever you want it; ongoing care is a paid service, scaled to your team. You own the code and the data, and any developer can work on it, so you can leave us too.
At Appalachian Field Service's launch week, 80 people filed 350 tickets, and the agent team resolved every one in 3 days, 160 of them in the first 7 hours (case study).
A realistic timeline
| Phase | What happens | Typical single app, with us |
|---|---|---|
| Decide and review | Costs, goals, whether to leave at all | Day 1, free review call |
| Inventory and map | Every table, formula, report, role, Pipeline and integration documented | Week 1 |
| Rebuild | Database, screens, permissions, workflows, integrations | Week 1 to week 1.5 |
| Data move and checks | Export, import, counts, spot checks, attachments | By week 1.5 |
| Fine-tune and run side by side | Your staff use it on real data and ask for changes | Weeks 1.5 to 3.5 |
| Cutover | Freeze, final delta, training, switch | A date you pick, ahead of renewal |
| After launch | Your agent team keeps making changes when asked | Ongoing |
A typical app takes about 3.5 weeks. Bigger moves with several connected apps take longer; Appalachian's took about a month and a half, and its employees kept working throughout. If you do it yourself, the phases stay the same, but plan for each to take longer, especially formulas and Pipelines.
If you want us to do it
Appalachian Field Service ran on Quickbase for almost 10 years. They no longer pay Quickbase about $55,000 a year, their mission-critical data came across, and their people kept working through the move (case study).
Here's what we offer, plainly:
- A free app review. A call with the people who'd do the work. If staying on Quickbase is the better call, we'll tell you.
- A rebuild, quoted after the review. ROI usually happens around 6 to 8 months. No per-user fees. Hosting is on your own server (free) or ours (quoted), and you pay your own AI plan (Claude, ChatGPT, Gemini or Grok), billed by the AI company with no markup.
- Or build it yourselves. From $1,500, we install K2 and get your agent team built and running, and you build from there.
When we're not the right fit: if your bill is small and steady, if your team wants to keep building in no-code every day, or if no one can give the move a few hours a week, this guide and a lower-cost platform may serve you better.
Your software runs on K2, which is free to download. Get a free review of your Quickbase app.
Questions people ask
Can I export my whole Quickbase app?
Not as a working app. Table exports give you your records as CSV, tab-delimited or XML, with formula fields as their current values and no file attachments. On the Enterprise plan, the Solution APIs export a text description of the app (QBL), which Quickbase says "is not the source code of a solution". Reports, formulas, forms and Pipelines have to be rebuilt in the new system (Quickbase help docs, checked October 21, 2026).
How do I export Quickbase data to Excel?
Open a report and select Download report as CSV, then open the file in Excel. For a whole table, use More > Import/Export > Export a table to a file and pick CSV. Report totals and averages aren't exported, and neither are file attachments. Quickbase's Excel Add-in can also import reports as sheets, using one integration read per 1,500 records.
How do I get file attachments out of Quickbase?
The standard export leaves them out. Quickbase's docs give two routes: a Pipeline that loops over records with files and uploads each one to SharePoint, OneDrive, Google Drive or Box, or the API, which downloads each file by table, record, field and version. Put the record ID in each file name so you can match files to records later.
How long does a Quickbase migration take?
With us, a typical app takes about 3.5 weeks: built and data moved by week 1.5, then two weeks of fine-tuning with your team. Bigger moves with several connected apps take longer; Appalachian Field Service's took about a month and a half. Doing it yourself follows the same steps, but plan for each to take longer, especially formulas and Pipelines.
What happens to our Pipelines and formula fields?
They only run on Quickbase, so they're rebuilt, not copied. Formula fields become calculations in code, and Pipelines and older Automations become workflows and scheduled jobs. Copy every formula's text and list every Pipeline's trigger and steps before you start, and use "Where is this field used?" to find what depends on each field.
Who makes changes after we leave Quickbase?
Decide before you move. With a dev shop, changes usually go through their queue. With us, the agent team that built your software stays: your staff ask in plain words, you set whether changes go live straight away, after your approval, or on a test copy first. Expert help is there whenever you want it, and with ongoing care our people keep checking the agents. You own the code and the data, so any developer can work on it.
Quickbase is a trademark of Quickbase, Inc. Other product names are trademarks of their owners. We are not affiliated with or endorsed by any of them. Prices and product facts are as checked on the date shown at the top of this page and may change.