Migrate from Redmine 3.3 to Microsoft Project

Each Redmine project becomes a single Microsoft Project file (for Project Desktop) or a Project Online project site. We extract the project identifier, name, description, public/private flag, and creation date from the projects table. Subprojects nest under parent projects in the Redmine project_hierarchy; we preserve this as a folder or enterprise pool structure in Project Online, or as a phase outline in a single Project Desktop file. Module enablement flags (wiki, forums, repository) have no direct Project equivalent and are flagged in the scope document for admin reference.

Redmine issues map to Microsoft Project tasks. The Redmine issue tree (parent_issue_id chain) is flattened into a WBS-compatible outline: we traverse the issue hierarchy breadth-first, assign each issue a WBS code prefix matching its project, and set Outline Number and Outline Level on the Project Task. Redmine status (New, In Progress, Resolved, Closed, Feedback) maps to a custom Task field or Status indicator since Project tasks have no status enum; we create a custom field redmine_status__c carrying the original value. Tracker (Bug, Feature, Support) maps to a custom text or flag field on the task. Start date and due date from Redmine become the task Start and Finish fields, with scheduling mode set to Auto or Manual depending on whether the customer relies on dependency-driven scheduling.

Redmine's done_ratio field (0-100 integer) maps directly to Microsoft Project's % Complete field. We preserve the value at migration time; Project Online and Project Desktop recalculate physical % complete based on actual work if the task is resource-assigned. Closed issues (done_ratio = 100) migrate with % Complete = 100 and Status = Complete.

Redmine issue relations (blocks, blocked by, relates to, duplicates, followed by, precedes) map to Microsoft Project task dependencies (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish). The relation_type field determines the dependency type: blocks and precedes map to Finish-to-Start (the most common); blocked by maps to Finish-to-Start in reverse direction. Redmine stores relation IDs as integers referencing the issues table; we resolve each integer to the corresponding migrated Task UID at migration time. Orphaned relations (target issue deleted or not migrated) are logged in a reconciliation report.

Redmine versions (milestones or release targets) within a project map to Microsoft Project milestone tasks. The version name becomes the milestone task name, effective_date maps to the milestone Finish date, and the status (open, locked, closed) maps to a custom field redmine_version_status__c. Versions with a null effective_date are flagged for the customer to supply a target date before migration. A milestone task has zero duration and is positioned at the version effective date in the project timeline.

Redmine time entries (hours, activity, spent_on, comments) map to Microsoft Project task actuals. For each task representing a Redmine issue, we aggregate all time entries for that issue into a Total Actual Work value (sum of hours). If the task has a resource assignment, we distribute the hours as actual work on the assignment. If no resource is assigned, the hours appear as task-level actual work with the entry-level detail preserved in a custom notes field on the task (activity name + comments). The Redmine spent_on date maps to the actual work date. We create a custom field total_hours__c carrying the aggregate for reporting.

Redmine users (firstname, lastname, email, admin flag) map to Microsoft Project resources. We create a resource for each user who appears as an assignee on any migrated issue. Email becomes the resource Initials or Windows Account field for Project Online integration with Microsoft 365. Redmine role assignments per project do not map to Project resource role fields natively; we create a custom field redmine_roles__c listing the original role names per project for audit. Resource calendars (working time) use the Project Standard calendar unless the customer provides a calendar export.

Redmine trackers (Bug, Feature, Support, Custom) are distinct issue types with independent workflows and custom field scopes. In Microsoft Project we create a custom enterprise or local task text field (e.g., Task Text1 labeled Tracker) and populate it with the tracker name for each migrated task. Tracker-specific workflows (status transition rules) have no Microsoft Project equivalent and are documented in the automation inventory as a rebuild item for Power Automate.

Redmine list-format custom fields store a numeric ID in the issue record, while the human-readable label lives in a separate possible_values table. We query the custom_field_definitions before processing any issue export, build an ID-to-label lookup table, and substitute display values when writing to Microsoft Project custom fields. If the custom field uses a finite set of valid values, we replicate the picklist in Project's custom field definition so the values appear as a dropdown. Multi-value list custom fields in Redmine map to a semicolon-delimited text string in the Project custom field.

Redmine stores uploaded files on the server filesystem under the files/ directory. We extract attachment metadata (filename, content_type, created_on, author_id) from the attachments table, download each file, and upload it to a designated SharePoint document library or Teams channel linked to the destination project. We then write a hyperlink on the corresponding Microsoft Project task pointing to the SharePoint or Teams file URL. Files with no reachable source path are logged in the attachment reconciliation report with the original Redmine URL.

Redmine project documents (title, description, category) have no direct Microsoft Project equivalent. We create a custom field documents__c on the project summary task containing a semicolon-delimited list of document titles and the SharePoint URLs where the customer stores them post-migration. Document content does not migrate; the customer either moves the files manually or creates a SharePoint library for the project and links it.