Migrate from Breeze to Jira

Breeze Projects map directly to Jira Software Projects. Each Breeze Project name becomes the Jira Project name. We preserve the project description, start date, and target end date as Jira Project properties. If the customer has multiple Breeze workspaces, we map each to a Jira Project by default and note whether consolidation into a single Jira Project with Epic groupings is preferable during scoping.

Breeze Tasks map to Jira Issues. The mapping to Story or Task issue type depends on the customer's intent: Tasks that represent deliverables or backlog items map to Jira Story; Tasks that represent discrete actions map to Jira Task. We use the Breeze task priority (High, Normal, Low) to set Jira Priority (High, Medium, Low, or Lowest). The Breeze due date maps to Jira Due Date field. Assignee resolves by email match against Jira User records.

Breeze Subtasks map to Jira Subtask issues, which sit one level below a parent Jira Story or Task. Breeze supports exactly one level of subtasking, matching Jira's Subtask pattern. If the destination Jira project has Subtasks disabled, we map Subtasks to linked Jira Tasks with a custom parent-reference field and flag the change for admin review. Parent-child ordering is preserved by setting the Jira subtask ordering at import time.

Breeze per-project custom fields require pre-migration schema reconciliation. We detect field name collisions across Breeze projects (same field name existing as text in one project and dropdown in another) during export scoping and build an explicit type map per project. These maps drive Jira Custom Field creation in each destination project before data import begins. Type conversions (Breeze text to Jira text field, Breeze dropdown to Jira single-select) are applied during the transform phase.

Breeze Tags are flat label-style identifiers attached to Tasks with no hierarchical structure. By default we map Tags to Jira Labels (Issue > Labels field), which are flat and per-issue. If the customer uses Tags as team-level or project-level categorisation rather than per-task labels, we recommend Jira Components as the destination and configure Components per Project during migration scoping. The customer chooses the strategy during discovery.

Breeze Time Entries (billable hours, duration, date, user) map to Jira Worklog entries on the migrated Issue. Jira Software Standard and Premium tiers include time tracking natively; Free tier requires a time-tracking app from the Marketplace. Worklog author resolves by matching the Breeze time entry user email to a Jira User. If the customer used Breeze time entries for billing rather than estimation, we flag Worklog visibility settings so that billable hours are visible to the correct Jira project roles.

Breeze attachments are stored in Breeze's file system and referenced by URL in the API. We export the attachment URL, filename, size, and upload date. The actual files must be downloaded from Breeze separately via the file export process. For Jira, we write the attachment metadata record pointing to the URL as an external link if the file has not been re-hosted. If the customer migrates files to a cloud storage location before migration, we update the Jira attachment reference to point to the new location.

Breeze Users are referenced on Tasks and Time Entries by email, name, and role. We extract the full user roster from Breeze and match each assignee by email against Jira User records in the destination instance. Any Breeze user without a matching Jira User goes to a reconciliation queue for the customer's admin to provision. If Jira user provisioning uses SSO (Atlassian Access or an external IdP), we flag that the admin must pre-create or sync users before assignee resolution can complete.

Breeze task statuses (To Do, In Progress, Done, Archived) per project map to Jira Status values within a Jira Workflow. We extract the per-project status schema from Breeze during scoping and create a Jira Workflow with corresponding statuses for each destination project. Breeze status ordering maps to Jira status category (To Do, In Progress, Done). If the customer has custom Breeze statuses beyond the default set, we document them during scoping and the customer's Jira admin confirms the target workflow configuration before migration.

Breeze task priority (High, Normal, Low) maps directly to Jira Priority values. We use the Breeze priority value to set the corresponding Jira Priority on each Issue. If the customer has custom priority levels in Breeze, we map them to the nearest Jira standard priority during scoping and flag the mapping for review.

Breeze does not expose task-level comments via its public REST API. We cannot programmatically export comment history. If comments are important to the customer, we advise manual export via Breeze's in-app CSV export or screenshot workflow before migration. We flag this gap during scoping and note that any comment context will need to be reattached manually in Jira after migration, or preserved in a shared document linked from the Jira Issue description.