Migrate from BQE CORE to Jira

BQE CORE Projects map directly to Jira Projects. The Project name, description, status, start date, and end date migrate as Project metadata fields. CORE's project-level custom fields transfer to Jira Project properties or to a designated Epic as custom fields. When CORE projects contain multi-year fiscal data, we create a Jira Project for each CORE project and use the Jira Project key as the top-level identifier.

CORE Phase records map to Jira Epic issues within the destination Project. The phase name becomes the Epic summary, phase status maps to Epic status, and phase-level custom fields attach to the Epic. Sub-phases map to child Epics if the destination team uses a nested Epic model, or to Stories if they prefer a flatter hierarchy. We flag the mapping decision during scoping because A/E firms often have 4-8 phase levels while Jira's default hierarchy is Epic-Story-Task.

CORE tasks and sub-tasks within phases map to Jira Stories and Tasks. If CORE has multiple task levels, we flatten to the Jira two-level max (Story and Sub-task) by mapping the top-level task to Story and the sub-task to Sub-task. Task status, priority, assignee (resolved from Employee mapping), due date, and estimated hours migrate as typed Jira fields.

CORE Time Entries link to Projects, Phases, and Employees and carry billable/non-billable flags, hours, date, and custom field values. We create Jira Issues for each unique Time Entry if the destination team wants granular time records, or we aggregate by Project-Phase-week and write a custom field (e.g., hours_logged__c) on the corresponding Epic or Story. The billable flag maps to a Jira Labels value or custom checkbox field. We preserve the employee-user link by resolving the CORE Employee email to the Jira User account.

CORE Expenses (tracked per project with category, amount, date, and receipt reference) map to Jira Issues with custom fields for expense category (mapped to Jira Labels), amount (mapped to a Number field), currency (mapped to a Select field), and reimbursement status (mapped to a Status or custom Select). Receipt file references migrate as Jira attachment links or as a URL field pointing to the migrated file location. CORE expense categories require mapping to Jira-compatible label values.

CORE Employee records (name, email, cost rate, bill rate, security profile) map to Jira User accounts. We resolve CORE employees by email as the dedupe key. Cost and bill rates are permission-gated in CORE via the Allow read rate permission; if the API user lacks read access, rate values may be null or zero. We request elevated API credentials with rate visibility before extraction, or flag which employees have restricted rate access. Jira project role assignments are set based on the CORE security profile.

CORE Invoices (with line items referencing time/expense entries, status, and amounts) have no Jira equivalent. Jira does not include an accounting module, invoicing, or payment tracking. We export invoice records as a structured CSV and JSON handoff document that the customer's finance team imports into their destination accounting system (QuickBooks, Xero, NetSuite, or similar). Invoice PDFs migrate as file attachments for record completeness even without a native accounting destination.

CORE Vendor records (name, contact details, payment terms, AP account assignments) have no Jira equivalent. We export vendor records as a structured CSV and JSON handoff for import into the customer's chosen accounting system. Vendor contact information can optionally map to a Jira Contact custom field on a dedicated Vendor-Tracking project if the customer wants vendor management visible in Jira, but this is a configuration choice not a native object mapping.

CORE Chart of Accounts (account types, numbers, balances, and sub-account hierarchies) has no Jira equivalent. We export the complete account structure as a structured CSV for import into the customer's accounting system. Jira has no concept of financial accounts, GL entries, or AP/AR, so this data is documented and handed off rather than migrated.

CORE Custom Field definitions (label, type, length, UI type, optional custom list linkage) migrate to Jira custom fields of the closest type. Text maps to Jira Text Field, numeric to Number, currency to Number with currency metadata, date to Date Picker, dropdown to Jira Select. We create the Jira custom fields in the destination project before data import so field IDs are stable during the migration pipeline. Custom lists become Jira Options on the corresponding Select fields.

CORE Custom Field Values are stored as separate linked entities with entityId and entityType rather than on the entity record itself. We perform a two-pass extraction: first to collect all custom field values keyed by entityId, then a join pass to attach them to their parent records before writing to Jira. This adds processing time for datasets with high custom-field density but ensures complete records in Jira. Jira custom field values write to the corresponding field on the Issue.

CORE Fiscal Year definitions and any Migrated Fiscal Years created during onboarding have no Jira equivalent. Jira has no fiscal period concept. We export fiscal year boundaries and any Migrated Fiscal Year flags as a configuration document for the customer's finance team. If Jira Dashboards are used for financial reporting post-migration, the fiscal year boundaries are documented for filter configuration rather than migrated as data.