Airtable and Smartsheet are easy to start with, which is why so many studies began in them. This playbook covers what to export, how linked records, views and automations map to an EDC, how to run both systems in parallel, and how to cut over without losing history.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Inventory tables, views, forms and automations
One line each, with the owner
Export records and attachments
CSV per table, files in folders
Map fields to eCRFs and visits
Linked records become repeating rows
Build and test in the sandbox
Edit checks replace automations
Run in parallel on sample participants
Compare outputs field by field
Freeze, archive and cut over
One date, no entry in the old base
What to know first
Why move
A spreadsheet-database hybrid is a fine place to start a pilot or a registry: anyone can add a field, views make the data readable, and forms and automations cover simple workflows. The trouble starts when the same flexibility is applied to a regulated study. Anyone with edit rights can change a field type or delete a column. Activity logs and revision history exist in both tools, but they vary by plan and record who changed a cell more than why, and they are not designed as the controlled, append-only trail that an inspection expects. Signatures and approvals are workflow features, not electronic signatures with a legal meaning statement. There is no concept of an approved, locked form that live data must use.
The practical signs that it is time: a monitor asks how you know who changed a value, a funder or ethics board asks for audit trail evidence, more than one site starts entering data, or an analysis finds values nobody can explain. For a similar journey from other tools, see how to migrate from Excel spreadsheets, from Microsoft Access and from Google Forms and Sheets.
Check the plan details of your own Airtable or Smartsheet account before relying on any statement about its history or permission features; they differ by plan and change over time.
Data mapping
| In Airtable or Smartsheet | In Capture | Effort |
|---|---|---|
| Participant row or record (primary field) | Participant record with a site-level ID such as 001-0042 | Low |
| Linked records to a child table (medications, adverse events, labs) | Table section with repeating rows; each row carries its own audit trail | Moderate |
| Linked record to a lookup table (sites, drug names) | Dropdown or single-choice list | Low |
| Single select, multiple select, checkbox fields | Single choice, multiple choice, dropdown | Low |
| Number, currency, percent, rating fields | Numeric or linear scale fields with a unit and range | Low |
| Date and date-time fields | Date and time fields, with edit checks for plausible ranges | Low |
| Formula or rollup fields | Built-in calculated field where one exists (BMI, eGFR, QTc), or derive at analysis | Moderate |
| Views and filters (by status, by site) | By-site data filtering, exports with date-range filters, status overviews | Low to moderate |
| Form views and form responses | eCRF forms attached to visits; participant questionnaires through ePRO | Moderate |
| Automations and scripts | Not carried over; replace with skip logic, edit checks that raise auto-queries, or reminders | Moderate to high |
| Row comments and @mentions | Queries raised and answered on the field; archive the old comments | Archive task |
| Attachments | Store with the trial master file or source documents; do not re-upload as data | Archive task |
| Smartsheet sheets, Gantt and dashboards | Rebuild timelines in a project tool; study status comes from exports | Moderate |
Airtable and Smartsheet differ on terminology and on which features are plan-dependent. Map from your own base, not from this table alone.
The path
List each table or sheet, linked field, view, form, automation, script, integration and shared interface, and who uses it. This is the specification for the new build.
Export the revision history or activity log available on your plan and see what it holds. Decide what you can show an inspector about the period before the move, and note the gaps in a memo.
Export each table to CSV, keeping linked fields as readable values rather than record IDs. Download attachments into folders named by participant and field, and record file counts so you can check nothing is lost.
For each field record name, type, allowed values, unit, who enters it and at which visit. Convert free-text status fields into coded choices now, or you will clean them later.
Group fields by when and by whom they are collected: screening, baseline, each follow-up visit and event forms. Linked child tables become repeating rows.
Upload the field list or CSV to a draft form. Capture reads CSV, XLSX, PDF and DOCX and drafts questions, choices and units. Review every field; nothing is saved until you approve it.
Turn each automation into skip logic, an edit check (range high, range low, custom value) that raises an auto-query, or a reminder. Retire those nobody can explain and record why.
Enter the same sample of participants in both systems for one or two visit cycles. Compare exports field by field, log every difference and fix the form or the mapping.
Choose one date. Set the old base to read-only, export it with attachments, record the date and owner, and file it with the trial master file. No entry after that date.
Try it in the free sandbox with sample data. Nothing is saved until you approve it. No credit card.
The common sticking point
The pattern teams rely on most in Airtable and Smartsheet, a child table linked to a participant, maps to a table section. A participant can have any number of medications or events, and each row has a field-level audit trail with user, time, old value, new value and reason for change.
Row 2 of 3
Medication
CMTRTDose
CMDOSEFrequency
Start date
Auto-query: start date is after the visit date
Parallel validation
| Check | Method | Pass criterion |
|---|---|---|
| Record counts | Participants, visits and repeating rows in each system | Equal after allowing for documented exclusions |
| Field values | Join exports on participant ID and visit; compare each field | All differences explained and fixed, or logged |
| Derived values | Compare calculated fields with the old formula results | Agree within rounding; differences documented |
| Missing and out-of-range data | Count edit-check queries on the same data | New system flags what the old automations flagged, plus more |
| Attachments | File counts and names against the export log | Every file located, or exceptions listed |
| Roles and access | Who could see or change what in each system | No user has broader access than intended |
Keep the comparison files and the sign-off with the migration record.
Cutover
The audit trail in Capture starts at the first entry. History from before that date lives in the archived export, and the honest way to describe it is in a short migration memo: what was exported, when, by whom, what the old tool recorded about changes, what it did not, and how the two data sets are joined at analysis. If you migrate historic records into Capture rather than keeping them separate, state which records were loaded, from which export, and keep the original files.
Train users on queries before cutover: coordinators should answer a query rather than overwrite a value, and know that signatures and approvals now have a meaning attached. For cost planning see the pricing page; a Core study with setup by the Capture team at $0 is described there. If the move is part of a wider system switch, how to switch EDC vendors mid-study covers the data-continuity issues.
There is no direct import of a base. Export tables to CSV, build a field list and upload it; Capture's AI drafts the eCRFs for review. Nothing is saved until you approve it.
A child table linked to a participant becomes a table section with repeating rows, each row with its own audit trail. A linked lookup table becomes a dropdown or choice list.
Skip logic, edit checks that raise auto-queries, and reminders. Automations are not carried over, so each needs a written replacement.
Both are general-purpose tools. Whether a particular plan could be validated for a regulated study is a question for your quality team and the vendor. Part 11 controls such as field-level audit trails with reasons, and signatures with meaning, are what an EDC provides.
Download them with a log of counts, and file them with the trial master file or source documents. Do not treat attachments as data.
Yes, on a small sample for one or two visit cycles, comparing exports field by field before the cutover date.
Yes. The free sandbox has every feature with no credit card and no time limit. You pay only once you go live with real participants.
Yes. Capture is suitable for Phase 1, 2 and 3.
Keep exploring
Capture vs Airtable
The head-to-head comparison.
Capture vs Smartsheet
The head-to-head comparison.
Can you use Airtable for clinical trials?
What the tool can and cannot do.
Migrate from Excel spreadsheets
The same path from spreadsheets.
Replace a Microsoft Access database
Another home-built database.
eCRF builder
Forms, edit checks and templates.
Upload the exported field list to the free sandbox, add visits and test as a participant. No credit card, and you pay only once you go live.