How to Migrate From Trello, Asana, or Jira Without Losing Your Project History

02. What Survives a Well-Planned Migration

The things that matter most for continuing active work do transfer reliably, if you export in the right format and map your columns before importing.

• Task titles: almost always transfer cleanly across all three source tools
• Task descriptions: transfer if the export format supports rich text (Trello JSON does, Asana and Jira CSVs vary)
• Due dates: transfer as long as date formats are consistent; check your destination tool's expected date format before importing
• Assignees: transfer if the email addresses match between tools; mismatched emails create unassigned tasks
• Status and column structure: transfers if you map columns explicitly before importing; do not rely on automatic mapping
• Time tracking history: transfers only if your source tool has it and your destination tool's importer supports it (most do not)

03. The Right Sequence Before You Export Anything

The most expensive migration mistake is exporting everything and importing everything. You end up with hundreds of archived projects cluttering the new workspace, tasks from 2019 that nobody will ever open again, and a team that cannot find their active work in the noise. Do the audit first. Categorize every project in your source tool into three buckets: active (needs to be in the new tool immediately), reference (should be accessible somewhere but not cluttering the active view), and archive (safe to leave in the old tool and forget). Only migrate the active bucket immediately. Set up the reference and archive access in the old tool, which you will keep read-only anyway. Within active projects, audit tasks: remove completed tasks that are so old they have no reference value, standardize assignee email addresses if they are inconsistent, and verify that due dates are still meaningful.

04. Migrating From Trello: JSON Export and What to Map

Trello's export format is JSON, accessible from each board's settings menu (Settings → More → Print and Export → Export as JSON). The JSON contains lists (your columns), cards (your tasks), card descriptions, labels, due dates, members, and checklist items. It does not contain comments in a format most importers support; comments are in the JSON but require custom parsing to use. Before importing, document your column structure: list every list name in Trello and decide what it maps to in your destination tool. 'Doing' in Trello might map to 'In Progress.' 'Review' might map to 'Client Review.' Do this mapping on paper before you touch the importer, because changing it after import means bulk-editing tasks. Melororium's importer accepts Trello JSON directly, shows a 5-row preview before committing, and has a column mapper where you define the Trello list to Melororium column relationship before any data is imported. If the preview looks wrong, you adjust the mapping and re-preview without creating any tasks.

05. Migrating From Asana: CSV Export and Column Mapping

Asana exports tasks as CSV, one row per task (File → Export → CSV from any project). The CSV includes task name, assignee email, due date, section (equivalent to a column or stage), and custom field values. It does not include comments, attachments, or timeline and dependency data. The section field is your column equivalent. Export the CSV, open it in a spreadsheet application, and look at the unique values in the Section column. Those are the columns you need to create in your destination tool before importing, or that you will map during the import process. One common Asana-specific issue: subtasks. Asana exports subtasks as separate rows with a parent task reference, but many importers do not support this hierarchy. Check your destination tool's documentation for subtask handling before assuming they will appear correctly.

06. Migrating From Jira: CSV Export and the Status Problem

Jira has two export paths: the built-in CSV export (available from the board or backlog) and the more complete Jira XML export accessible from project settings. For migration purposes, the CSV is usually sufficient for the core task structure. The Jira-specific challenge is status mapping. Jira statuses are project-specific and often include custom workflow statuses like 'In code review,' 'Waiting for PM,' or 'UAT.' Your destination tool probably does not have these exact statuses. Before importing, list all unique status values in your Jira CSV and decide what they map to. Statuses that have no equivalent can be mapped to 'In Progress' temporarily, then corrected task by task after migration. Jira also uses a different assignee field format than most tools (account IDs rather than email addresses in some export formats). Check the assignee column in your CSV. If you see account IDs instead of names or emails, run an additional export from User Management to build the mapping table.

07. The Pilot Project Rule

After you have mapped columns, prepared your export file, and confirmed assignee email formats, do not import everything at once. Pick one active project, ideally one with a small number of tasks and a team of two or three people, and run it through the full migration process first. The pilot project surfaces problems that theory cannot: date format mismatches, assignee emails that do not match between tools, column names that looked right in the mapper but create confusion in practice, custom fields that do not have an equivalent. Fix these in the mapping configuration before importing your entire workspace. Give the pilot project team one week to work in both tools simultaneously: the old tool for reference, the new tool for active work. Collect every friction point they encounter. Fix as many as possible before expanding the migration.

08. Keep the Old Tool Read-Only for 30 Days

The most expensive migration decision is canceling the old tool subscription the same day you import to the new one. Do not do this. Keep the old tool in read-only mode (stop adding new tasks, stop updating tasks) for 30 days after the migration. You will reference it. A client will ask about something from two months ago. Someone will need a comment from an old project thread. You will realize you missed an active project in the audit. The 30-day buffer is cheap insurance against scenarios that feel unlikely until they happen, at which point the data is either accessible in the old tool or gone entirely. After 30 days, evaluate: have you needed the old tool? If not, cancel. If you accessed it three times, keep read-only access for another 30 days. The goal is a clean cutover, not a permanent dual-tool setup, and the timing should be driven by actual usage rather than a calendar date.

09. Frequently Asked Questions

**Will I lose my comments when migrating from Trello, Asana or Jira?** Probably yes, at least partially. Comment data is the most commonly lost element in tool migrations because comment formats are highly tool-specific and most importers do not support them. Trello's JSON export contains comments but they require custom handling. Asana's CSV export does not include comments at all. Jira's CSV export includes some comment data but formatting is often lost. If comments are critical, export them separately (screengrab, PDF export, or custom JSON parsing) and store them in a reference location before canceling the old tool. **Can I migrate just one project instead of everything?** Yes, and this is the recommended approach. Migrate active projects first, keep archived projects in the old tool for reference during the 30-day read-only period, and only migrate historical projects if someone actively requests them. Most teams find that 90% of the value comes from migrating the 20% of projects that are currently active. The remaining projects rarely need to move at all. They just need to be accessible for occasional reference, which the old tool provides during the read-only window. **How long does a full migration take?** Planning and audit: 2-4 hours for most teams. Pilot project migration and testing: 1-2 days. Full team migration: a few hours of actual import work plus 1-2 weeks of parallel operation while the team gets settled. The total elapsed time from decision to old-tool cancellation is typically 3-5 weeks for a 10-person team with 10-20 active projects. Teams that compress this into 2-3 days usually spend the next month fixing problems the pilot project would have caught. **What happens to Jira sprints and epics in the migration?** Sprint and epic structures are Jira-specific concepts that do not have direct equivalents in most destination tools. Sprint data is usually lost in the migration: historical sprint assignments, velocity charts, and burndown data do not transfer. Epics can sometimes be mapped to labels, tags, or a parent-task structure in the destination tool, but this requires manual mapping rather than automatic transfer. If sprint history matters, export a separate sprint report from Jira before migrating and keep it as a reference document. **Do we have to migrate over a weekend?** No. A pilot-first migration runs alongside normal work: one small project moves, the team works in both tools for a week, and the friction points get fixed before anything else moves. The only moment worth scheduling carefully is the cutover day for each team, and even that stays reversible while the old tool remains read-only for 30 days.