Migrate from Airtable to Jira

Each Airtable base maps to a Jira project. We consult the customer on the right project type: Team-managed projects for smaller, self-contained teams; Company-managed projects for cross-functional work requiring shared configurations. Base-level metadata (name, description, creation date) migrates as the project name, key prefix, and description. Multi-base migrations where the customer wants separate projects per base require Jira project provisioning before record import begins.

Airtable tables map to Jira Issue Types within the target project (Bug, Story, Task, Epic, or custom). If a table represents an entirely different work domain, it maps to a separate Jira project instead. The mapping decision is made during scoping: tables sharing the same workflow states map to issue types within a single project; tables with independent workflows map to separate projects. We pre-create all issue types and their associated field configurations before importing any records.

Airtable records map directly to Jira issues of the target issue type. The record Name field becomes the Jira Summary. All standard field types—text, number, currency, date, checkbox, single/multi select, URL, email, phone, and rating—map to their Jira equivalents. We use Jira's Bulk API for large record sets, chunking inserts to avoid timeouts and setting the project and issue type on each record before submission.

Airtable linked records between tables export as arrays of record IDs. In Jira, we convert these to Issue Links (blocks, relates to, depends on) or store the referenced record ID in a custom Jira text field depending on the relationship semantics. If Airtable linked records represent a parent-child hierarchy, we use Jira's parent Epic-Story link or a custom hierarchy custom field. We flag any circular reference loops detected during the transform and resolve them with a one-level flattening approach.

Airtable formula fields evaluate server-side and the API returns only the computed result, not the formula definition. During migration, formula field values land in Jira as static custom field values with no live recalculation. We flag every formula field in the scoping report, note its Airtable table and expression, and recommend the customer document the logic for rebuilding as a Jira Calculated field or Automation rule post-migration. Cross-table reference formulas require the referenced table to migrate first so that lookup values are available.

Airtable attachment fields store files on Airtable's CDN and export as signed URLs. We generate an attachment manifest CSV mapping record IDs to filenames and CDN URLs. Jira's API accepts file attachments uploaded as multipart form data and associates them with issues by issue key. Files must be re-downloaded from the manifest URLs and re-uploaded to Jira; we do not automatically transfer file binaries. Jira's per-file size limits (10 MB on Standard, 50 MB on Premium and above) apply, and files exceeding this threshold require a separate upload strategy.

Airtable single-select fields map to Jira custom fields of type Select (radio group or single select) with options preserved. Multi-select fields map to Jira multi-select custom fields. We create the Jira custom fields and populate the option lists before importing records so that field references resolve on insert. Any Airtable option value that does not map to a Jira option is flagged during the scoping review and resolved by the customer before migration.

Airtable lookup and rollup fields pull values from linked records and aggregate them. Because linked records denormalize during migration, lookup fields land as static text values in Jira custom fields with no live recalculation. Rollup aggregations (SUM, COUNT, AVERAGE, etc.) are computed during migration time and stored as static Jira number fields. If the customer needs live rollup behavior in Jira, we document the requirement for a Jira app (such as ScriptRunner or a native automation) post-migration.

Airtable collaborator fields export as user email and name pairs. We resolve these against the Jira destination instance's user directory by email match. Collaborators without a matching Jira user are flagged in a reconciliation report and held in a queue until the customer's Jira admin provisions the missing users or confirms the user should be skipped.

Airtable Views (Grid, Kanban, Calendar, Gallery, Timeline, Gantt) are presentation-layer constructs with no direct Jira equivalent. We export view-level settings—column order, filters, sorts, and groupings—as a written view inventory document. The customer uses this to configure Jira Board filters, JQL queries, and dashboard gadgets that replicate the view logic post-migration.

Airtable automations are not accessible via the public API and do not migrate. We audit every automation before migration and deliver a written automation inventory listing each automation's trigger (record created, field changed, scheduled), conditions, and actions with recommended Jira Automation Rules equivalents. The customer's Jira admin rebuilds automations post-migration using this document as a specification.