Migrate from Braid to Jira

Braid Projects map to Jira Projects. The Jira project type (Team-managed or Company-managed) is determined during scoping based on whether the customer plans cross-project reporting. Braid project metadata including name, status, dates, and client association migrate as Jira Project properties and the Project Description field. Archived Braid projects map to Archived Jira projects. Jira project roles (Admins, Members) are provisioned from Braid project team members.

Braid Resources map to Jira Users. We match by email address and map the Braid capacity settings, multi-location flags, and skill tags into Jira User properties and custom fields. Any Braid Resource without a matching Jira user goes to a reconciliation queue for the customer's admin to provision. Inactive Braid Resources map to Jira users with Jira Access licenses rather than product licenses.

Braid Clients are organizational entities that own engagements. Jira does not have a native Client object. We map Braid Clients to Jira Project names and the Project Lead field, or to Jira Components if multiple Braid projects share the same Client and the customer wants to filter reporting by client. Client contact details migrate as custom fields on the Jira Project.

Braid Time Entries map to Jira Issue Worklogs. Each worklog records the hours, date, billable flag, and description against the Jira Issue that represents the Braid project task. We preserve the Braid billable flag in a custom field braidf_billable__c on the worklog since Jira's native worklog has no billable property. Approval status from Braid is noted in the worklog description but cannot enforce an approval workflow in Jira. Time entries spanning multiple Braid project tasks are disaggregated into individual worklogs per Jira Issue.

Braid custom fields on Projects map to Jira project properties or Jira Issue custom fields depending on whether the custom field applies to the project level or to individual tasks. We run a pre-migration discovery pass to enumerate all Braid custom field names, types, and picklist values. Unsupported Jira field types (long-text,richtext without specific formats) are flagged and mapped to the nearest Jira equivalent. Custom field schema is deployed to Jira before record import begins.

Braid custom fields on Resources map to Jira User properties or custom User fields. Not all Jira Cloud plans expose custom User fields; we verify the customer's Jira edition during scoping and fall back to project properties if User custom fields are not available. Any Resource custom fields that cannot map to Jira User fields are documented as requiring a post-migration rebuild.

Braid employee schedules and shifts represent availability and allocation against Projects. Jira has no native scheduling or capacity view. We map Braid schedule assignments to Jira Labels (braidf_schedule__c) on Issues or to Sprint membership where the customer uses Scrum boards. The customer should evaluate Jira Marketplace apps such as Structure or Atlas for resource capacity visualization post-migration; we document this in the handoff inventory.

Braid multi-location tags on Resources and Projects migrate to Jira Labels (braidf_location__c) or Jira Components. The mapping type depends on the customer's reporting needs: Labels work for filtering and board grouping; Components work if the customer wants to group Issues geographically within a project.

Braid budget-versus-actual records and billing visibility have no native Jira equivalent. Jira Software does not include financial models, billing, or revenue recognition. We flag these objects in the migration inventory, preserve the raw budget and actual figures in a written data file for the customer's records, and document the Jira Marketplace apps (Expensify for Jira, Tempo Timesheets with billing, or custom ERP integrations) that can restore this capability. Revenue recognition settings are not migrated because Jira cannot host them.

Braid workflows tied to project status triggers, time-entry approvals, and client billing milestones have no Jira Automation equivalent that preserves the PSA business logic. We document every active Braid workflow in the migration handoff with its trigger, conditions, and actions, and recommend Jira Automation rules or third-party workflow apps to restore equivalent automation. The customer's admin rebuilds these post-migration.