Migrate from AGILITY to Trello

Agility Projects map 1:1 to Trello Boards. Each Agility Project becomes a separate Trello Board with the Project name as the board title and the Project description migrated to the board description field. If the customer uses multiple Agility Teams within a Project, we create separate Lists within the board rather than separate Boards, unless each Team has a distinct board cadence that requires separation. Workspace membership in Trello maps to the Agility Project Owner and Team assignments.

Agility Iterations have no direct Trello equivalent. We reconstruct the iteration cadence by creating Trello Board Labels in the format 'Sprint N — Start Date to End Date' using Trello's label naming convention. Sprint status (Active/Closed/Planning) is appended to the label name. Teams that require full sprint planning features (backlog views, burndown, velocity tracking) are directed to the Planyway or Scrum for Trello Power-Up as a post-migration configuration step; we document the label scheme and recommend which Power-Up suits the team's cadence.

Agility Stories migrate to Trello Cards placed in the List representing the corresponding Story status (Backlog, In Progress, Done). Story points map to a Number-type Custom Field 'Story Points' on the board (Premium tier) or to a checklist item 'Story Points: N' inserted at the top of the card. The Story description migrates as the card description with rich text preserved where Trello supports it. Story priority maps to Trello Labels ('Priority: High', 'Priority: Medium', 'Priority: Low') using the Agility priority field values.

Agility Defects migrate to Trello Cards with a 'Defect' label applied to distinguish them from Stories. The severity field (Critical, Major, Minor, Trivial) maps to an additional severity label or to a Dropdown-type Custom Field 'Severity' on Premium boards. Defect status maps to the appropriate List. The detected-in-iteration information is preserved as a label or card comment noting the originating sprint. Defects without a parent Story are created as standalone Cards; Defects linked to a parent Story are placed in the same List and optionally cross-referenced via a card link.

Agility Tasks are child work items of Stories or Defects. In Trello, child Tasks migrate as Checklist items on the parent Card rather than as separate Cards. This preserves the parent-child relationship within the single-Card paradigm Trello uses. Each Checklist item captures the Task title, assignee (as '@mention' in the checklist item text), estimated hours (appended to the item name), and status (completed checkbox for tasks with status 'Done', unchecked for all others). Tasks that exceed the natural checklist scope of a single card (complex tasks with their own comments, attachments, or sub-subtasks) are flagged for the customer to convert to linked Cards rather than checklists.

Agility custom fields on Stories, Defects, and Tasks require type-aware mapping to Trello. Text fields migrate to Trello Text-type Custom Fields (Premium). Number fields migrate to Number-type Custom Fields. Date fields migrate to Date-type Custom Fields. Dropdown-type fields migrate to Dropdown-type Custom Fields. Checkbox fields migrate to Checkbox-type Custom Fields. Multi-select fields (not natively supported by Trello Custom Fields) are converted to a comma-separated text field or to multiple Checkbox fields per option. Standard-tier Trello limits boards to one Custom Field; Premium is required for full custom field migration. We flag Standard-tier boards during scoping and recommend upgrading before migration if custom field data is material.

Agility Issues tracked in Fact.Issue are standalone work items with their own schema. They migrate to Trello Cards with an 'Issue' label applied. The Issue priority and status fields map to card Labels and Lists respectively. Issues do not have a native Trello equivalent object — the Card-with-label pattern is the closest structural mapping. We flag this as a schema reduction and note it in the written inventory for the customer's admin to communicate to stakeholders who rely on Issue reporting.

Agility Test Sets aggregate Test Cases and have a schema that varies by AGILITY edition. Trello has no native test management object. We migrate Test Sets as Cards with a checklist named 'Test Cases' containing one checklist item per Test Case (title and expected result). Test Set status is stored as a label. Test Sets with step-level attachments cannot preserve those attachments in Trello's flat card model; attachments are added as card-level file attachments and noted in the migration log. This mapping is documented as a known data reduction from AGILITY's test management to Trello's card-based workaround.

Agility Test Cases carry steps, expected results, and custom fields. They migrate as Checklist items under the parent Test Set Card (see above). The step sequence number, description, and expected result are concatenated into the checklist item text. Custom fields on Test Cases (if available in the source edition) are stored as card comments on the parent Card. Trello does not support test case traceability, execution history, or pass/fail status natively; this is a known limitation documented in the migration scope.

Agility work item comments migrate to Trello Card comments. The comment author display name and timestamp are preserved in the Trello comment header. Comment body migrates as plain text. Rich text formatting in Agility comments is simplified to plain text with markdown-style emphasis where Trello supports it. If the original comment contains @mentions, we replace them with plain text since Trello comment mentions require the mentioned user to be a board member at migration time.

Agility attachment binaries are stored in a separate OID registry from the work item JSON payload. We run a two-pass migration: first, we export attachment binaries and upload them to Trello Cards via the Trello API attachment endpoint, capturing the destination-generated attachment URLs. Second, we re-associate the attachment URLs with the corresponding Card IDs using a cross-reference table built during discovery. Trello's attachment limits apply: 10MB per file on Free, 250MB on Standard and above. Files exceeding these limits are flagged for the customer to store externally (Google Drive, SharePoint) and link from the Card.

Agility user records (display name, email, role, team membership) map to Trello Workspace members. We extract distinct owner and assignee references from all work items and match them by email to Trello Workspace members. Any Agility user without a matching Trello Workspace member is held in a reconciliation queue for the customer's admin to provision before Card import begins, because Trello @mentions and Card assignments require an existing Workspace member. Active Directory-sourced users in Agility are flagged if the destination Trello Workspace uses a different identity provider.

Agility Environments are simple name/description records referenced by Test Sets and Defects. Trello has no native environment object. We create Trello Labels in the format 'Env: [environment_name]' on relevant boards and apply them to the Cards that reference the environment. This is a stub mapping — environments without Cards referencing them are noted in the migration log but not otherwise represented in Trello.

Agility Requests tracked in Fact.Request represent incoming work or stakeholder asks with their own custom field set. They migrate to Trello Cards with a 'Request' label. Request custom fields are mapped using the same custom field strategy as Stories and Defects (Premium Custom Fields or Labels). Requests without a parent relationship to a Story or Defect are created as standalone Cards in the board's 'Backlog' or 'Incoming' List.