Migrate from Redmine 3.3 to Trello

Redmine Projects map to Trello Boards with the project name as the board name. Public and private flags from Redmine map to Trello's board visibility (public vs private). We export the full project-subproject tree and create each subproject as a separate Board, then document the parent-child relationship in the board description for manual workspace organization. If the Redmine project has modules enabled (wiki, issue tracking, repository), we add a board description note flagging the modules for manual activation in Trello.

Redmine subprojects map to Trello Boards under the same Workspace. There is no native subproject concept in Trello, so we create each subproject as a standalone Board and record the parent project identifier in the board description. The customer manually organizes boards within the Workspace sidebar after migration.

Redmine Issues map to Trello Cards. The issue subject becomes the card title, the description maps to the card description with markdown formatting preserved. Issue status New, In Progress, Resolved, Feedback, Closed maps to Trello list positions (e.g., To Do, In Review, Done). The assignee from Redmine is added as a card member in Trello. Due dates, start dates, estimated hours, and done ratio migrate as card metadata. We resolve assignee email addresses against the target Trello workspace members and add matching users as card members.

Redmine Trackers (Bug, Feature, Support, custom) map to Trello Labels with the tracker name as the label name and a consistent color assignment per tracker type. If the destination workspace already has labels defined, we map the Redmine tracker names to existing label names or create new labels. The label mapping configuration is documented in the mapping spec before migration begins.

Redmine issue statuses (New, In Progress, Resolved, Feedback, Closed, plus any custom statuses defined in the workflow) map to Trello List names. We export the full workflow status set from the Redmine database, deduplicate, and create one Trello List per distinct status value in each board. Custom status labels are preserved in the list name for admin review and renaming post-migration.

Redmine custom fields (string, integer, list, date, boolean, user references) present a mapping challenge because Trello has no native custom field objects on the Free tier. On Standard and Premium tiers, the Custom Fields Power-Up provides typed custom fields. We read the custom_field_definitions table, resolve list-format internal IDs to display labels using the possible_values lookup, and write field values into a structured section of the card description for all tiers. On Business Class Standard+ we use the Custom Fields Power-Up API to create typed fields before card import.

Redmine time entries linked to an issue merge into a time log section on the corresponding Trello Card. Each time entry contributes a checklist item in the format '[hours]h - [activity] - [comments]' or a structured description block. Activity categories from Redmine (e.g., Design, Development, Testing) are written as text labels in the time log entry. We export the full time entry set per issue and consolidate into the card during migration. Trello's native time-tracking Power-Up can be activated post-migration to surface these as formal time records.

Redmine Versions (milestones or targets) within a project are documented as Trello Labels named after the version with a milestone color code, or as card due dates where the version has an effective date. Versions without a due date are preserved as labels only. We export the version name, effective date, description, and status (open, locked, closed) and map accordingly.

Redmine typed relations (blocks, blocked by, relates to, duplicates, follows, copied from) have no native Trello equivalent. We export the full relation graph and for each relation type we create a label on the related card (e.g., a 'blocks:#123' label) or a checklist item noting the dependency. The customer reviews these post-migration and uses Trello's Card Aging Power-Up or manual checklist grouping to manage dependencies.

Redmine user accounts (login, firstname, lastname, email, admin flag) map to Trello Workspace members. We match by email address during migration and add matched users as board members with the same role scope as their Redmine membership roles. Any Redmine user without a matching Trello account goes to a reconciliation queue for the admin to provision before the final migration run.

Redmine attachments are files stored on the server filesystem with metadata in the attachments table (filename, content_type, disk_filename, created_on). We extract the file path from disk_filename, verify file accessibility, download each file, and re-upload as a Trello card attachment using the Trello Attachment API. We preserve the original filename and content-type. File links from migrated issues remain valid post-migration.

Redmine wiki pages are project-scoped with hierarchical page structures and HTML or textile formatting. Trello has no native wiki feature. We export wiki page content as markdown text and append it to the project board description or a designated 'Project Documentation' card. If wiki pages are critical, we recommend the customer migrate them to Confluence as a parallel step. Page-level permissions do not transfer.