Migrate from Coda to Jira

Each Coda Doc maps to a Jira Project. The Doc title becomes the Project name; the Doc's description field (if any canvas text exists) maps to the Project description. Jira Projects require a Project Key (e.g., ENG, PROD, MKT) which we derive from the Doc title's initials or ask the customer to specify during scoping. Multiple Docs cannot share a single Project unless their schemas are compatible; divergent Docs generate separate Jira Projects.

Coda Pages inside a Doc have no direct Jira equivalent. Jira uses Issue Types within Projects, not a page-tree hierarchy. During scoping we assess whether Pages represent parallel workstreams (mapped to separate Epics or Stories in Jira) or are navigational groupings (to be discarded and replaced by Jira Project structure). Pages containing standalone content with no child Tables may map to Jira Epic records with the page title as the Epic summary.

Each Coda Table becomes a Jira Issue Type within the destination Project. The Table's column definitions drive the Jira Custom Field configuration. Jira enforces a typed field schema per Issue Type — a field that is a Select list in one Issue Type is not automatically available in another. We create a field schema per mapped Issue Type before any data migrates, using Jira's field configuration and screen schemes to control which fields appear at which workflow states.

Coda typed columns map to Jira fields by inferred type: Coda Text maps to Jira Text Field (single-line) or Jira Text Field (multi-line) depending on expected length; Coda Number maps to Jira Number field; Coda Date maps to Jira Date Picker; Coda Select maps to Jira Single Select (Option Set); Coda Multi-select maps to Jira Multi-select; Coda Person maps to Jira User Picker (single); Coda Attachments map to Jira File Attachment (handled separately). Coda formula columns are flagged as non-migratable; we document them for the admin to convert to Jira Calculated fields or automation rules.

Each Coda Row maps to a Jira Issue within the appropriate Issue Type. The Row ID is preserved as a custom field coda_row_id__c for traceability. Column values map to the corresponding Jira custom fields by position and type during the transform phase. Jira Issue summary defaults to the Row's primary text column (column A or the first non-system column) unless the customer specifies an alternate mapping during scoping. Jira issue keys (PROJ-1, PROJ-2) are assigned by Jira at insert time, not carried over from Coda.

Coda's Relation column type and cross-doc lookup formulas reference source and target Row IDs across Tables and Docs. We extract the source Row ID and the target doc/table/row reference from Coda's API, then create Jira Issue Link records (type: Relates To, Blocks, or Depends On chosen during scoping) linking the migrated Jira Issues. Unresolved cross-doc references (where the target row did not migrate) are flagged in the reconciliation report for the admin to handle manually post-migration.

Coda Select and Multi-select column options map to Jira Select and Multi-select option values. We extract all distinct option values per column and create corresponding Jira field options before row migration. Option ordering is preserved. New Jira options added after migration do not conflict with Coda-sourced values because Jira's option set is append-only for existing fields.

Coda canvas content outside of Tables — text blocks, headings, embedded content — has no direct Jira equivalent because Jira Issues are structured records, not free-form documents. We extract canvas content as structured JSON blocks and present it as a pre-migration inventory: text sections that belong in an Issue description are mapped to the Jira Description field; content that represents a knowledge article is flagged for Confluence as the destination. The admin decides placement during scoping.

Coda file attachments stored in Rows or Canvas are extracted via the Coda API using the authenticated session before any URL expiry, then uploaded to Jira as Issue Attachments via the Jira REST API. We preserve the original filename and a reference to the source Coda Row ID in a custom field. Coda attachment URLs generated via CSV export expire immediately and cannot be used; we bypass CSV entirely for asset handling.

Coda automations are doc-scoped rule definitions with trigger/action pairs that execute inside Coda's runtime environment. They do not migrate to Jira Automation for Cloud because the trigger models differ fundamentally. We export every Coda automation rule (trigger type, conditions, actions, delay settings) as a written inventory document with a Jira Automation equivalent recommendation. The customer's Jira admin rebuilds each rule in Jira Automation for Cloud or ScriptRunner post-migration.

Coda formula columns that reference only values within the same Row (simple computed fields) can be replicated in Jira using Calculated Number or Calculated Text custom fields available on Premium and Enterprise plans. Cross-row formulas, cross-table lookups, and cross-doc references do not have Jira equivalents and are flagged in the formula inventory. We provide a per-formula assessment with complexity rating and replacement recommendation.