Moving Related Quickbase Tables by CSV Without Losing the Relationships

Someone asked in this community thread about handing five related Quickbase tables to another team as CSV files. Their questions were whether the parent/child relationships would survive the import into a fresh app, and whether formulas, summaries and lookups would break.

Short answer: the relationships can come over, as long as you export the IDs and import the tables in the right order. Formulas, summaries and lookups don't travel in a CSV. You rebuild them in the new app, and once the relationships are back the summaries and lookups fill in again by themselves.

The whole trick is this. In the new app you can't import into Record ID#, so the old record numbers need somewhere else to live. On each parent table you add a numeric Old ID field, make it the key field, and import the old Record ID# into it. Child records still carry the old parent number in their reference column, so Quickbase matches each child to the parent whose Old ID is that number.

I ran the whole process in a sandbox app with three levels (Customers, Projects, Tasks) before writing this up, including switching the keys back at the end. The results are in the "What I tested" section below.

Why the links break if you just import the files

In Quickbase, a child record points to its parent through a reference field (usually named something like Related Customer). That field stores the value of the parent's key field, which is Record ID# unless someone changed it.

When you export a child table, the Related Customer column holds the parent's old Record ID#, say 14. In the new app, Sarah Lee's customer record gets a brand-new Record ID#, maybe 1. If you import the child rows as-is, Related Customer = 14 points at whatever record happens to be number 14 in the new app, which is either nothing or the wrong customer.

You can't fix that by importing 14 into Record ID#. Quickbase doesn't let you import into Record ID# or the other built-in fields (Date Created, Date Modified, Record Owner, Last Modified By). So you give the old number a field of its own and point the relationship at that field for the duration of the import.

Step 1: Export each table with its IDs

For every table you're moving:

1. Open the table and choose More > Import/Export.
2. Pick Export a table to a file, choose the table, and pick Comma Separated Values (.csv).
3. Open the file and check that it contains:
   • Record ID# on every table that is a parent of something.
   • The reference field column on every child table (Related Customer, Related Project, and so on). This column holds the parent's old Record ID#.

There's also an Export data-entry fields to a file option that leaves out calculated fields. That gives the receiving team a cleaner file, but whichever option you use, make sure Record ID# and the reference columns made it into the CSV. Those two are what make the rest of this work.

Name the files so the receiving team can tell what's what, for example customers.csv, projects.csv, tasks.csv. If a table is too large to export in one go (the compressed file has to be under 150 MB), export it in chunks from reports.

Also write down for each table:

• Which tables are its parents, and which reference column points to each one.
• Every formula field, with its formula text.
• Every summary field (what it counts or totals, and any filter) and every lookup field.
• The field types, especially for numeric, date, user and multiple-choice fields.

That list goes with the CSVs. It's what lets the other team rebuild the parts a CSV can't carry.

Step 2: Work out the import order

Draw the tables as a tree. A table can only be imported after every table it points to is already in. For the example in this guide:

1. Customers (no parents)
2. Projects (child of Customers)
3. Tasks (child of Projects)

With five tables the order might be something like Customers, then Contacts and Projects, then Tasks, then Time Entries. If one table has two parents, both parents have to go in before it.

Any table that is a parent needs an Old ID field, including a table in the middle that is both a child and a parent (Projects in this example). A table that is only ever a child (Tasks) doesn't need one.

Step 3: Build the tables in the new app

Do this before any data goes in.

1. Create each table and its regular data fields (text, numeric, date and so on). Match the field types from your list.
2. On each parent table, add a Numeric field called Old ID.
3. On each parent table, make Old ID the key field: go to Settings > Fields, check the box next to Old ID, select Set Key, and confirm. A key field has to be unique, which old Record ID#s always are.
4. Now create the relationships. In each child table, add the relationship to its parent. Because Old ID is the parent's key, the new reference field on the child (for example Related Customer) is set up to hold Old ID values.
5. Add any lookups and summaries you want now if you like. They will just sit empty until the data arrives.

The order of steps 3 and 4 matters. Set the key before creating the relationship, so the relationship is built on Old ID from the start.

Step 4: Import the parents first

For the top-level table (Customers):

1. Open the table and choose More > Import/Export, then Import into a table from a file, and pick customers.csv.
2. On the mapping screen, map the CSV's Record ID# column to Old ID.
3. Map the other data columns to their fields.
4. Set any columns for formula, lookup or summary fields to Do Not Import. Those fields are calculated, so there's nothing to import into.
5. Run the import and check that the number of records added matches the number of rows in the file.

Because you're importing into the key field, Quickbase may treat Old ID as the merge field and warn you that this is an update import. In a brand-new empty table that's fine: there is nothing to match, so every row is added as a new record.

Step 5: Import the middle tables, then the children

For Projects, which is both a child and a parent:

1. Map the CSV's Record ID# column to Old ID (because Tasks will point at it).
2. Map the CSV's old Related Customer column to the new Related Customer reference field.
3. Map the data columns, and set calculated columns to Do Not Import.
4. Import, and check the record count.

Then do the same for Tasks, mapping its old Related Project column into the new Related Project reference field. Tasks doesn't need an Old ID because nothing points at it.

As each child row comes in, Quickbase looks up the parent whose key (Old ID) equals the number in the reference column, and links them. You can see it working right away: lookup fields such as Customer Name on Projects fill in, and summary fields on the parent, like # of Projects, show the right counts.

