Migrate from AGILITY to monday Work Management

Agility Projects map directly to monday.com Workspaces as the top-level container. The Workspace is created first, and all child Boards inherit its permission scope. Project-level custom fields from Agility map to Workspace-level custom fields or to a configuration board with a single Item representing the project settings.

Agility Iterations (with start date, end date, status, velocity) have no native monday.com equivalent. We map each Iteration to a Group within the project board, add custom date columns for Start and End, a status dropdown for Active/Closed/Planning, and a number column for velocity. This preserves the iteration calendar and cadence for retrospective planning but requires manual sprint ceremonies to be conducted in monday.com's native meeting tools or calendar integration.

Agility Stories map to monday.com Items on the relevant board. Story fields (title, description, status, points, assignee, priority, iteration) map to Item name, description (rich text), Status column, Numbers column (story points), People column, Priority column, and the Iteration Group respectively. Parent-child story hierarchy is preserved by placing child Stories as Items in the same Group or as Sub-items of the parent Story.

Agility Defects share the primary work item schema with Stories but add severity, detected-in-iteration, and resolution fields. We map them to Items on the same or a dedicated defect board, with severity mapped to a Status value or a dedicated Priority column, detected-in-iteration mapped to the Iteration Group assignment, and resolution as a text column or sub-item. The Defect-to-Story linkage is preserved as a Sub-item relationship or as an Item linked via the Relations column.

Agility Tasks are child work items belonging to Stories or Defects. We map them to monday.com Sub-items of the parent Item, preserving estimated hours (Numbers or Duration column), assignee (People column), status (Status column), and the parent linkage. Sub-items do not have their own custom columns in monday.com; the parent Item's column structure applies, which is a constraint for Task-specific fields that have no Story-level equivalent.

Agility Issues are standalone defects tracked in Fact.Issue with their own schema distinct from primary work items. We map them to Items on a dedicated Issues board, preserving status, priority, and custom fields. If the customer uses Issues to track stakeholder requests separately from Defects, we create a separate board with a Status column that mirrors the Agility issue lifecycle.

monday.com has no native test management object. Test Sets from Agility cannot migrate as structured test assets. We create a dedicated board with Items representing Test Sets, map Test Set name and description, and flag the test steps, expected results, and step attachments for manual recreation or a third-party test management integration (TestRail, Zephyr). The customer receives a written inventory of all Test Sets and their member Test Cases for rebuild planning.

Agility Test Cases carry steps, expected results, and custom fields stored in Fact.Test. We map Test Case title and description to an Item, but step-level structure (Given/When/Then, expected result, step attachments) cannot be expressed in monday.com's flat Item schema. Step sequences migrate as a text description column; detailed step recreation is documented separately. Test Case-to-Iteration assignment maps to the Iteration Group on the test board.

Agility custom fields exist on most asset types with types including checkbox, date, text, number, and drop-down. We map them to monday.com Board Columns of the equivalent type. The critical distinction: Agility's Data Mart uses the field's System Name as the column identifier, not the display label. We extract both System Name and display label during discovery and generate a dual-key mapping table so that destination column names match the intended semantic meaning rather than the raw internal identifier.

Agility stores binary attachments with a separate OID registry from the work item JSON payload. We export attachments independently during the first pass, upload them to monday.com per Item during the second pass, and use a cross-reference table (Agility OID to monday.com file ID) to re-associate the file references. This two-pass approach prevents orphaned attachment links. Note that Agility's attachment metadata (file size, upload timestamp, author) does not have a direct monday.com field equivalent and is preserved as a note on the file upload step in the cross-reference log.

Agility user records (display name, email, role, team membership) map to monday.com User records. We resolve by email match during migration. If the destination uses a directory-based SSO (Google, Microsoft Entra ID), user provisioning happens through the directory rather than manual invite; we flag any Agility user without a matching directory account for admin provisioning before or during migration.

Agility Comments attached to work items carry author, timestamp, and body. We map them to monday.com Updates on the Item, preserving the author attribution and timestamp. Updates in monday.com display in reverse-chronological order on the Item's main view. Rich text in Agility comments is converted to monday.com's supported subset of formatting.