Migrate your Redmine data
Self-hosted open-source project management and issue tracker written in Ruby on Rails. No licensing cost, no user caps, and full source-code access for teams that want control over their tooling.
In its favor
Why people choose Redmine
The signal that keeps Redmine on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Free open-source licensing with no per-user or per-project fees makes Redmine popular with budget-constrained technical teams and nonprofits.
Full source-code access and a mature plugin ecosystem let self-hosting teams customize workflows, roles, and integrations without vendor constraints.
Built-in Gantt charts, calendars, time tracking, and version-control repository browsers provide project management essentials out of the box.
Cross-platform and cross-database support (MySQL, PostgreSQL, SQLite) means Redmine runs on a wide range of infrastructure.
Support for 49 languages and per-project wikis and forums appeals to globally distributed or documentation-heavy teams.
Installation and initial configuration are consistently described as difficult, with a steep learning curve for server administrators new to Ruby on Rails.
The user interface is widely criticized as dated and unintuitive, with cluttered project screens and confusing role-based permission setup.
Email notifications lag and feel outdated compared to modern real-time collaboration tools, frustrating teams expecting Slack-style updates.
Performance degrades with large numbers of projects and issues, and no native mobile app forces reliance on a mobile-unfriendly web interface.
Hidden costs accumulate through required hosting fees, paid plugins for enterprise features, and ongoing IT maintenance overhead.
Reasons to switch
Why people leave Redmine
The recurring reasons buyers give for replacing Redmine. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where Redmine fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
What gets migrated
Redmine object support
Object-by-object support for Redmine migrations. Per-pair details surface during scoping.
Projects
Fully supportedProjects and subprojects map cleanly. We pull the full project hierarchy via the REST API or direct DB access and recreate parent-child relationships in the destination. No special handling required.
Issues
Mapping requiredIssues are the core object. We map standard fields (status, priority, tracker, assignee, due date) and handle custom fields as a separate step. Note that CSV export excludes history—a full issue history requires DB-level extraction or a plugin.
Time Entries
Fully supportedTime entries are first-class objects linked to Issues and Users. We export them via CSV or the REST API and map them to equivalent time-logging objects in the destination PM tool.
Users
Mapping requiredRedmine Users include login, name, email, admin flag, and custom fields. We preserve the user identity but note that Redmine does not store a password hash compatible with most SaaS destinations, so credential migration is not possible.
Custom Fields
Mapping requiredCustom Fields are defined separately via /custom_fields.json and apply to specific object types (issue, project, time_entry). We retrieve all definitions first, then map values per object during migration.
Wiki Pages
Mapping requiredWiki pages are stored as separate objects with wiki text and attachments. Migration requires preserving the content format and file references, which may not be compatible with destination wikis.
Documents
Mapping requiredDocuments are project-level file attachments with titles and descriptions but no direct Issue linkage. We map them as files in the destination project context.
Versions
Fully supportedVersions (also called milestones) are straightforward to map. They carry a name, description, status, and due date that transfer cleanly to destination Versions or Milestones.
Enumerations
Mapping requiredEnumerations cover issue statuses, priorities, document categories, and activities. We map the active enumeration values; deprecated values are omitted unless explicitly requested.
News
Mapping requiredNews entries are lightweight posts tied to projects. We migrate the title, description, and author but note that the 'news' concept does not exist in most SaaS PM tools and typically gets mapped to project announcements or dropped.
Attachments
Mapping requiredAttachments are stored both in the database (metadata) and on the filesystem under Redmine's /files directory. We retrieve both layers and re-upload files to the destination, preserving filename and content.
Groups
Mapping requiredGroups are used to organize Users for role assignment. We recreate Groups in the destination and repopulate their membership. Note that some destination tools do not have a Group object and require flattening to individual user permissions.
Trackers
Mapping requiredTrackers (Bug, Feature, Support, etc.) are enumerations that categorize Issues. We map Tracker names and custom tracker definitions, noting that destination tools may use different taxonomy for issue types.
| Object | Support | Notes |
|---|---|---|
| Projects | Fully supported | Projects and subprojects map cleanly. We pull the full project hierarchy via the REST API or direct DB access and recreate parent-child relationships in the destination. No special handling required. |
| Issues | Mapping required | Issues are the core object. We map standard fields (status, priority, tracker, assignee, due date) and handle custom fields as a separate step. Note that CSV export excludes history—a full issue history requires DB-level extraction or a plugin. |
| Time Entries | Fully supported | Time entries are first-class objects linked to Issues and Users. We export them via CSV or the REST API and map them to equivalent time-logging objects in the destination PM tool. |
| Users | Mapping required | Redmine Users include login, name, email, admin flag, and custom fields. We preserve the user identity but note that Redmine does not store a password hash compatible with most SaaS destinations, so credential migration is not possible. |
| Custom Fields | Mapping required | Custom Fields are defined separately via /custom_fields.json and apply to specific object types (issue, project, time_entry). We retrieve all definitions first, then map values per object during migration. |
| Wiki Pages | Mapping required | Wiki pages are stored as separate objects with wiki text and attachments. Migration requires preserving the content format and file references, which may not be compatible with destination wikis. |
| Documents | Mapping required | Documents are project-level file attachments with titles and descriptions but no direct Issue linkage. We map them as files in the destination project context. |
| Versions | Fully supported | Versions (also called milestones) are straightforward to map. They carry a name, description, status, and due date that transfer cleanly to destination Versions or Milestones. |
| Enumerations | Mapping required | Enumerations cover issue statuses, priorities, document categories, and activities. We map the active enumeration values; deprecated values are omitted unless explicitly requested. |
| News | Mapping required | News entries are lightweight posts tied to projects. We migrate the title, description, and author but note that the 'news' concept does not exist in most SaaS PM tools and typically gets mapped to project announcements or dropped. |
| Attachments | Mapping required | Attachments are stored both in the database (metadata) and on the filesystem under Redmine's /files directory. We retrieve both layers and re-upload files to the destination, preserving filename and content. |
| Groups | Mapping required | Groups are used to organize Users for role assignment. We recreate Groups in the destination and repopulate their membership. Note that some destination tools do not have a Group object and require flattening to individual user permissions. |
| Trackers | Mapping required | Trackers (Bug, Feature, Support, etc.) are enumerations that categorize Issues. We map Tracker names and custom tracker definitions, noting that destination tools may use different taxonomy for issue types. |
Gotchas
What to watch for in Redmine migrations
Issues we've hit on past Redmine migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
No built-in CSV import function for Issues
Uploaded files stored on filesystem, not in the database
CSV exports exclude issue history and journals
Custom field definitions require a separate API call
REST API disabled by default on most installations
| Severity | Issue |
|---|---|
| High | No built-in CSV import function for Issues |
| High | Uploaded files stored on filesystem, not in the database |
| Medium | CSV exports exclude issue history and journals |
| Medium | Custom field definitions require a separate API call |
| Medium | REST API disabled by default on most installations |
Leaving Redmine?
Where Redmine customers move next
5 destinations Redmine can migrate to.
How a Redmine migration works
Four steps, Redmine-specific
Connect
API key or session cookie (admin required for most endpoints) into Redmine. Scopes limited to read-only on the data we move.
Map
We translate Redmine-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate Redmine quirks before production.
Migrate
Full migration with Redmine rate-limit handling. Rollback available throughout.
FAQ
Redmine migration FAQ
Answers to the questions buyers ask most during Redmine migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your Redmine migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther project management tools we support
Ready when you are
Migrate Redmine.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your Redmine setup and destination — written quote back within a business day.