Migrate from AGILITY to Jira

Agility Projects map directly to Jira Projects. Each Agility Project OID is preserved in a custom Jira field agility_oid__c for traceability. Project metadata including name, description, owner, and team assignments migrate as Project-level fields. If the customer uses multiple Agility Teams within a single Project, we discuss whether to consolidate into one Jira Project with multiple Boards or create separate Jira Projects per Team.

Agility Iterations (with start date, end date, status, and velocity settings) map to Jira Sprints. We preserve the iteration name, start/end dates, and status (Active, Closed, Planning) as Sprint fields. If Agility uses multiple concurrent Iterations, these map to multiple active Jira Sprints within the same Project. Historical sprint velocity metrics from Agility become custom fields on the Jira Sprint for reporting continuity.

Agility Stories map to Jira Story issues within the destination Project. The Story title, description, acceptance criteria, story points (if numeric), status, and priority migrate directly. Parent-child relationships to Epic or parent Story in Agility become Jira Epic links or parent Story links. Custom fields on the Story use the System Name-to-Jira field mapping generated during discovery. Stories without a direct Jira equivalent are mapped to the closest Issue Type during scoping.

Agility Defects map to Jira Bug issues. Defect-specific fields (severity, detected-in-iteration, resolution type, steps to reproduce) migrate to Jira Bug fields or custom fields of equivalent type. The Defect-to-Story parent relationship maps to the Jira Bug's parent Epic or linked Story. Defects with no severity equivalent in Jira's default configuration become custom Jira priority or severity fields that we configure before import.

Agility Tasks (child work items belonging to Stories or Defects) map to Jira Sub-Tasks linked to their parent Story or Bug. Task fields including assignee, estimated hours, remaining hours, and status migrate directly. If the customer's Agility uses Tasks as standalone work items rather than children, we map them to Jira Task issues at the same level as Stories. Parent-child linkage is reconstructed using the Agility work item OID preserved in agility_oid__c.

Agility Test Sets aggregate Test Cases and generate Fact.PrimaryWorkitem records in the Data Mart. They map to Jira Test Cycles (Xray) or Test Executions (Zephyr) depending on the customer's Jira add-ons. The Test Set name, description, assigned tester, and execution status migrate. If the customer does not have a test management add-on installed, Test Sets are mapped to Jira Epic or Label for manual test management configuration post-migration.

Agility Test Cases (with steps, expected results, and custom fields) map to Jira Test Case records under the corresponding Test Cycle or Project. Step-level data decomposes into Jira's test step structure with the Given-When-Then format if the destination supports it. Test Case status from Agility (Draft, Approved, Active) maps to Jira test status values. Any fields that exist in Agility Enterprise but have no Jira equivalent are flagged in the mapping document for manual recreation.

Agility Issues are tracked in Fact.Issue and behave like standalone Defects with their own schema distinct from primary work items. They have status, priority, assignee, and description fields. We migrate them as first-class Jira Issues or as Story-type issues depending on the customer's Jira project configuration. Issue-specific fields (issue-type classification, external reference) migrate to custom Jira fields.

Agility custom fields (checkbox, date, text, number, drop-down) on any asset type map to Jira custom fields of the matching type. The critical mapping is System Name to Jira field: the Agility Data Mart generates column names from the field's System Name, not its display label. During discovery we extract both the System Name and display label and generate a dual-key mapping table. Without this, destination field matching silently fails and data lands in the wrong columns or is dropped.

Attachments in Agility are stored as binary assets with a separate OID registry from the work item JSON payload. We run a two-pass workflow: first, we export the work item data and attachment OID list; second, we upload attachments to Jira (using the Jira REST API attachment endpoint), capture the Jira-generated attachment IDs, then update the cross-reference table mapping Agility OID to Jira attachment ID. Finally we re-associate the attachment with the parent work item. This prevents orphaned attachment references. Jira's attachment size limit is 256 MB per file; we flag any Agility attachments exceeding this during discovery.

Agility user records (display name, email, role, team membership) map to Jira Users. We resolve users by email match against the Jira destination instance. Active Directory integration in Agility can source users externally; we detect whether Jira will use local user management or directory-based provisioning (Atlassian Access, Google Workspace, Okta, Azure AD) and align the migration accordingly. Users without a matching Jira account are held in a reconciliation queue for the customer's admin to provision before record import.

Comments on Agility work items (author, timestamp, body) migrate as Jira Comments on the corresponding Issue. Author attribution is preserved by resolving the Agility user email to the Jira User account. Comment timestamps are preserved as the Jira comment creation date. Rich-text comments from Agility are converted to Jira's Wiki markup or kept as plain text depending on complexity. Comments on Test Cases, Defects, and standalone Issues all migrate with their parent work item.