Migrate from Redmine to monday Work Management

Each Redmine Project maps to a monday.com Board within a Workspace. We use the Project identifier and description to seed the Board name and description. Subprojects create a separate Board within the same Workspace; the migration notes flag that monday.com's flat board model does not preserve parent-child subproject relationships natively, and the customer chooses whether to use board groups, board linking, or a separate Workspace to represent the hierarchy.

Redmine Issues map directly to monday.com Items on the corresponding Board. The Issue subject becomes the Item name. Standard fields map to monday.com columns: status to Status column with labels matching Redmine issue statuses (New, In Progress, Resolved, Closed), priority to a Labels column or Priority column, assigned_to to a People column, due_date to a Date column, and description to the Item's text body. Redmine's tracker (Bug, Feature, Support) maps to a Status column group or a dedicated board per tracker if the customer opts for tracker separation.

Redmine subprojects map to separate Boards within the parent Workspace or to Groups within the parent Board, depending on the customer's chosen structure. The migration notes this is a structural decision made during scoping. Subprojects with fewer than 50 issues map to Groups; subprojects intended as independent workstreams map to separate Boards for cleaner access control and automation scoping.

Redmine Versions (milestones with name, description, status, and due date) map to Groups within a Board (preserving the due date on the Group header) or to a Labels column, depending on whether the team uses milestones as deadlines or as categorical labels. Version status (open, locked, closed) maps to the Group visibility or a Status label.

Redmine Trackers (Bug, Feature, Support, and any custom trackers) have no direct monday.com equivalent. We map them either to Status column labels within a single Board (all issues, labeled by tracker) or to separate Boards per tracker. The choice is made during scoping based on the customer's workflow. Custom tracker definitions retrieved from /custom_fields.json are used to configure the corresponding column type in monday.com.

Redmine Time Entries linked to a single Issue map to the monday.com native Time Tracking column on the corresponding Item, with hours and comments preserved. When a single Issue has multiple Time Entries from different users or dates, each entry appends a separate time block to the item's Time Tracking column. Hours, activity type, and comments transfer. Note that Redmine's activity enumeration (design, development, research) maps to a Labels column on the item alongside the time data.

Redmine Users (login, firstname, lastname, email, admin flag) map to monday.com Workspace members. We resolve by email match. Any Redmine User without a matching monday.com account goes to a reconciliation queue for the customer's admin to provision before record import resumes. Redmine's custom user fields map to monday.com People column custom fields if the Pro/Enterprise account supports them.

Redmine Custom Fields retrieved from /custom_fields.json map to typed monday.com columns: list-type custom fields map to Dropdown or Labels columns, boolean to Checkbox, date to Date, integer or float to Numbers. The field name from Redmine becomes the column title. Multi-value custom fields (multiple flag set to true) map to Labels columns in monday.com. Custom fields are created per board, not globally, because monday.com Standard tier does not support shared column libraries across boards.

Redmine Time Entry custom fields map to additional columns on the parent Item alongside the native Time Tracking column. We retrieve all time_entry-scoped custom field definitions during discovery and create corresponding columns before the time data import phase.

Redmine stores attachment metadata (filename, content_type, filesize, description) in the database and the actual files on disk under the /files directory or a configured storage path. We enumerate the /files directory during discovery, copy its contents to a staging location, and re-upload each file via the monday.com REST API to the corresponding Item using the Redmine issue identifier as the relink key. The original filename, description, and uploader are preserved in the file column metadata.

Redmine Wiki pages stored with wiki text and attachment references map to monday.com Docs (if the customer licenses monday docs) or to Item updates with the wiki content as formatted text. Wiki text format (Redmine-specific markup) may require transformation depending on the destination format. Attachment links within wiki pages are resolved against the migrated file set.

Redmine Documents are project-level file attachments with titles and descriptions but no direct Issue linkage. We map them to Items on a dedicated Board (or a dedicated Group within the Project board) with the Document title as the Item name, the description as the Item body, and the file attachment migrated via the File column. The absence of an Issue linkage is noted in the migration report.

Redmine Groups used for role assignment map to monday.com Teams. We recreate Group membership by adding the corresponding monday.com users to the Team. monday.com Teams control board access permissions and notification settings. Note that Redmine's role-permission system (Member, Reporter, Non-member, Anonymous) does not map to monday.com's Team-based access model and requires a separate permissions design step.

Redmine News entries (title, description, author, created_on) map to monday.com Item updates or Board updates depending on whether the team wants them attached to a specific item or as a general board announcement. The News concept has no native equivalent in monday.com, so we flag the mapping decision during scoping.