Migrate from BrightWork to Jira

BrightWork Projects map directly to Jira Projects as the primary container. We preserve project name, description, start and target end dates, and the assigned Project Manager by mapping to the Jira Project Lead field. Each Jira Project is created with the appropriate project type (Team-managed or Company-managed) agreed during scoping. Project Area subsite hierarchy is evaluated at scoping to determine whether the customer wants a flat Jira project-per-project or a parent-child structure using Epics.

BrightWork Programs group multiple Projects and roll up to a portfolio-level Status Report. We map each Program to a Jira Project, with its child BrightWork Projects becoming Jira Epics within that Project. The portfolio-level Status Report migrates as a Confluence page attached to the Jira Project, or as a Jira Issue with a summary description and linked child Epics, depending on the customer's reporting workflow preference identified during scoping.

BrightWork Tasks map to Jira Issues with the appropriate Issue Type. Parent-child task relationships from BrightWork migrate as Jira Epic-Story-Task-Subtask hierarchy using the parent-link field. Standard fields (name, start date, due date, percent complete, priority, assignee) map to Jira summary, Due Date, Assignee, Priority, and custom fields for numeric percent-complete where Jira's native sprint-based tracking model requires adjustment. Predecessor links from BrightWork map to Jira Dependencies using the parent-link or a custom dependency field.

Each RAID category in BrightWork becomes a Jira Issue with a matching label (raid-risk, raid-assumption, raid-issue, raid-dependency). Structured fields on each RAID entry—severity, owner, status, description—map to Jira Priority, Assignee, Status, and custom text fields. Risks with probability and impact ratings map to custom Jira number fields. We preserve the RAID entry ID as a custom Jira field for traceability back to the source SharePoint list.

BrightWork custom fields are SharePoint list columns defined per Project Area. We export the column definitions for each Project Area, consolidate duplicate field names across projects, and flag type conflicts (same field name with incompatible SharePoint column types) for customer resolution before import. Compatible custom fields become Jira custom fields of the matching type. Type conflicts are resolved by the customer choosing a target type, with the understanding that data may be truncated or reformatted.

BrightWork stores files in SharePoint document libraries within each Project Area. We extract binary files and re-upload them to Jira as attachments on the corresponding Issue or Project. Folder structure from the SharePoint document library is preserved as a Jira comment referencing the original file path for audit purposes. Attachments exceeding Jira's size limits are flagged for customer review before migration.

BrightWork time entries logged against Tasks migrate to Jira Work Logs on the corresponding Issue. Hours, date, and user association transfer directly. Jira requires an active Sprint or Issue to accept work logs; we map time entries to their parent Issue and skip any entries referencing deleted or unmigrated tasks with a warning in the reconciliation report.

SharePoint document libraries within a BrightWork Project Area are exported as file sets. We attach documents to the corresponding Jira Project as file attachments where the files are project artifacts (deliverables, specs). Documents that represent knowledge-base or process content are migrated to Confluence pages linked from the Jira Project, at the customer's preference during scoping.

BrightWork aggregates project status into portfolio-level Status Reports with RAG (Red, Amber, Green) indicators, milestone summaries, and executive commentary. We extract the latest Status Report per Program and create a Confluence page with structured sections matching the original report layout. The Confluence page is linked from the Jira Project's description or sidebar. If the customer does not have Confluence, we create a Jira Issue with the summary in the description and link it to all child Projects.

BrightWork Project Areas are SharePoint subsites serving as project workspaces. Where the destination Jira project already covers the work scope, we collapse the area structure into the parent Project record and apply a label for area-of-origin traceability. If multiple Project Areas represent distinct work streams within one Program, we split them into separate Jira Projects under the Program-level Project.