How to Migrate from Redmine to Jira

• Performance at Scale
  Redmine tends to degrade in performance as teams and data grow. Jira, particularly Jira Cloud, is built for scale — supporting large teams with consistent performance and enterprise-grade reliability.
  
  
• Seamless Integrations
  Jira integrates out of the box with other Atlassian tools like Confluence, Bitbucket, and Jira Service Management. It also connects with hundreds of third-party apps via the Atlassian Marketplace, something Redmine doesn't offer at scale. Plus, if the specific integration you need isn't available out-of-the-box or on the Marketplace, we can build it.
  
  
• Intuitive Interface
  Redmine's UI is functional, but clunky. Jira offers a modern, intuitive design that supports both technical and business users, improving adoption and productivity.
  
  
• Flexible Workflows
  Redmine's workflows are rigid and difficult to customize. Jira lets you build workflows that reflect real processes — with conditional transitions, validators, and per-project configurations.
  
  
• Advanced Reporting
  Jira offers rich out-of-the-box reporting, dashboards, and customizable charts. If you're on Jira Cloud Premium or Enterprise, you also get access to features like Atlassian Analytics for advanced business intelligence.
  
  
• Strong Global Support
  Redmine's documentation is limited. By comparison, Jira benefits from a massive global community, extensive knowledge base, and direct support through Atlassian or a Platinum Solution Partner.

Atlassian previously offered a Redmine Importer, but it has been deprecated and is no longer supported. Today, migration requires more manual effort:

• Export Redmine data to CSV — but note that some field data may be lost.

• Use the Redmine REST API to extract detailed data, including issues, users, and custom fields.

• Transform your data to align with Jira's structure and supported formats.

Each path requires a significant amount of effort to modify data into a format Jira can import. Before the import can happen, though, make sure to map your data so you know which elements from Redmine will be migrated into corresponding elements in Jira. Careful mapping will result in a smoother migration.

User mapping is one of the most critical—and often most time-consuming—steps in a Redmine to Jira migration. Before moving any data, it's essential to assess the user directories in both systems to ensure a clean and functional transition.

If your Jira instance is brand new, and you're not syncing from an external identity provider, this process may be relatively simple. But in most cases, user mapping becomes necessary—especially when your Jira environment uses Atlassian Access, Active Directory (AD), or another identity management solution that differs from the one Redmine uses.

If your Redmine and Jira environments share the exact same usernames and email addresses, you're in luck. Jira will be able to associate activity records with existing accounts, minimizing duplication. However, mismatches are common—especially if the systems have evolved separately or use different authentication methods. For example, one system might use short usernames while the other relies on full email addresses. In these cases, a 1:1 user mapping must be defined to preserve user activity and audit trails.

We recommend evaluating and exporting both Redmine and Jira user lists early in the process. If you’re planning to import users “as is” into Jira Cloud—without syncing through a directory or SSO provider—you may be able to bypass some of the mapping effort. However, if your users already exist in Jira or if email addresses and usernames differ between systems, you'll need to manually define how Redmine users correspond to Jira accounts.

This mapping can be done in a spreadsheet or script-friendly format and should include:

• Username

• Email address

• User ID (if available)

• Mapped Jira account name or ID

Once your mapping file is finalized, you'll use this data to update Jira user records accordingly—either before or during the import. Many teams write custom scripts to help automate updates or to prepopulate Jira with mapped user data. Wherever possible, syncing users before the data import reduces errors and prevents the creation of duplicate or orphaned accounts.

Here are some additional notes and caveats to keep in mind during user import:

• Users who have interacted in Redmine (i.e., created issues, left comments, etc.) will be created as active Jira accounts—even if they’re no longer active in Redmine.

• Users who have not interacted in Redmine will be grouped under a default bucket called Redmine-import unused-users and marked as deactivated in Jira.

• Passwords are not migrated. All imported users will need to receive password reset emails upon first login to Jira Cloud. Be sure to notify users in advance so they know what to expect.

