Migrate from Backlog to Microsoft Project

Backlog Projects map 1:1 to Microsoft Project. Each Backlog project becomes a separate Project for the web project or .mpp file. Project name, description, and start date migrate directly. Backlog's project-level settings (notification preferences, issue order defaults) do not have a Microsoft Project equivalent and are documented for the customer to reconfigure manually.

Backlog Issues map to Microsoft Project Tasks. The Backlog issue title becomes Task Name; description HTML migrates to Task Notes. Backlog status (Open, In Progress, Resolved, Closed) maps to Microsoft Project Task Status values (Not Started, In Progress, Completed) with the customer's status matrix defined during scoping. Assignee migrates to the Resource field by email lookup.

Backlog Issues that have subtasks become Microsoft Project Summary Tasks. The parent issue's Start and Due Date frame the summary task, and each subtask becomes a linked child Task with Start and Finish dates derived from the subtask's own dates or the parent's date window. WBS numbering is generated during migration to reflect the hierarchy depth.

Backlog Versions with planned release dates map directly to Microsoft Project Milestones. The Version name becomes the Milestone task name; the planned release date becomes the Milestone date. Issues assigned to the Version retain their task-milestone linkage through a custom field or task flag so the customer can filter by release in Microsoft Project.

Backlog Custom Fields on Premium and Enterprise plans map to Microsoft Project custom fields. Text fields become Text custom fields; date fields become Date custom fields; numeric fields become Number custom fields; dropdown lists become Drop-Down List custom fields with the same options. Accounts below Premium have no custom fields to map. We pre-create the destination custom field schema during schema design before any data loads.

Backlog Tags are free-form labels with no hierarchy. We migrate tags as a multi-value Text custom field on the task or as a comma-separated entry in Task Notes, depending on the customer's preference. If the tag count is high, we offer to consolidate the most-used tags into a Drop-Down List custom field during scoping.

Backlog Wiki pages at the project level migrate to Project Notes on the Microsoft Project summary task or to a linked SharePoint page. Backlog's custom wiki markup converts to plain text or Markdown. Complex Backlog macros with no Microsoft Project equivalent are flagged for manual review. Wiki page hierarchy flattens; nested pages become individual notes entries with indentation preserved as a best-effort text formatting.

Backlog Users map to Microsoft Project Resources. We resolve each Backlog user by email to a Resource record in the destination. Resource type (Material vs. Work) defaults to Work. Max Units reflects the user's assignment availability. Teams in Backlog map to Microsoft Project Team Build or are held as a custom field for the customer to configure in the resource management settings.

Backlog file attachments on issues migrate as URL references in the Task Notes field. The actual files are out of scope for migration. We document the file URLs and the project-issue context so the customer's admin can relocate files to SharePoint or a document management system and update the links post-migration.

Backlog's burndown chart data is derived from issue completion rates against the sprint or milestone timeline. We do not migrate the chart visualization. We preserve the underlying issue completion events and sprint dates as data that feeds a rebuilt burndown report in Microsoft Project using the custom fields and Excel export. The customer or a reporting consultant rebuilds the visual burndown chart as a separate step.

Git and Subversion repositories linked to Backlog projects do not migrate to Microsoft Project. Source control history is external to Microsoft Project's data model. We deliver a written inventory of all repository-issue linkages (commit SHAs, branch names, PR titles) as a reference so the customer's engineering team can re-link code references in their source control platform post-migration.

Backlog notification settings (email digest preferences, in-app alert rules, per-user notification overrides) are user-specific runtime state that does not port between systems. We do not migrate them. We deliver a written notification configuration guide that maps the customer's Backlog notification rules to equivalent Microsoft Project notification settings and Microsoft Teams channel delivery options.