Migrate from ProjeQtOr to Jira

ProjeQtOr Projects map directly to Jira Projects. Each ProjeQtOr Project ID becomes a Jira project with a unique project key that must be alphanumeric, uppercase, and 1-10 characters. We extract the project key from ProjeQtOr's Project code field, validate it against Jira's naming constraints, and reserve the key before migration. Project description, status, and start/end dates map to the Jira Project description and date fields. Active ProjeQtOr projects map to active Jira projects; archived projects map to archived Jira projects if the destination supports archival.

ProjeQtOr Tasks map to Jira Issues using a type-split rule we define during scoping. Standard project tasks typically become Jira Stories or Tasks depending on the ProjeQtOr task type classification. ProjeQtOr issue and incident types split into Jira Bug Issues. Parent-child task hierarchy from ProjeQtOr maps to Jira's Epic > Story > Subtask hierarchy or to linked Issues with a 'Parent' link type. Planned work hours and actual work from ProjeQtOr map to Jira's Story Points, Time Tracking, or custom number fields depending on the customer's reporting needs. WBS numbering sequences are preserved in the Jira Issue Summary or a custom field for traceability.

ProjeQtOr Milestones map to Jira Fix Versions within the target project. Each ProjeQtOr Milestone with a target date and status becomes a Jira Fix Version (release) with the corresponding release date and released/unreleased flag. Milestones that are standalone and not tied to a specific project map to a Jira project we designate as the portfolio or program project, with the milestone name as the Fix Version name. If Jira Advanced Roadmaps is active (Premium/Enterprise), milestones can alternatively map to Plan milestones.

ProjeQtOr Resources representing team members map to Jira User accounts. We extract resource email addresses as the primary matching key. Resource capacity, calendar availability, and cost rates from ProjeQtOr have no direct Jira equivalent; we preserve them as Jira User properties or custom fields on the User record if the customer requires capacity planning. Resource skills and profile descriptions migrate to the Jira user profile or to a custom User field. Any ProjeQtOr Resource without an email (system or generic resource) is flagged for the customer to provision as a Jira user or consolidate into an existing named user.

ProjeQtOr Resource Allocations bind a Resource to a Task with a start date, end date, and daily assignment percentage. Jira does not have a native allocation object, so we map allocations to Jira's Assignee field on the Issue and Sprint assignment in the appropriate Jira Sprint. If the ProjeQtOr allocation has a percentage less than 100 percent, we store the original allocation percentage in a custom field on the Jira Issue. For Jira Premium/Enterprise with Advanced Roadmaps, allocation data can be represented as Resource Plans within a Plan.

ProjeQtOr Expenses capture project costs outside resource billing, including travel, software licenses, and contractor fees. Jira (standard project management tier) does not have a native expense object, so we map expense data to custom number and date fields on the parent Project or on a designated Jira Issue acting as an expense register. Expense category, amount, date, and VAT/tax amounts migrate as structured data. The customer chooses whether to display expenses as custom fields on the parent Project or as a separate Jira Issue with expense records attached.

ProjeQtOr Risks include probability, impact, mitigation plan, and owner assignment. We map these to Jira Issues using a dedicated Risk Issue type that we create in the destination project before migration. Probability and impact values map to custom select fields on the Risk Issue; mitigation plan maps to the Issue description. The ProjeQtOr Risk owner resolves to a Jira Assignee via the User mapping. If Jira Governance (Enterprise) is not available, Risk Issues are created in the same project as standard Issues with a custom field to distinguish them.

ProjeQtOr Issues and Incidents (including bugs, incidents, and change requests stored in a combined object) map to Jira Issues of type Bug or Task depending on the ProjeQtOr issue type classification. We extract issue type, priority, status, description, and attachments from ProjeQtOr and map them to the corresponding Jira fields. Jira requires a valid Project and Issue Type on creation, so the ProjeQtOr type-to-Jira-type mapping is applied before any Issue records are submitted via the API.

ProjeQtOr Document references stored as server filesystem paths require parallel file transfer to Jira's attachment storage location. We identify all Document records in ProjeQtOr, extract the corresponding files from the application server storage directory, and upload them to Jira using the Issue attachments endpoint or the Jira REST API. Attachment URLs in migrated Jira Issues point to the new Jira attachment location. Binary file content migrates as part of this parallel transfer; the file folder hierarchy from ProjeQtOr is preserved where Jira's attachment structure allows.

ProjeQtOr Versions track product releases linked to a project with a version name, number, status, and target date. We map these to Jira Fix Versions within the target project. ProjeQtOr version status (planned, in-progress, released, closed) maps to the Jira Fix Version released flag and release date. Version number from ProjeQtOr's versionName field becomes the Fix Version name, and any version description becomes the Fix Version description.

ProjeQtOr supports custom status workflows per object type with statuses defined in a workflow table. We extract the full set of ProjeQtOr statuses per object type and map them to Jira Status values (To Do, In Progress, Done) or custom Status values. Each ProjeQtOr workflow status gets a corresponding Jira status with the same name and color. Jira Status Categories (Todo, In Progress, Done) are assigned based on the ProjeQtOr workflow stage. The Jira Workflow scheme is configured to associate the correct statuses with the relevant Issue types before migration.