Migrate from Redmine 3.3 to Asana

Redmine projects map to Asana Projects within Teams. Redmine's subproject hierarchy (a project with a parent project_id) maps to Asana's project nesting or a separate project within the same Team. If the Redmine instance uses many levels of subproject nesting, we discuss collapsing into a flat project-per-team structure or using Asana Portfolios for cross-project grouping. The project's public/private flag maps to the Asana project's visibility setting. Each Redmine project module (wiki, forums, repository, time tracking) is audited and flagged: Asana has no wiki or forum equivalent, so those are omitted from the migration scope unless the customer requests wiki-to-task conversion.

Redmine issues map directly to Asana tasks. Subject maps to Task Name, Description maps to the task description field (markdown preserved), Done Ratio maps to a custom numeric field or Percent Complete if using the Asana Timeline. Start Date and Due Date map to the task Start Date and Due Date fields. Redmine's issue priority (Low, Normal, High, Urgent) maps to Asana's Custom Fields as a single-select dropdown. Redmine's estimated hours map to Asana's Time Tracking field if the project has it enabled. We resolve assignee (issue.assigned_to_id) by matching to an Asana User by email.

Redmine trackers (Bug, Feature, Support, or custom trackers defined at install time) do not have a native Asana equivalent. We create an Asana custom field named 'Tracker' with a single-select dropdown containing each distinct tracker name from Redmine, then write the tracker value into that field for each migrated task. Alternatively, if the customer prefers a non-custom-field approach, we create one Asana Section per tracker within each project and sort migrated issues into those sections.

Redmine 3.3 stores list-format custom field values as internal numeric IDs in the issue record, while the human-readable label lives in a separate possible_values table. We query the custom_field definitions endpoint and build an ID-to-label lookup table before processing any issue export. For each list-format custom field, we create a corresponding Asana custom field of the matching type (single-select for list, multi-select for multi-list) and write the resolved display label rather than the raw ID. This prevents migrated records from showing numeric IDs instead of meaningful values.

Redmine time entries record hours spent against a project or specific issue, with activity categories (e.g., Development, Design, Meeting) and comments. Asana's time tracking feature is enabled at the project level and records time against tasks. We migrate time entries by converting the Redmine hours and activity into Asana time logged against the corresponding task. If Asana time tracking is not enabled on the destination project, we create a custom numeric field 'Hours Logged' and write the total hours there, losing the per-activity breakdown. Activity category names migrate as a custom field on the task if the customer requires the breakdown.

Redmine versions (or targets) represent milestones or releases within a project, with fields for name, effective date, description, and status. Asana Milestones are a task type with zero duration that represent checkpoints. We migrate each Redmine version as an Asana Milestone within the corresponding project. The version effective date maps to the milestone due date, and the version description migrates to the milestone description. If the Redmine version is not yet effective (status = 'open'), the milestone is created without a due date.

Redmine supports typed issue relations: blocks, blocked by, relates to, duplicates, and others. Asana Timeline supports dependency types finish-to-start, start-to-start, finish-to-finish, and start-to-finish. We map Redmine 'blocks' to Asana 'blocks' (finish-to-start where the blocking task must complete before the dependent starts), 'blocked by' to 'depends on', 'relates to' to a non-blocking association (noted in the task description because Asana has no non-blocking dependency type), and 'duplicates' to a task-level flag. Circular dependency detection is applied during the transform phase.

Redmine stores uploaded files on the server filesystem under the files/ directory (or a configured storage path) and records only the file path and metadata in the attachments table. We extract file paths from the attachments table, verify file accessibility on the Redmine server, download each file, and re-upload to Asana as a task attachment via the Asana Attachments API. The original filename and content-type are preserved so that the attached file opens correctly in Asana. Files are processed in batches to manage download/upload time and avoid timeout during the migration window.

Redmine user accounts include login, firstname, lastname, email, admin flag, and custom fields. We export users and their project memberships with role assignments. We match Redmine users to Asana workspace members by email address. If a Redmine user has no corresponding Asana account, they are added to a reconciliation list for the customer to provision before record import. Role-based access control (Redmine role permissions per project) has no direct Asana equivalent; we document the role matrix in the migration handoff and the customer recreates permissions in Asana Teams and Projects manually.

Redmine wikis are project-scoped and store content in a wiki_format attribute with page hierarchy. Asana has no wiki or document-repository concept. We do not migrate wiki pages as functional content. We export wiki content as HTML files and deliver them as a static export package. If the customer uses Redmine wiki for project documentation, they must recreate it in a document management tool (Notion, Confluence, Google Docs) or in Asana task descriptions. This is flagged during discovery and documented in the scope agreement before migration begins.

Redmine project-level documents store a title, description, and category with attached files. If the document has files attached, we migrate those files as task attachments on a designated documentation task within the project. If the document has no attachments, it is flagged as a candidate for recreation in a document management tool. Document categories vary by installation and do not have an Asana equivalent.

Project news posts include a title, summary, content, and author. Asana has no news feed equivalent. News is omitted from standard migration scope as it is typically lower priority than task and project data. If explicitly requested, we migrate news as tasks with a custom 'News' section and the author set as the task assignee.