Migrate from Redmine 3.3 to monday Work Management

Redmine projects map to monday.com boards with the project identifier becoming the board name and the project description becoming the board description. Subprojects in Redmine map to monday.com boards linked via an integration column or held as groups within a parent board depending on the customer's preferred hierarchy. Public/private project flags map to board-level visibility settings. We configure boards during the pre-migration phase so that item import lands in the correct destination structure from the first record.

Redmine issues map to monday.com items on the corresponding board. The issue subject becomes the item name, the description becomes the item text column or main description field, status maps to a monday.com Status column with values matched to the Redmine tracker workflow states, priority maps to a Label column, assignee maps to a Person column, and due date maps to a Date column. We construct the item using the monday.com GraphQL API, batch-creating items in chunks with exponential backoff to respect rate limits.

Redmine trackers (Bug, Feature, Support, etc.) defined per-project map to monday.com groups within each board, or to a Status column with tracker-name prefixes if the customer prefers a flat item list. We export tracker definitions from the trackers table and issue associations from the issues table during scoping, then configure groups or the Status column values before any item migration begins. Per-role workflow restrictions cannot be reproduced in monday.com's permission model and are flagged for the customer to address through board-level permissions.

Redmine custom fields map to monday.com column types: text fields to Text columns, numeric fields to Numbers, dates to Date columns, user lookups to People columns, list values to Dropdown or Labels, booleans to Toggle columns, and version lookups to a dedicated Version integration or Text column with the version name. List-format custom fields store numeric IDs in Redmine's database — we query the custom_field_enumerations table to build an ID-to-label lookup before writing any value to monday.com so that display values appear correctly rather than raw integers.

Redmine time entries with hours, activity category, comments, and issue association migrate as monday.com sub-items linked to the parent item. Where the destination plan includes the Time Tracking column feature (Pro and above), we use the native time-tracking column. We preserve the original spent date as the sub-item date and the activity category as a label or text field so that time reporting by activity type remains intact. If the destination plan is Standard, the sub-item approach provides equivalent historical granularity.

Redmine versions (milestones/releases) with name, effective date, and status migrate to monday.com as a dedicated Status column value, a Label column tag, or a Text column entry depending on the customer's reporting pattern. Version dates are preserved in a Date column or in the item description for reference. Version-to-issue associations are reconstructed by matching version names at migration time.

Redmine user accounts (login, email, firstname, lastname) map to monday.com workspace members invited by email. Project memberships and role assignments migrate as board-level permission settings. We match users by email address. Any Redmine user without a monday.com account goes to a reconciliation queue for the customer to provision before item import begins, because monday.com Person column values require an existing workspace member.

Redmine typed issue relations (blocks, blocked by, relates to, duplicates) are stored by internal numeric ID. We export the full relation graph and attempt to link migrated items using the monday.com Integration Column (two-way mirror) or a custom text column holding a comma-separated list of linked item IDs. Note: monday.com does not natively support cross-board item linking in all plans, so cross-project issue relations may resolve to text fields with a note explaining the limitation rather than a live link.

Redmine project wikis with page hierarchy and formatted content export as raw text or HTML. We write wiki content to monday.com item descriptions or to a linked Document (if the monday.com instance has the Docs feature) for each Redmine wiki page. Wiki permissions are not enforced in monday.com; we note the original page-level permission set for the customer to address through board-level access settings.

Redmine attachments stored on the server filesystem (or object storage path) are extracted via the attachments table file path metadata, downloaded, and re-uploaded to the corresponding monday.com item using the monday.com API file upload endpoint. We verify file accessibility and content-type before upload so that links in migrated items remain valid. Attachments exceeding monday.com storage limits are flagged for the customer to address.

Redmine project documents (title, description, category) migrate as monday.com items with a document-category label or as monday.com Documents if the instance supports the feature. Document categories that vary by installation are mapped to monday.com Labels or a Dropdown column during the field map phase.

Redmine project news posts migrate as monday.com items on a designated News board or as Updates on the relevant project board, with the post title as the item name and the content as the description. News is low-priority scope and migrates only if explicitly included in the customer's migration scope to reduce migration window time.