Migrate from Backlog to Trello

Each Backlog Project maps to a Trello Board. We create the board in the target Trello Workspace, copy the project description into the board description, and set the board visibility (private, workspace, or public) based on the Backlog project's public/private setting. Project-level project managers and administrators map to Trello board Admins.

Backlog Issues map directly to Trello Cards. The Backlog issue title becomes the card name, the description HTML or markdown migrates as the card description, and the Backlog status (Open, In Progress, Resolved, Closed) maps to a Trello List name. We create the Lists on each Board based on the distinct Backlog status values present in that project. Assignee, reporter, priority, and due date migrate as card fields.

Backlog Subtasks map to Trello Checklists on the parent Card. The subtask title becomes a checklist item; subtask status (Open, Resolved) maps to checked/unchecked state. Subtask assignees do not have a native Trello equivalent — we preserve them in the checklist item name as a prefix (e.g., [Assignee Name] Fix login bug) and flag the limitation for the customer.

Backlog Categories within a project map to Trello Lists on the Board. If a Backlog project has multiple Categories, we create corresponding Lists. If no Categories exist, we create default Lists based on Backlog status values. Multiple Categories do not split into multiple Boards unless the customer requests it during scoping.

Backlog Tags migrate as Trello Labels on each Card. Tag names become Label names; we assign label colors by cycling through Trello's eight color options in order of first appearance. Duplicate tag names across projects result in duplicate labels on the same Board, which is Trello's expected behavior.

Backlog Milestones (called Versions in the Backlog UI) group issues for release planning. Trello has no native milestone concept. We map the milestone name to a Label with a distinct color and the milestone planned completion date to the card due date. If the milestone has no date, we set the label only and flag the absence of a date for manual review.

Backlog Custom Fields exist only on Premium and Enterprise accounts. Trello Custom Fields exist on Standard and Premium boards only. If the source Backlog account is on Premium or Enterprise, we detect all custom field definitions and map them to Trello Custom Fields by type: text maps to Trello text, number to Trello number, date to Trello date, single-select to Trello dropdown, and multi-select to Trello dropdown (Trello does not have a native multi-select field type). Free-tier Backlog accounts have no custom fields and this step is skipped entirely.

Backlog Wiki pages at the project level have no direct Trello equivalent. We extract each wiki page as plain text, preserve headings and lists, and attach the content to the most relevant Card (identified by a page-to-issue link or naming convention) as the card description. Standalone wiki pages with no issue link are attached to a dedicated Wiki Cards Board created for the migration. Backlog wiki markup is converted to plain text; complex macros and proprietary formatting are flagged for manual review.

Backlog Git and Subversion repositories are project-scoped and linked to Issues via commit hashes and pull request titles. Trello has no native code integration. We extract the repository URL and any issue-to-commit associations and deliver them as a lookup table. The customer configures a GitHub or Bitbucket Power-Up post-migration if they want live commit-to-card linking. Source code itself is out of migration scope.

Pull request titles, reviewers, and comment threads from Backlog's Git integration migrate as card description text with PR links preserved as URLs. The PR diff and actual code are out of scope. We deliver a PR migration summary with links grouped by Card for the customer to review.

Backlog Users map to Trello Members. We match by email address and resolve active Backlog users to Trello Workspace members. Inactive or disabled Backlog users are mapped to a Trello inactive member group and flagged for the customer's admin to reassign or deactivate. Role mapping (Backlog Admin, Project Manager, Reporter, Viewer) does not translate directly to Trello board roles (Admin, Member, Collaborator) — we assign the most permissive role that preserves the user's ability to view and edit migrated cards.

Backlog Teams are groups that can be assigned to Issues. Trello Workspaces are the top-level container. If the customer has multiple Backlog Teams, we create one Trello Workspace per team or consolidate into a single Workspace with multiple boards, depending on scoping preference. Team memberships are preserved as Workspace membership lists.