Migrate from Easy Redmine to Trello

Every Redmine project maps to a single Trello board. Sub‑projects become independent boards and are linked from a card in the parent board that holds the child board URL; this approach preserves the original project hierarchy while respecting Trello's lack of a native sub‑board construct. Board names inherit the project name, and the project description can be stored in the board's welcome card for reference.

Redmine issues translate directly into Trello cards. The issue subject becomes the card title, the description populates the card detail area, and the original Redmine issue ID is saved as a custom field to keep traceability. Additional fields such as priority, assignee, start and due dates, and any attachments are also transferred, preserving the full context of the original work item within the Trello card.

Every distinct Redmine issue status—such as New, In Progress, Resolved, Closed, or Feedback—becomes a named Trello list. The sequence of these lists reflects the workflow order set in Redmine, preserving the original process flow. When custom statuses exist, each one is mapped individually to a list, ensuring that the specific terminology and transitions defined by your team are reflected accurately in Trello.

Redmine versions (the target versions attached to issues) can be represented in Trello either as a label that tags relevant cards or as a dedicated list marking a sprint milestone. The choice depends on how your team prefers to visualise release or sprint information. During scoping we confirm the preferred approach, decide on label colours or list order, and ensure the version name appears consistently on all affected cards.

Redmine users are matched to Trello workspace members by email address. When an email does not find a corresponding Trello account, the record is flagged; you can either assign those items to a fallback member, place them in a dedicated “Unmatched Users” list for manual resolution, or create new Trello accounts before migration runs. This ensures every work item retains an owner or a path for post‑migration onboarding.

Redmine issue assignees become Trello card members. Since Redmine permits only a single assignee per issue, each assignee maps directly to a member on the corresponding Trello card. If a Redmine issue ever contains multiple assignees (through custom workflows), each member is added individually to the card, and unmatched assignees are flagged for resolution before the migration completes.

Redmine time entries contain hours, activity type, and the date work was performed. Since Trello has no native time‑tracking object, total hours per issue are aggregated into a custom number field (Time Spent hours) on each card. The activity type (Development, Design, Meeting) is saved as a label, and the spent‑on date can be stored in a custom date field for reporting if needed.

Redmine priority levels—Low, Normal, High, Urgent, and Immediate—are translated into Trello label names and associated colours. The original priority label is kept verbatim so that filtering, sorting, and reporting by priority remain functional in Trello. During migration we align the colour scheme with your existing conventions where possible, ensuring visual consistency across boards.

Redmine issue relations (blocks, duplicated by, relates to) have no native Trello equivalent. We store the related issue ID as a custom field (Related Issues) on each card and generate a card link using the Redmine issue URL for reference.

Redmine file attachments linked to issues are downloaded and re‑uploaded as Trello card attachments. Before each upload we check the file size against Trello's limits: 10 MB on the Free plan, 250 MB on Business Class and Enterprise. Files exceeding the target plan's limit are flagged; options include skipping the file, compressing it, or linking to a repository such as Google Drive, while keeping the file name and creation date for auditability.

Redmine wiki pages attached to a project have no Trello counterpart. We migrate the wiki content as a board-level card (named 'Project Wiki') with the page text in the card description, or a linked external document via a URL card.

Redmine child issues can be modelled as Trello checklist items on the parent card. This collapses the four-level Redmine hierarchy into the flat three-level Trello model — your team decides whether to use checklist items or keep children as separate cards.

Redmine custom fields of type date, boolean, list, or text are transferred to Trello via the Custom Fields Power‑Up, using the matching Trello field type where available. For Redmine fields that reference users or versions, which have no Trello equivalent, values are stored as text in a custom field. All other field types are flagged in the pre‑flight report so you can review loss before migration runs.