Migrate your Backlog data

Projects are the top-level container in Backlog. Every issue, repository, wiki, and Gantt chart belongs to a project. We migrate all projects 1:1 including project-level settings, descriptions, and archived status. Project count limits are enforced by plan tier (1 for Free, 5 for Starter, 100 for Standard, unlimited for Premium and Enterprise) — we validate against the current plan during scoping.

Issues are Backlog's primary work unit — analogous to tasks or tickets. They carry a status, priority, assignee, category, version, milestone, and custom fields. We preserve all standard fields, the full description text, and parent-child links where issues are grouped under an epic or feature.

Subtasks are a dedicated issue type nested under a parent Issue. Backlog enables subtasking from the Starter plan onward. We maintain the parent-child relationship during migration and map subtask status independently from the parent issue.

Custom Fields are introduced at the Premium plan tier and do not exist on Free, Starter, or Standard plans. We detect whether the source account has custom fields configured and map them to equivalent custom fields in the destination. If the destination does not support custom fields natively, we encode them as structured JSON properties on the issue record.

Tags are free-form labels that can be applied to Issues across Backlog. There is no tag hierarchy. We migrate tags as a flat list against each issue and reconstruct tag sets in the destination.

Backlog users are invited per space and assigned roles. We map each user to a corresponding user in the destination or flag them as inactive if the user account is disabled. User display names, email addresses, and timezone settings are preserved.

Teams are Backlog groups that can be assigned to issues. We preserve team memberships and team-issue assignments during migration, mapping to equivalent group or team objects in the destination where supported.

Git and Subversion repositories are project-scoped. We migrate repository references and pull request metadata, but the actual source code is out of scope for typical data migration. Pull request titles, descriptions, reviewers, and comments are migrated; actual commit history is not transferred.

Wiki pages live at the project level and support structured content. We migrate the page content and hierarchy. Backlog uses its own wiki markup — we convert to plain text or the destination's supported format, preserving headings, lists, and links.

Pull requests are linked to Git repositories and carry titles, descriptions, reviewers, comments, and status. We migrate the PR metadata and discussion threads. The diff and actual code are out of scope.

File attachments on issues and wiki pages are migrated by URL reference. We confirm the file storage limits for the source plan (100 MB on Free, 1 GB on Starter, 30 GB on Standard, 100 GB on Premium) and flag any attachments that would exceed the destination's limits.

Gantt charts are derived from issue start dates, end dates, and dependencies. On the Standard plan, Gantt view is limited to 6 months of visibility. On Premium it is unlimited. We migrate the underlying issue date fields and reconstruct the Gantt in the destination from those fields.

Burndown data is computed from issue completion rates against the sprint or milestone timeline. We do not migrate the chart visualization itself but rather the underlying issue completion events and sprint date ranges needed to reconstruct the burndown in the destination tool.

Milestones (called 'Versions' in Backlog's UI) group issues for release planning. We migrate milestones with their planned completion dates and preserve the issue-milestone associations.

Notifications are user-specific runtime events in Backlog — read/unread state, email digest preferences, and in-app alerts. These are not portable between systems because they represent ephemeral user activity rather than durable data. We do not migrate notification history.