Migrate from Redmine to Trello

Redmine Projects map to Trello Boards. Each Project's identifier, name, description, homepage, and public/private flag transfer to the Board. Subprojects map to child Boards or to Lists within a parent Board depending on whether the customer wants a flat or hierarchical structure. We confirm the preference during scoping and configure the Board hierarchy accordingly.

Redmine Issues are the primary migration object and map to Trello Cards. Standard fields transfer: subject (Card name), description (Card description in markdown), status (Card position within a List), priority (Card position or Label color), assignee (Trello Member), due date (Card due date). Custom field values transfer to Trello Custom Fields Power-Up if the destination Board has matching field definitions. Note that Redmine's parent-subtask hierarchy has no native Trello equivalent; subtasks are mapped as Checklist items on the parent Card.

Redmine Trackers (Bug, Feature, Support, etc.) map to Trello Labels. We create Label definitions on each destination Board that correspond to the active Trackers in Redmine. The Label name carries the Tracker name and an optional color assignment. Closed or archived issues can be mapped to a separate 'Archived' Label if the customer wants visibility into closed items within the same Board.

Redmine Issue Statuses (New, In Progress, Resolved, Closed, etc.) map to Trello Lists on the destination Board. We configure Lists to correspond to the active status values in the Redmine project. The customer chooses whether to map statuses directly to Lists or to use Card position within a smaller set of Lists with Label-based status overlays. Status transition history (journals) does not migrate because Trello has no concept of status change audit trails.

Redmine Versions carry a name, description, status, and due date. We map the Version name to a Label (e.g., 'Sprint 3') and the Version due date to the Card due date for issues assigned to that Version. If the customer uses Versions as milestones rather than as date targets, we offer a List-based mapping where all cards in a Version appear on a dedicated List.

Redmine Users (login, firstname, lastname, email, admin flag) map to Trello Members on the Board. We extract all Users referenced as assignees on Issues and add them as Members to the destination Board. Note that Redmine passwords are not transferable—Trello accounts are provisioned by email invitation, and each Redmine User must accept the invitation to access Trello.

Redmine Issue Custom Fields are defined separately via /custom_fields.json and apply to specific Tracker or Project contexts. We retrieve all active custom field definitions before migration, then configure matching Custom Fields in the Trello Custom Fields Power-Up on each destination Board. Trello supports five custom field types: checkbox, date, dropdown, number, and text. Fields using unsupported formats (e.g., long text, URL, user reference) are flagged as requiring manual entry or a workaround.

Redmine attachments are stored in the filesystem under /files (not in the database). We enumerate the /files directory during discovery, extract each file with its container_type and container_id metadata, and re-upload each file as an attachment to the corresponding Trello Card using the Card ID resolved from the Redmine Issue identifier. Filename, content type, and file size are preserved. This is a high-severity gotcha: database-only migration scripts miss all attachments.

Redmine Time Entries are first-class objects linked to Issues with hours, activity, and comments. Trello has no native time tracking object. We map the total logged hours per Issue to a text note in the Card description (e.g., 'Total time logged: 4.5h') and optionally create a Checklist item with time details if the customer needs granular visibility. Dedicated time tracking Power-Ups in Trello are noted as a post-migration rebuild option.

Redmine Wiki Pages are stored as wiki text with attachments and are project-scoped. Trello has no native wiki. We export wiki content as markdown, save it as a file, and attach it to the Board or to a designated Card as a reference document. If the customer uses Confluence for documentation, we can flag the Confluence URL mapping as a separate engagement. Wiki pages with complex formatting may require manual review.

Redmine Documents are project-level file attachments with titles and descriptions but no direct Issue linkage. We map them to Trello Card attachments on a designated Card per project, or to a Board Power-Up such as Document Card if the customer enables one. Documents without a clear home in Trello are flagged in the written inventory for the admin to organize.

Redmine News entries are lightweight project posts with a title, description, and author. Trello has no News object. We map News to Card descriptions on a designated Board Card (e.g., 'Project Announcements') or note them in the written inventory for manual republication in Trello's activity stream or a connected tool.

Redmine Issue Priorities (Low, Normal, High, Urgent, Immediate) map to Trello Card position (higher priority cards placed higher in the List) or to Label colors that the customer assigns. We configure the mapping during scoping so that priority is visible without opening each Card.

Redmine Groups organize Users for role assignment. Trello uses Workspaces and Board membership for access control. We recreate Group names as Trello Workspace names if the customer uses multiple Workspaces, and add Members to Boards based on Group membership. Role-based permissions in Redmine do not transfer because Trello's permission model is Workspace and Board-level only.