Migrate from Favro to Jira

Favro Cards map to Jira Issues based on a type-designation rule agreed upon during scoping. We preserve Card title as Summary, description as Description, assignee as Assignee (resolved by email against Jira User directory), due date as Due Date, and labels as Jira Labels. Priority maps from Favro's priority system (1-4) to Jira's Priority field (Highest, High, Medium, Low). The original Favro Card ID is stored in a custom field favro_card_id__c for traceability. If the Card appeared on multiple Boards, all originating Board names are added as Jira Labels to preserve the cross-team context that Favro's architecture natively supported.

Each Favro Board maps to a Jira Project, with Board name becoming Project name and Board description becoming Project description. Board columns map to Jira workflow statuses and the board's view mode (Kanban or sheet) determines whether we configure the project as a Kanban or Scrum project type in Jira. Board-level permission settings require manual recreation in Jira's permission scheme editor post-migration. For teams with fewer than 5-10 Boards, separate Jira Projects per Board is the recommended approach; for larger Board counts, we discuss aggregating related Boards into multi-project structures with shared components.

Favro Collections aggregate multiple Boards for management-level visibility and do not have a direct Jira equivalent. We map each Collection to a Jira Backlog by configuring Advanced Roadmaps (Premium) or by creating a dedicated Backlog view per Collection that includes all Projects mapped from the Collection's member Boards. For teams on Jira Standard, we use Jira Filters saved to the Backlog with the JQL scoped to the relevant Projects, achieving a similar aggregated view without requiring Premium licensing.

Favro Relations (Blocks, Blocked by, Relates to, Duplicate, etc.) between Cards map to Jira Issue Links using Jira's built-in link types. We extract the relation type from Favro's relation_type property and map it to the closest Jira Issue Link type (Blocks, is blocked by, relates to, duplicates). If the destination Jira project has non-standard link types configured, we align during scoping. Cards referenced by Relations that have not yet been migrated are held in a resolution queue and processed after parent records are created.

Favro Labels (name and color) migrate to Jira Labels with the label text preserved. Label colors do not have a native Jira equivalent, so we store the original hex color in a custom field favro_label_color__c on the Issue. Jira Labels are per-project by default but can be configured as global; we configure global Labels during Jira setup so that cross-project Card labels remain searchable across the entire instance.

Favro Comments migrate to Jira Comments preserving author (resolved by email), timestamp (created date and updated date), and comment body. Threaded replies maintain their parent-child structure via Jira's comment hierarchy. If comments reference other Favro Cards by @-mention or card ID, we convert those references to Jira @-mentions of the migrated Issue keys.

Favro file attachments migrate as Jira Attachments on the corresponding Issue. We extract the file URL from Favro (if stored externally) or re-upload the file blob. Attachments exceeding Jira's size limits (250 MB per file) are flagged during scoping. External URLs stored as Favro Card attachments migrate as a text field attachment_url__c rather than binary files.

Favro Custom Fields on Cards (text, number, date, dropdown) are mapped to Jira Custom Fields of equivalent type. We create the Jira custom fields before migration using the Jira REST API, assign them to the relevant Screen(s), and import values as part of the Issue migration. Dropdown (select) fields in Favro map to Jira Select (single choice) or Multi-select fields. Date fields map to Jira Date fields. Number fields map to Jira Number fields.

Favro guest accounts have restricted Board-level visibility that Jira does not natively replicate. We map each Favro guest to a Jira user account and assign them a project role scoped to the relevant migrated Projects. We flag all guest accounts during scoping so the customer's admin decides which external members receive full Jira access versus restricted project-level access. If the destination Jira has Atlassian Access (SAML SSO), we coordinate guest provisioning through the identity provider.

Favro users (owners, assignees) are resolved by email match against the Jira destination User directory. Any Favro user without a matching Jira account is held in a user reconciliation queue. The customer's Jira admin provisions missing users before record import resumes, as Jira requires a valid AssigneeId reference at time of Issue creation. Inactive Jira users are supported if the customer's permission scheme permits inactive user assignment.

Favro timesheet entries (available on Enterprise plan only) migrate to Jira Worklog records against the corresponding Issue. We map hours_logged to Time Spent (in Jira's format), work_date to Start Date, and user attribution to the Jira Author field. Worklog entries are migrated after the parent Issue to avoid orphaned records. Jira's billing and time tracking features vary by tier; we align the worklog structure with the destination's time tracking configuration during setup.