Migrate from Trello to Jira

Each Trello board maps to one Jira Project. We provision the Jira Project using the board name as the Project Key (first 9 characters, uppercase) and map board visibility (public/private) to the Jira project's permission scheme. Atlassian recommends keeping board count below 15,000 per workspace for migration performance; we flag any workspace exceeding this and work with the customer to archive inactive boards before migration begins.

Trello lists map to workflow status values within the Jira project's default workflow. List order is preserved as the sequence of status values. We configure the Jira workflow to include each list name as a distinct status (To Do, In Progress, Review, Done) and map archived lists: in software space they are skipped; in business space archived lists and their cards are imported with Done status.

Trello cards map to Jira Issues. Card title becomes Issue Summary; description (Markdown) migrates as Jira text. Due dates and start dates migrate to Due Date and Start Date fields. Card cover colors migrate as Jira label or comment with color metadata. We map card position within list to Jira priority or a custom ranking field if the customer uses ranked backlog views.

Trello checklists (multiple named lists per card, each with completion states) map to Jira sub-tasks. In Jira business space, the native importer converts checklists to sub-tasks automatically. In software space, the importer does not transfer checklists at all. We detect the destination Jira space type during scoping and apply either the native import path or our own sub-task generation from the Trello API checklist data to ensure no checklist data is lost in software-space destinations.

Custom Fields graduated from Power-Up to core API in 2023, but older boards may store Custom Field definitions and values in card pluginData rather than the structured API response. We detect which storage mechanism is in use during discovery and apply the appropriate extraction method. Legacy pluginData extraction is less reliable and may require a post-migration manual audit of field values. Core API Custom Fields (text, number, date, checkbox, dropdown) map to Jira Custom Field equivalents with type-matching.

Trello labels (color + name per board) migrate to Jira Labels on each Issue. We preserve the label name and append the color code as a tag suffix if the customer needs color metadata for post-migration reporting. If the customer uses Jira Components as a parallel categorization layer, we map Trello label groups to Components and individual labels to Component names.

Trello card members map to Jira Assignee. Trello allows unlimited members per card; Jira allows one assignee per Issue by design. We flag every card with more than one member during scoping. The customer's admin chooses the strategy: map the first member only, map to the Jira project's Lead field, or configure a Jira multi-user picker custom field and migrate all members to it. We do not arbitrarily drop secondary assignees without customer direction.

Trello stores file attachments on Amazon S3 with per-plan size limits (10MB Free, 250MB Enterprise). We download all raw attachments at migration time and upload to Jira, which has a 10MB per-file ceiling on standard attachments. Files exceeding 10MB are flagged for the customer's admin to host externally (Confluence, SharePoint, S3) with a link inserted into the Jira Issue description. Board-level attachments migrate to the Jira project's description or a linked Confluence page.

Trello card comments migrate to Jira Issue comments with the original author and timestamp preserved. We extract comment text and Markdown formatting, convert to Jira's comment format, and set the comment author by resolving the Trello member email to the Jira user account. If the destination Jira space is team-managed, user tags in comments appear as plain text if the importing user lacks admin permissions; we run as org admin to prevent this data loss.

A Trello Workspace maps to a Jira Organization (Atlassian Admin) or a collection of Jira Projects grouped under a single site. Multi-workspace configurations require separate Jira organizations or a single organization with projects partitioned by team. We document the workspace-to-organization mapping during scoping and configure the Jira org structure before migration begins.

Power-Up data is stored in third-party schemas inaccessible via the Trello API. We do not migrate Power-Up state. During discovery we generate a Power-Up inventory for each board identifying which Power-Ups are active, which data they contain, and what Jira or Atlassian Marketplace alternatives exist for the customer's admin to evaluate post-migration.