• External User Management is incompatible with user import. If you're syncing Jira with a directory like Okta, Azure AD, or LDAP, users won’t be created during import. Instead, Jira will provide a list of required accounts for you to provision manually.

• User license limits may interrupt the migration. If your Jira license tier is exceeded during import, the process will stop and generate a list of users that couldn't be created. It's important to verify your user count ahead of time and ensure your subscription can accommodate all active users being migrated.

User mapping may not be the most glamorous step in your migration plan, but getting it right is crucial to preserving project history, permissions, and traceability in Jira. Taking the time to align users up front will save you major cleanup effort after the migration is complete.

Statuses and priorities need to be mapped as part of your Redmine to Jira migration. This is the right time to review the values currently used in Redmine and compare them with those in Jira.

Since both statuses and priorities are global elements in Jira, it’s important to avoid adding unnecessary new ones. Instead of importing every value from Redmine, see where you can map to Jira’s existing configuration. If there are Redmine statuses or priorities that don’t have clear equivalents in Jira, you’ll need to decide whether it’s worth introducing them—or if they can be consolidated without losing meaning.

Cluttering your Jira instance with redundant or overly specific values can make future administration more difficult. To avoid that, document your mapping plan in advance. This reference will be essential later in the process, especially when rebuilding workflows during the import.

Workflows should be reviewed and planned out before you begin the import process. You’ll need to recreate each workflow used in Redmine within Jira.

Start by using your status mapping as the foundation. Once your statuses are in place, you can safely rebuild the workflows in Jira. In many cases, it’s best to create one reusable workflow that includes all necessary statuses—especially if the imported Redmine projects follow similar patterns.

If you're planning to rebuild workflows using Jira’s workflow editor after the import, you don’t need to replicate every step exactly. Focus on including the correct statuses for now. You can always customize transitions, conditions, and validators later. As long as your Jira workflow includes the appropriate statuses, it should work across all imported Redmine projects.

Custom field mapping is another time-consuming step in a Redmine to Jira migration. You’ll need to manually create in your Jira instance all the custom fields currently used in Redmine before starting the import.

While it may feel redundant, setting up these fields ahead of time ensures that your data can be mapped cleanly during the import process. Without this step, the import may fail to associate data correctly or could leave fields unmapped. Preparing your custom fields in advance makes the rest of the migration much smoother.

Redmine “Trackers” are functionally equivalent to Jira “Issue Types.” Before your migration, check whether your existing Redmine trackers align with Jira’s current issue types. If they do, you can map them directly. If not, you’ll need to create any missing issue types in Jira so each Redmine tracker has a corresponding destination during import.

Before importing data, set up the empty Jira projects that will receive your Redmine content. To keep things organized, create Redmine-specific schemes—just as you would for any Jira project—and assign them accordingly.

Once your schemes are ready, go through your list of Redmine projects and create a matching empty project in Jira for each one. Avoid adding components or versions during this step—doing so would make the project non-empty, which the importer doesn’t support. Let Jira handle components and versions during the import process instead.

Redmine supports hierarchical issue relationships by default, but Jira handles this differently. To replicate hierarchy in Jira, you’ll need to use issue links to establish parent-child relationships. In some cases, configuring a custom issue link type may be necessary to mirror Redmine’s structure more closely.

If you're using Jira's advanced planning features (available in Plans), you can also configure issue hierarchy levels beyond the default Epic → Story → Sub-task structure.

When planning your Redmine to Jira migration, it’s easy to focus on the how and overlook the whether. Not all data holds equal value, and it’s crucial to weigh the cost of migrating specific data against its ongoing usefulness.

Think of it like moving to a new house—you wouldn’t pay to haul along furniture or items you plan to discard. The same logic applies to data. Migrating every single issue, user, or custom field just because you can, may not be cost-effective or beneficial.

Before starting your migration, evaluate what data is truly needed in Jira. Prioritize active projects, relevant issues, and critical historical records. Leaving behind obsolete or redundant data can simplify your migration and reduce overhead in your new environment.