Migrate from Redmine to Asana

Redmine Projects map to Asana Teams (organizational unit) containing one or more Projects. We preserve the project hierarchy: top-level Redmine projects become Asana Teams with a root Project; subprojects become Asana Projects within that Team. Project status (active/closed/locked) maps to Asana Project archived status. If the Redmine project contains only one subproject, we may collapse the hierarchy into a single Asana Team for simplicity.

Redmine Issues map to Asana Tasks. The Redmine tracker (Bug, Feature, Support, etc.) maps to an Asana Project or a Project-level label that we create during schema setup. Redmine status (New, In Progress, Resolved, Closed, etc.) maps to Asana task completion status (complete/incomplete) plus an optional custom status field if multi-stage tracking is required. Parent-child Issue relationships in Redmine map to Asana subtasks; we handle single-level nesting by default and flag deeper hierarchies for flattening during scoping.

Redmine Versions (also called Milestones) carry a name, description, due date, and status. They map directly to Asana Milestones within the corresponding Project. The version due date becomes the Milestone due date, and the version description becomes the Milestone notes. We resolve the parent Project reference by matching the Version's project_id to the mapped Asana Project.

Asana has no native Time Entry object in its base tiers; time tracking requires the Time Tracking add-on or custom fields. We discuss the customer's preference during scoping. If the Time Tracking add-on is available on the destination Asana plan, we map Time Entries to Asana time-tracking entries linked to the Task. If not, we create custom fields (Hours, Date, User) and populate them as structured custom field values or as formatted notes on the Task, preserving hours, the logged date, and the original Redmine user reference.

Redmine Users include login name, email, first/last name, admin flag, and custom fields. We match Redmine Users to Asana Members by email address. Any Redmine User without a matching Asana email is held in a reconciliation queue for the customer's admin to provision before record import. Redmine does not store passwords in a format compatible with Asana, so no password migration is attempted. The user's language preference and time zone map to Asana profile settings if available via API.

Redmine Groups are used for organizing Users for role-based access control. We map each Redmine Group to an Asana Team, preserving membership. If the customer uses Groups only for notification routing rather than access control, we may alternatively map Groups to Asana Tags or custom fields. This is decided during scoping based on how the customer uses Groups in Redmine.

Redmine attachments are stored as metadata in the database (filename, content_type, description, disk_path) with the actual file on disk under the /files directory. We enumerate the /files directory during discovery, copy each file to a staging location, and upload it to Asana via the Asana Attachments API using the original filename and content_type. The attachment is linked to the target Task by resolving the Issue identifier stored in the Redmine attachment record. Files larger than 100 MB require chunked upload handling.

Redmine Issue journals capture status changes, priority changes, and comments. We separate comments (journalized_notes with author and created_on) from system status-change entries. Comments migrate to Asana as Task notes (appended in chronological order) or as subtasks with a 'Comment' label depending on the customer's preference for preserving conversation context. We resolve the comment author to the corresponding Asana Member by email.

Redmine Custom Fields are defined once at the installation level via /custom_fields.json and applied to specific object types (Issue, Project, Time Entry). Asana custom fields are workspace-level and shared across all projects. We consolidate all Redmine custom field definitions during discovery, deduplicate by name, and create corresponding Asana workspace custom fields of matching types (text, number, date, enum dropdown, multi-enum checkbox). For enumeration-type custom fields, we map the possible_values list to Asana custom field enum options. Custom field values on Issues are populated during the Issue migration phase.

Redmine Trackers (Bug, Feature, Support, etc.) categorize Issues. Asana has no direct Tracker object. During scoping we decide whether to map each Tracker to a separate Asana Project (one Project per tracker type) or to use Project-level Labels. The choice depends on whether the customer wants cross-tracker views. If Asana's free-tier plan is in scope, we use Labels because the customer may not have project creation capacity on all tiers.

Redmine Wiki Pages are stored as separate objects with wiki text and attachment references. Asana has no native wiki. We evaluate the content and either convert wiki text to a formatted Task (with the Task description carrying the wiki body) or export to an external document format (Markdown or HTML) that the customer stores in a linked Google Drive or SharePoint integration. This is a migration gap the customer must address as part of post-migration cleanup.

Redmine Documents are project-level file attachments with titles and descriptions but no direct Issue linkage. We map Documents to Asana Attachments linked to the corresponding Project task or to a standalone documentation Task. The document title and description migrate to the attachment or task notes.

Redmine Issue Relations include blocker, duplicates, precedes, follows, and Blocks/Blocked by types. Asana supports dependency arrows (finish-to-start) via the dependencies field on Task. We map Redmine precedes/follows to Asana dependencies and flag blocker relations as a custom field (redmine_blocker_type__c) because Asana does not distinguish between 'blocks' and 'is blocked by' directionality. Duplicate relations have no Asana equivalent and are recorded in a custom field for manual cleanup.