Migrate your AGILITY data

Projects are the top-level container in digital.ai Agility. The API exposes them as standalone assets with a stable OID. We migrate them 1:1 and map their Owner and Team assignments to the destination's equivalent construct.

Iterations have start/end dates, cadence settings, and status (Active/Closed/Planning). We preserve the iteration calendar and map velocity metrics where the destination supports them.

Stories are primary work items with points, status, and a rich set of custom fields. Custom field Data Mart columns use the System Name as the column identifier — we capture both the display name and system name to avoid silent field mismatches at import.

Defects share the primary work item schema with Stories but include severity, detected-in-iteration, and resolution fields. We handle the Defect-to-Story relationship mapping based on the destination's issue model.

Tasks are child work items belonging to Stories or Defects. They have assignees, estimated hours, and status. We preserve parent-child linkages and reconstruct the task breakdown in the target system.

Test Sets aggregate Test cases and generate Fact.PrimaryWorkitem records in the Data Mart. The schema varies between Agility editions and the destination test management tool — we map Test Set membership and test step detail individually.

Test Cases carry steps, expected results, and custom fields. They exist in the Fact.Test Data Mart. We export the full step structure and map to the destination's test case object, flagging any unsupported step formats.

Issues are tracked in Fact.Issue and behave like standalone defects. They have a distinct schema from primary work items. We migrate them as first-class objects with their own status and priority fields.

Custom fields exist on most asset types and support checkbox, date, text, number, and drop-down types. The Data Mart column name is derived from the System Name, not the user-facing label. We extract both and generate a dual-column mapping table so destination fields are matched by display name while internal references use system names.

Attachments are stored as binary assets with a separate OID registry. We export them independently from the JSON mapping file and re-associate them post-import using the source OID-to-destination ID cross-reference table. Large attachments may require chunked transfer.

User records include display name, email, role, and team membership. Active Directory integration in Agility can source users externally — we detect whether the destination will use local or directory-based user provisioning and map assignments accordingly.

Comments are attached to work items and carry author, timestamp, and body. We migrate comments as a child collection of the parent work item and preserve the author attribution.

Environments are referenced by Test Sets and Defects. They are simple name/description records that may not exist in all destination systems — we flag and optionally skip or stub them.

Requests are tracked in Fact.Request and represent incoming work or stakeholder asks. They have their own custom field set distinct from primary work items.