Migrate from Allegra to Jira

Allegra Items map to Jira Issues based on Item type classification. We query the Allegra schema to determine Item type values and map them to Jira Issue Types: general Items become Jira Stories or Tasks, Items classified as bugs become Jira Bug issues, and parent Items become Jira Epics if a parent-child hierarchy is detected. The Jira Project, Issue Type Scheme, and Workflow are configured before migration begins.

Allegra attributes belong to Items natively and differ from form fields. We discover all Item attributes via the Allegra schema endpoint, determine their data type (string, number, date, picklist), and create corresponding Jira custom fields of matching type (Text Field, Number Field, Date Picker, Select/Picklist). Attributes with picklist behavior map to Jira custom field options. This is the most critical mapping step because skipping the attributes-versus-fields distinction causes silent data loss.

Allegra form fields belong to input forms rather than Items. We extract field definitions separately from attributes and map them to Jira project-level custom fields. Form field values stored against Items are resolved at migration time by matching the form submission to the Item record and populating the corresponding Jira custom field. Some form fields may not apply to Jira if they capture metadata relevant only to Allegra's form submission model.

Allegra stores file attachments on disk under the ALLEGRA_HOME directory, not in the database. We export both the Allegra database and the ALLEGRA_HOME attachment directory simultaneously, preserve the directory structure mapping each file to its source Item record, and upload files to Jira via the Jira REST API attachment endpoint (POST /rest/api/3/issue/{issueIdOrKey}/attachments). Jira Cloud attachments are stored in Atlassian's file store; Jira Data Center attachments are stored in the attachments table. We verify each file attachment succeeds and report any orphaned files (files without a matching Item record) for customer review.

Allegra custom lists with list entries (accessible via GET /v2/lists in the REST API) map to Jira custom field option sets. For single-level picklist behavior, we create Jira Select custom fields and populate the options from Allegra list entries. For hierarchical lists, we create Jira Cascading Select custom fields where the parent level maps to the primary list and the child options map to the dependent list entries. We verify option consistency during migration and flag any Item references to list entries that no longer exist.

Allegra users and their roles are exported from the database. We map user accounts to Jira users by matching email address as the unique identifier. Role assignments in Allegra (Admin, Project Manager, Team Member, Viewer) map to Jira global permissions and project-level roles (Administrators, Developers, Users, Viewers). Any Allegra user without a matching Jira account enters a reconciliation queue for the customer's admin to provision before the Item migration phase begins.

Allegra can import Microsoft Project and Project Libre MPP files with task recognition. We parse the MPP structure to extract the WBS hierarchy, task names, start dates, end dates, duration, and resource assignments. The task tree maps to Jira Issues: top-level tasks become Epics, mid-level tasks become Stories or Tasks, and leaf-level tasks become Subtasks. We preserve the parent-child relationships as Jira issue links (Parent > Sub-task). Jira does not have native MPP import, so this mapping delivers the closest equivalent structure.

Allegra projects map to Jira Projects as containers. Each Allegra project becomes a Jira Project with its own key (prefix), Issue Type Scheme, and Workflow. If the Allegra project uses a specific methodology (Agile, Waterfall, hybrid), we configure the corresponding Jira project template (Scrum, Kanban, or Bug Tracking) during project creation. Projects are created before Items to serve as the parent container during issue import.

Allegra Item comments map to Jira Issue Comments via the Jira REST API. We preserve the original comment author (mapped to Jira user), timestamp, and comment body. Comment ordering is maintained by setting the created field to the Allegra comment timestamp. Rich text from Allegra comments is converted to Atlassian Document Format (ADF) for Jira Cloud compatibility.

Allegra Item status values map to Jira Issue Status values within the Jira Workflow. We discover all status values in the Allegra schema and map them to corresponding statuses in the Jira Workflow. If Allegra uses custom status labels, we create custom status categories in Jira (To Do, In Progress, Done) to preserve the customer's status semantics. Status transitions map to Jira Workflow transitions.

Allegra workflow rules, notification triggers, and assignment rules are documented as part of migration discovery but are not migrated to Jira Workflows as code. Jira Workflows use a different XML-based definition model from Allegra's rule engine. We deliver a written inventory of every Allegra workflow rule with its trigger, conditions, and actions, mapped to equivalent Jira Automation rules or Jira Workflow Post-Functions. The customer's Jira admin or an Atlassian partner rebuilds these post-migration.