Step 6: Switch the keys back to Record ID# (optional)

Once everything is in and the links look right, you can switch each parent table's key back to Record ID#. That way new records get the normal auto-numbered key and people don't have to type an Old ID for each new customer. (When you make your own field the key, Quickbase displays it as required on forms, which is one more reason to switch it back.)

1. Go to Settings > Fields on the parent table.
2. Check Record ID#, select Set Key, read the warning about relationships, and confirm.

Quickbase keeps the existing links when you do this. Here's what it actually does to each child table, which I confirmed in the sandbox:

• It adds a new reference field, named like Related Customer (ref), and fills it in on every child record with the parent's new Record ID#.
• It moves the relationship, its lookups and its summaries over to that new reference field, and puts it on the forms in place of the old one.
• It turns the old Related Customer field into a lookup of the parent's Old ID.

So after the switch you'll see two Related Customer fields on the child. The (ref) one is the real reference field now. The old one is just a read-only lookup showing the Old ID number, and you can rename it to something like Customer Old ID or delete it once you no longer need it. Keep the Old ID field on the parent for a while too. It's handy if someone later asks you to match a record back to the old system.

Step 7: Rebuild formulas, summaries and lookups

A CSV only has values. A formula column in the export is just the result it showed on the day you exported. You can't import into formula, lookup or summary fields, so:

• Formulas: recreate each formula field in the new app from the list you sent along. Field names in the new app need to match what the formula refers to, or the formula needs to be edited to match.
• Lookups: add them on the child table's relationship. They fill in immediately for every linked record.
• Summaries: add them on the relationship (count, total, and so on, with any filters). They calculate across the linked children right away.

Do this after the relationships exist and the data is in. Formula fields that reference lookups or summaries will then calculate against real data as soon as you save them.

Step 8: Hand over file attachments separately

File attachments are not exported with the table, so the files themselves have to be handed over another way and re-attached in the new app. Quickbase's help covers exporting attachments with pipelines if there are a lot of them. If you name each file with the record's old Record ID# (for example project-32-site-plan.pdf), the other team can match each file to its record using Old ID.

What I tested

In a sandbox app I created three new tables, Blog Demo - Import Customers, Blog Demo - Import Projects and Blog Demo - Import Tasks, and set up a CSV for each that looked like an export from another app, with gaps in the old IDs the way real data has them:

Customers and Projects each got a numeric Old ID field set as the key before the relationships were created, plus a Customer Name / Project Name lookup and a count summary on each relationship. Then I imported the files in order: Customers, Projects, Tasks.

Results after the import:

• Customers got new Record ID#s 1, 2 and 3, with Old ID 14, 22 and 37.
• Every project showed the right Customer Name lookup (Backyard and Kitchen under Sarah Lee and Priya Patel, Office Remodel and Warehouse under Mike Chen), and # of Projects on Mike Chen showed 2.
• Every task showed the right Project Name, and # of Tasks on Office Remodel showed 3.

Then I switched both parent tables' key fields back to Record ID#. Quickbase created Related Customer (ref) on Projects with the new values 1, 2, 2, 3, and Related Project (ref) on Tasks with 1, 1, 2, 2, 2, 3, 4. The old reference fields became lookups showing 14, 22 and so on. Every lookup and summary value stayed the same. I also added a new task with Related Project (ref) = 2 after the switch, and it linked to Office Remodel straight away.

Gotchas checklist

• Set the key before the relationship. If the relationship is built while Record ID# is still the key, the child reference field will expect new Record ID#s, and the old numbers in your CSV won't match.
• Import top-down. Parents, then children, then grandchildren. A child imported before its parent has nothing to link to.
• Middle tables need their own Old ID. Any table that something else points at needs one, even if it's also a child.
• Keep the numbers numeric. Old ID should be a Numeric field, and the CSV values should be plain numbers with no commas or spaces (12,345 can turn into two columns or fail to match).
• Watch for orphans. If the source data has a child pointing at a parent that wasn't exported (because it was deleted, or filtered out of a report), that child will come in with a reference value that matches nothing. Filter the child table for records where the lookup is blank to catch these.
• Verify counts. For every table, compare the rows in the CSV with the records added. Then spot-check a few parents: the summary counts should match the source app.
• Don't import into calculated fields. Set formula, lookup and summary columns to Do Not Import.
• Only one key per table. Quickbase doesn't support compound keys, so if a table's identity in the old system was a combination of fields, use the old Record ID# as Old ID instead.
• Existing data in the target table. This approach is for empty, fresh tables. If the target table already has records, changing its key field can disrupt existing relationships, so test on a copy first.
• User fields. If a column holds people, import into a User field. Quickbase can match email addresses to real users; plain names come in as placeholders you convert later.
• Attachments and formulas travel separately. Send the formula list and the files along with the CSVs.

A shorter version to send with the files

If you're the one handing the data over, a note like this saves the receiving team a lot of guessing:

Import order: Customers, then Projects, then Tasks. Before importing, add a numeric Old ID field to Customers and Projects and set it as the key, then create the relationships. Map each file's Record ID# column to Old ID, and map Related Customer / Related Project to the new reference fields. Formula, lookup and summary fields are listed in the attached sheet and need to be recreated. Attachments are in the attachments folder, named by old Record ID#.

That, plus the CSVs and the formula list, is everything they need to rebuild the app with every link intact.