Migrate from Taiga to Microsoft Project

Taiga Projects map 1:1 to Microsoft Project files or Project Online projects. We extract the project name, description, creation date, and any project-level custom attributes from the JSON export and create a corresponding MS Project file (MPP) or Project Online project entry. Project-level wiki pages in Taiga are flagged for SharePoint document migration outside the standard scope because MS Project does not have a wiki object.

Taiga Milestones map to MS Project milestone tasks. The milestone name, start date, and finish date migrate, with the MS Project task set to the milestone flag. Where Taiga milestones contain user stories, we link those tasks as children of the milestone task using the WBS hierarchy. Sprint date ranges (start, finish) become task constraints or fixed-duration summary rows in MS Project depending on the customer's scheduling preference.

Taiga Epics map to MS Project summary tasks at the top of the WBS hierarchy. We preserve the Epic color tag and description as custom fields (Text1 and Text2) in MS Project. Epic status (open, in progress, completed) maps to a custom Task Status field. If the destination project has multiple epics, we nest them as top-level summary rows with their user stories as indented children.

Taiga User Stories map to MS Project tasks. The story subject becomes the task name; description migrates to the task notes field in rich text. Story points (numeric) migrate to a custom Number field (StoryPoints__c). Taiga status (new, in progress, ready for test, completed) maps to a custom picklist field MS_StoryStatus. Assignee from Taiga maps to the MS Project resource assignment once the resource pool is configured.

Taiga Tasks map directly to MS Project tasks. Task subject becomes task name. Taiga custom attributes on tasks (per-project, varying schema) are extracted and mapped to MS Project custom fields, with type conversion: text enums become picklists, dates become date fields, numeric values become number fields. Due date from Taiga maps to the MS Project task deadline or finish date depending on configuration.

Taiga Issues (standalone bugs and tracked work outside the sprint backlog) map to MS Project tasks with a custom IssueKind field carrying the Taiga issue type (bug, question, enhancement, others). Severity and priority from Taiga map to MS Project custom fields. Issues without a milestone reference are placed in an Unscheduled section at the bottom of the MS Project task list.

Taiga wiki pages export as Markdown with a named page tree structure. We do not migrate wiki pages as a structured object because MS Project has no wiki object and Project Online's wiki relies on SharePoint. We export the Markdown content and deliver it as a folder of .md files with a filename matching the page tree path, for the customer to upload to the linked SharePoint document library or OneDrive. Links between wiki pages require manual re-linking post-migration.

Taiga custom attributes are defined per project on User Stories, Tasks, and Issues. We extract every distinct custom attribute across all projects, classify by data type (text, enum, number, date, checkbox), and create corresponding MS Project custom fields in the destination project. Enumerated values from Taiga become MS Project custom picklist entries. If the same custom attribute name exists across multiple Taiga projects with different value sets, we flag this for the customer's PM to consolidate or scope per project.

Taiga project members map to MS Project resources. We extract the member name, email, and role name from Taiga. MS Project resources are created from the member list, with the Taiga role mapped to a custom Resource field (Role__c). MS Project resource calendars (working time, PTO) are not populated from Taiga because Taiga has no resource calendar data. We flag this as a manual configuration step for the customer's admin.

Taiga free-form tags on User Stories, Tasks, and Issues are extracted as string values. Tags that are used consistently (present on more than 5 artifacts) are migrated as a custom MultiValue text field in MS Project. Tags used inconsistently (ad-hoc labeling) are delivered as a reconciliation report for the customer's PM to decide whether to promote to a formal custom field or drop. MS Project does not have a native multi-select label system, so the custom field approach is the closest structural analog.

Taiga stores file attachments as references with a media URL. If the Taiga instance is cloud-hosted and accessible via URL, we download the files and attach them to the corresponding MS Project task using the file attachment feature. For self-hosted Taiga, attachment URLs may point to internal storage paths that are not publicly accessible; in these cases we deliver a file manifest with the original file path and recommended upload instruction for the customer's admin.