How to upgrade unsupported Redmine 5.1 and older to 7.0
Moving an unsupported Redmine 5.1 or older installation to 7.0.x is a planning exercise across the Ruby runtime, the database server, every installed plugin and the stored data, and it cannot be handled as a single package update. Redmine 7.0.x is the only line that receives new features, bug fixes and security updates, while 5.1.x and older no longer receive security fixes, so exposure grows with each unpatched vulnerability. Act now if the instance is reachable from the internet, holds project data under a compliance obligation, or depends on plugins you cannot yet confirm will run on 7.0. The exact intermediate releases you must pass through have to be confirmed against the Redmine upgrade guide and the release notes for each version before you schedule any work.
Start with the stack underneath Redmine. Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0, and it does not support JRuby. Record the Ruby and Rails versions of your current installation and the gems pinned in its Gemfile.lock, then decide whether the host can be rebuilt on a supported Ruby or whether a new application server is the simpler route. On the database side, confirm your engine and version against the installation guide: PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, SQL Server 2012 or higher, or SQLite, which the guide says is not suited to multi-user production use. An older database server may need its own upgrade before Redmine can move, and that work belongs in the same plan.
Plugins often take the most planning time. Inventory every installed plugin and theme, including its source, its most recent release and whether its maintainer still responds. For each one, establish whether a version exists for Redmine 7.0 and, if not, whether its function can be covered by core features or by another maintained plugin. Abandoned plugins may need to be forked, rewritten or removed, and each decision changes the test scope. Review the data as well, including custom fields, workflows, roles and any tables a plugin added to the database. The upgrade guide describes copying configuration, uploaded files and third-party plugins to the new installation, then running the database migration and the plugin migration task, so every plugin must be accounted for before the cutover date is set.
Whether the jump can be made in one step or needs stops at intermediate releases is the question the upgrade guide and each release's notes must answer, so do not assume a direct path from your current version. Build a staging environment from a fresh copy of production data and run the full sequence there, recording the output and elapsed time of each migration step. Confirm which backups support a rollback, because reverting the application code alone may not restore the database to its prior state. Before accepting any quote from an implementation partner, ask for a written list of upgrade stops, the test scripts each stop will pass and the rollback point for each stage. Those documents tell you what the work includes and how much of it depends on your plugins and data.
What changes when you upgrade Redmine from 5.1 to 7.0
This table compares what changes between Redmine 5.1 and 7.0 across the runtime, framework, database, migration tools, sign-on and API. Read each row as a question to answer before the upgrade starts. The main takeaway is that the Ruby, database and plugin checks determine your path, while the last two rows are items to confirm in the 7.0 release notes.
| Change | What it means for a 5.1 installation | Action needed |
|---|---|---|
| Ruby runtime | Redmine 7.0 supports Ruby 3.2, 3.3, 3.4 and 4.0 only, and does not support JRuby. | Confirm your current Ruby version and plan a runtime upgrade before the application move. |
| Rails framework | Redmine 7.0 runs on Rails 8.1. Custom code and plugins written for older Rails versions need review. | Test each plugin and customization on a staging copy before cutover. |
| Database engines | Supported: PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED, SQL Server 2012 or higher, and SQLite for single-user use only. | Confirm your database version is in range and set MySQL isolation to READ COMMITTED. |
| Trac and Mantis importers | The built-in importers are obsolete and not working. Other migration scripts are neither tested nor supported. | Plan a separate data migration for tickets and history, and test it on a copy. |
| Single sign-on | LDAP is native. SAML and OpenID Connect are not core features and depend on plugins or an authenticating reverse proxy. | Choose the sign-on method early and confirm plugin support for Redmine 7.0 before cutover. |
| REST API | An administrator must enable the REST API before API clients can connect. | Enable it deliberately and confirm each integration uses a supported authentication method. |
| Rails 8 move (verify) | The move to Rails 8 may change behavior that affects your installation and custom code. | Verify the Rails 8 items in the 7.0 release notes against your customizations. |
| Sudo mode default (verify) | Confirm in the release notes whether sudo mode is on by default and how it affects administrator actions. | Brief administrators before cutover and test their routine workflows. |
Replacing abandoned plugins before the Redmine jump
Start by listing every third-party plugin and theme on the existing 5.1 or older installation, including the ones nobody remembers installing. Read the plugins directory under the Redmine root and the Gemfile.local and plugin folders, and record for each one its name, the version in use, the author or repository it came from, the Redmine versions it declares compatibility with, and the people who use the features it provides. Themes deserve the same treatment because they often override view templates and stylesheets that change during the move. Ask project managers and administrators which features they rely on, since a plugin that adds a custom field type, a workflow hook or a report may be used by only one team and easy to miss in a code review.
Next, check each entry against the target stack. Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0, and it does not support JRuby, so a plugin that depends on an older Rails API, a gem pinned below the required version, or a JRuby-only build will not load. Review the plugin's source for deprecated calls, gem dependencies and any assumptions about database adapters, then test it on a copy of the database in a staging instance running the target versions. Record each result as one of three outcomes: works unchanged, needs a patch, or cannot run. Confirm each outcome against the plugin's own repository and issue tracker, because a release tag can lag behind the code on the default branch.
The decision for each plugin is one of three choices: upgrade it, replace it, or retire it. Upgrade when the maintainer still ships compatible releases or when a fork is actively maintained and the license permits your use. Replace when the feature matters but the plugin is dead, which may mean a newer maintained plugin, a core feature added in a later Redmine release, or a small internal plugin written to the same need. Retire when the feature is unused, duplicated by configuration, or better handled by a separate tool. Document the reasoning for each choice in the change record so auditors and the next administrator can see why a plugin disappeared.
An abandoned plugin with no maintainer changes the plan in two ways. First, it turns a configuration question into a development task, because someone must either patch the code and own every future patch or accept that the feature will stop working at the next upgrade. Treat that ownership as a recurring cost and name the person or team who will carry it before work starts. Second, it removes the vendor's security response. Whoever takes on the plugin should subscribe to the Redmine security announcements and review the plugin's code for the kinds of issues that appear in unmaintained extensions, such as unescaped output or weak permission checks on new routes. Where no one can take ownership, retirement or replacement is usually the safer choice.
Plugin migrations run as a separate step after core migrations because the core schema must be stable before plugin code can be tested against it. The Redmine upgrade procedure runs db:migrate first and then redmine:plugins:migrate, so a plugin migration that depends on core tables will fail if the core step has not finished cleanly. Keep the two steps distinct in the runbook, record the output of each, and roll back the plugin step separately if a plugin migration fails. Confirm the exact command sequence in the upgrade guide for the version you are moving to, since the order in your environment should match the documentation rather than habit.
Redmine upgrade preparation: backups, inventory and a test copy
Most failed upgrades come from work skipped before the first command runs. The four items below form a sequence: a verified backup gives you a way back, the inventory defines what the new installation must carry over, the test copy proves the upgrade on your data, and a named owner decides when production is ready to change.
Full database and uploads backup
Take a complete database dump and a copy of the uploaded files directory before anything changes, and store both outside the server being upgraded. Confirm the backup restores by loading it into a scratch database and checking that issue counts, attachments and wiki pages match production. Record the Redmine version, Ruby version and database engine in the backup note so a rollback targets the correct stack. The upgrade guide describes the backup step; your own restore test is what proves it.
Configuration and plugin inventory
List everything the installation depends on: configuration.yml, email delivery settings, third-party plugins and their versions, themes, custom fields, workflows, roles and any LDAP or reverse proxy settings. For each plugin, note whether its maintainer still publishes a release for Redmine 7.0, because abandoned plugins are the most common blocker in this jump. Include the web server, proxy headers and authentication rules that sit in front of Redmine, since they change how users sign in after the move.
Restored test environment on target versions
Build a copy of production on the Ruby and database versions the target Redmine line supports, then restore the backup into it. Run the migration steps there first, including the plugin migration task, and log every error and warning. Check that LDAP sign-in, email notifications, attachments and the REST API still behave as before. Ask your implementation partner to show the test log and the list of changed settings so the production run repeats the same steps.
Named sign-off owner
Assign one person who accepts the test results and approves the production window, with a deputy for absences. This owner confirms the inventory is complete, reviews plugin decisions that remove or replace functionality, and signs off on the post-upgrade checks, such as role permissions and workflow transitions. Without a single decision maker, untested plugin gaps tend to surface after users are already working in the new version.
How to stage the jump across intermediate releases
The first decision is how many hops the jump needs, and that count is set by the release lines between your installation and Redmine 7.0. Redmine 5.1.x and older are unsupported, so the path has to pass through the supported lines: 6.0.x, which receives only important security updates, 6.1.x, which receives bug fixes and security updates, and 7.0.x, the fully supported line. The latest stable releases on the download page are 6.0.11 (dated August 26, 2026), 6.1.5 and 7.0.2 (both dated October 1, 2026). Map your current version against those lines and list every intermediate release that the upgrade guide documents between 5.1 and your first target. Do not assume that one step is enough because the endpoints are known.
Before you fix the plan, confirm the exact intermediate versions, the Ruby version each one requires, and any migration notes in the Redmine upgrade guide and the release notes for each release. Ruby requirements can change the path more than Redmine versions do. Redmine 7.0 supports Ruby 3.2, 3.3, 3.4 and 4.0, but the Ruby versions needed by the earlier releases in your path have to be checked separately, and a hop may require a Ruby upgrade before the Redmine upgrade can run. Record the Ruby version, the database server version and the supported database engine for each hop, because the installation guide sets its own requirements for MySQL, PostgreSQL, SQL Server and SQLite.
Each hop needs its own backup, migration and test cycle. Before every hop, back up the database and the uploaded files, then copy the configuration, uploads and third-party plugins to the new installation. Run db:migrate and redmine:plugins:migrate as the upgrade guide describes, clear the cache and restart. Then test the features your teams depend on, such as issue workflows, custom fields, email issue creation, LDAP sign-in, API integrations and any plugin that changed behavior. The backup taken before a hop is also your rollback point for that hop. A snapshot that has never been restored in a test environment is not proven, so restore one at least once during planning and time the restore.
Stage the hops in a copy of production before touching the live system, and treat every hop as a go or no-go decision. Check each plugin against the target release of that hop, since an abandoned plugin can block a step and may need replacing before the path can continue. Decide in advance whether a failed hop is repaired, rolled back or re-run from the last good backup. Ask any partner to put the hop list, the Ruby and database changes per hop, the test scripts and the rollback procedure into the written scope, so that the number of cycles and the effort behind them are visible before work starts.
Redmine upgrade sequence with checks and rollback points
This sequence moves an unsupported Redmine 5.1 or older installation to Redmine 7.0 in stages that each have a verification check and a restore action. The old installation stays untouched until the new build passes its checks, so any step can be reversed without losing project data.
Freeze target versions and confirm the path
Before anything changes, the team writes down the target Redmine 7.0 release, the Ruby version from the supported list for 7.0, the database engine and version, and every plugin with the version that supports the target. The upgrade guide is checked for any required intermediate stops between the current release and 7.0. Confirm each plugin has a maintained release for the target or a named replacement. The output is a signed-off version matrix. Rollback point: none is needed, because nothing has changed. The restore action is to keep the current production system running as the baseline.
Back up database and uploaded files
The administrator takes a full database dump and a copy of the files directory that holds uploaded attachments, with the Redmine configuration file captured alongside them. The check is a test restore of the dump into a scratch database, followed by a count of attachment files compared with the source. Store the backup set outside the host being upgraded. This set is the rollback point for every later step. The restore action is to load the dump into the original database, return the files directory, and confirm that a known project, issue and attachment open correctly.
Build the new installation
The engineer installs the target Ruby version and the target database client on a new host or a new directory, then installs Redmine 7.0 with its bundled gems. The check is that bundle install completes without errors, the application boots against an empty test database, and the reported version matches the target. Compare the list of optional components, such as ImageMagick or Sidekiq, against the old host. The old installation is not modified. The restore action is to discard the new build and keep serving from the original installation, which needs no change.
Copy configuration, uploads and plugins
The engineer copies the configuration file and database settings into the new build, then places the uploaded files in the location the new installation expects. Only plugins confirmed for the target version are copied into the plugins directory, and any replaced plugin is installed from its maintained source. The check is a file listing diff against the backup set, plus a boot test that shows no missing plugin errors. The rollback point is the backup from the second step. The restore action is to delete the copied files and re-copy them from that backup set.
Run database and plugin migrations
The engineer runs the core database migration and then the plugin migration task against the copied database. The check is that both commands finish without errors and the reported schema version matches the target release. Note any migration that warns about data changes, and review the log before continuing. Migrations are not assumed to be reversible, so the rollback point is the database dump taken before this step. The restore action is to load that dump into the database, restore the old code, and confirm the old installation serves requests again.
Clear cache and restart services
The engineer clears the application cache, restarts the web process and any background workers, and runs a smoke test covering login, a project issue list, an attachment download, a new issue, and a test notification email. Confirm that LDAP or other authentication still works if it is used. The output is a passing smoke test recorded in the change log. If any check fails, the rollback point is the database dump from the second step. The restore action is to stop the new services, restore the database and the old code, and restart the original installation.
Testing and rollback for a Redmine upgrade
A Redmine upgrade from 5.1 or older is only ready for cutover when the test plan covers every path users and integrations depend on, not just whether the application starts. Begin with authentication. Test each sign-in method the installation uses, whether native accounts, LDAP through the built-in integration, or single sign-on provided by a plugin or an authenticating reverse proxy. For each one, confirm that new and existing users log in, that disabled accounts are refused, and that group membership still maps to the right roles. Then test roles and permissions by project. Sign in as a representative user for each role and check what they can see, edit, and close. Workflows need the same attention: walk each tracker through its status transitions, and confirm that custom fields still display, validate, and enforce required values on the correct trackers and statuses.
The second group of tests covers the features that tend to break quietly. Send email to the address used for issue creation and confirm that the issue lands in the right project with the expected tracker, author, and custom field values. Upload attachments of several sizes and types, then download them and check that previews and file paths work after the restore. Exercise the REST API with a per-user API key, sent both as a request parameter and in the X-Redmine-API-Key header, and confirm that the administrator has enabled the API first. Read calls on issues, projects, users, and time entries should return the same data as before. Verify scheduled jobs such as reminder emails and cleanup tasks by running them manually and checking the logs. Finally, test each optional component the installation relies on, including Sidekiq for background jobs, ImageMagick, Ghostscript, and Pandoc, because a missing binary often fails only when a user triggers the feature.
A rollback plan is only useful if it restores the database and the uploaded files to the same point in time. Redmine stores issues, journals, and settings in the database, while attachments, configuration, and third-party plugins live on the filesystem. If one is restored and the other is not, the application can show issues whose attachments are missing or attachments that point to records that no longer exist. The upgrade guide calls for backing up the database and uploaded files, along with configuration and plugins, before any migration runs. Define the rollback as a single procedure with a named snapshot of each part, taken in the same maintenance window and labeled with the Redmine version and the pre-upgrade migration state. Record the exact commands and the order of restoration, and state who has authority to start it. Rehearse the restore on a copy of production before the cutover date, and time the rehearsal so the team knows whether the rollback fits inside the agreed outage window.
The go or no-go decision should be made against written criteria before the maintenance window opens, not during it. Set the criteria as a checklist covering the test results from authentication, roles, workflows, email, API, scheduled jobs, and optional components, with each item marked pass, fail, or accepted with a named owner. Add technical conditions: the database migration completed without errors on the rehearsal, the backup snapshots are verified and readable, the replacement plugins have passed their tests, and the monitoring and log review are in place. Name the decision maker and the person who can trigger rollback, and agree the latest time at which a rollback is still practical. Once production migrations begin, the rollback path changes, so treat that step as the last point to stop without a restore. Confirm the Ruby and database versions against the installation guide for the target release before the freeze, because a mismatch found after cutover turns a simple stop into a restoration.
What makes a Redmine upgrade from 5.1 take longer
This table compares the factors that expand or shrink an upgrade from Redmine 5.1 or older to 7.0. Read each row as a question to answer during scoping, since the same driver can add little or a great deal of work depending on your setup. The main takeaway is that plugins, local customization and the age of the runtime often matter more than the version number alone.
| Driver | What increases the work | What reduces it |
|---|---|---|
| Intermediate releases | Each skipped release adds a migration step to test before reaching the 7.0 line | Confirm the required stepping path in the upgrade guide before planning the sequence |
| Plugins and themes | Abandoned plugins with no release for 7.0 must be replaced or rebuilt | Inventory every plugin and theme and confirm a maintained version exists for each target release |
| Local customization | Patched core files, custom views and hooks must be reapplied and retested | Keep changes in plugins or documented overrides, and record every core file that was modified |
| Data volume and attachments | Large databases and attachment stores lengthen migration runs, backups and restores | Archive closed projects and remove unused attachments before the migration window |
| Database engine | A SQLite file adds a conversion step, since SQLite is not suited to multi-user production use | Existing PostgreSQL or MySQL 8.0 to 8.4 (READ COMMITTED) setups move forward with fewer changes |
| Ruby and operating system runtime | Older Ruby or OS packages may force a platform rebuild before Redmine itself is upgraded | A current OS and a Ruby version in the 3.2 to 4.0 range already in place; JRuby is not supported |
| Authentication setup | SAML or OpenID Connect through a plugin or reverse proxy adds components to rebuild and test | Native LDAP authentication or an existing proxy configuration keeps login testing narrower |
| REST API integrations | Each client needs its authentication method and response format rechecked after the upgrade | List every consuming system, then test core resources such as issues, projects, users and time entries |
| Environments to test | Each environment, such as development, test, staging and production, repeats the upgrade and plugin checks | Rehearse on a recent copy of production data and keep all environments on matching versions |
Questions buyers ask about upgrading unsupported Redmine
Does upgrading Redmine cost money if the software is free?
Yes, the upgrade costs money even though Redmine has no license fee. Redmine is free under the GNU General Public License v2, so the spend goes to the work around the software: hosting in infrastructure you control, implementation labor, plugin replacement or development, testing, and ongoing upkeep. Most of the upgrade effort is one-time (assessment, migration, plugin work, cutover). Hosting, security updates and support retainers recur after go-live. A written quote should separate these lines so you can see what is one-time and what continues.
What drives the cost of upgrading an old Redmine installation?
The biggest drivers are how far the installation is behind, how many plugins it runs, and how much customization sits on top. Redmine 5.1 and older are unsupported, so the Ruby runtime, the database server and the operating system often need upgrading before Redmine itself can move to 7.0, which supports Ruby 3.2, 3.3, 3.4 and 4.0 with Rails 8.1. Each plugin that is abandoned, forked or unavailable for the target version adds replacement or rewrite work. Data volume, custom fields, workflows, LDAP settings and the number of environments (staging, test, production) also change the effort. Ask for the estimate to name each of these factors.
What should a written quote for a Redmine upgrade include?
A useful quote lists the scope before the price. Ask for the current version and the target version, an inventory of installed plugins and themes with a status for each, the environments in scope, and the database and operating system versions. The quote should name the migration steps, the backup and rollback approach, the test plan, and who signs off each phase. Ask which items are fixed in scope and which are priced as changes if the inventory turns up more work. Separate one-time implementation from recurring hosting, support or retainer terms, and confirm what is excluded, such as third-party hosting fees or new feature requests.
How long does upgrading Redmine 5.1 or older take?
The schedule depends on the work in front of the team, not on a fixed number of weeks. The main inputs are the number of versions between your installation and 7.0, the state of the Ruby and database layers, the plugin list and how many plugins need replacement, the data volume to migrate, and how quickly your business users can test. Approval cycles and change windows also set the calendar. Before you commit to a date, ask for an assessment that produces a dated plan with gates for each environment. Confirm the exact upgrade sequence against the Redmine upgrade guide for each release you pass through.
What do we need to provide before a Redmine upgrade starts?
The upgrade needs access and decisions from your side. Plan for administrator access to the server or hosting account, database credentials and a current backup you can restore, and access to the uploaded files directory and configuration. Name a plugin owner for each installed plugin who can explain why it is used and who approves replacing it. Provide test users from each business group who will exercise their workflows, and a sponsor who approves scope changes and go-live. You also need the LDAP or email settings, DNS and certificate details, and an agreed change window.
Can our internal IT team upgrade Redmine from 5.1 without outside help?
Often yes, if the team has Linux administration and Ruby on Rails operations experience and time to run a staged project. The Redmine upgrade procedure is documented: back up the database and uploaded files, copy configuration, uploads and third-party plugins to the new installation, run the database migrations and plugin migrations, clear the cache and restart. The harder parts are underneath it: Ruby and database upgrades, plugins with no maintainer, and testing workflows that nobody has documented. Teams that lack spare capacity for staging and testing usually benefit from a fixed-scope engagement or a retainer. Decide this after the assessment, based on the plugin inventory and your team's available hours.
What breaks most often when old Redmine plugins are left behind?
The most common problem is a plugin that works on the old Ruby and Rails versions but fails once the platform moves to Rails 8.1 and a newer Ruby. The plugin may need code changes, a replacement, or removal, and its data or custom fields may depend on it. Themes and custom styling can also break after a major release. Check whether each plugin has a release for Redmine 7.0, whether its maintainer is active, and whether it adds menus, permissions or API behavior that users rely on. Also note that Redmine's built-in importers for Trac and Mantis are marked obsolete and not working, so do not assume older data imports still function.
How DeployOpen scopes and delivers a Redmine upgrade
DeployOpen plans an upgrade from unsupported Redmine 5.1 or older as a fixed-scope engagement, with the scope agreed in writing before work starts. The work covers the Ruby and database versions underneath, abandoned plugins, staged migrations and a tested rollback path. Ongoing support and upgrades are available as a retainer once the system reaches Redmine 7.0.
How we scope
- Inventory the current version, database, Ruby runtime, plugins and themes before quoting.
- Map each plugin to a 7.0-compatible replacement, a port or a retirement decision.
- Write the scope, deliverables and timeline into a fixed-scope agreement before work starts.
How we build
- Stage the jump through the supported intermediate steps, confirming each migration runs cleanly.
- Rebuild the Ruby and database layers on versions Redmine 7.0 supports, such as Ruby 3.2, 3.3, 3.4 or 4.0.
- Run db:migrate and redmine:plugins:migrate on a copy of production, with plugin and theme checks.
How we hand over
- Deliver a runbook covering the upgrade steps, configuration changes and rollback procedure.
- Document backup and restore checks, plugin versions and any retired or replaced extensions.
- Walk your administrators through the new installation, including the sudo mode default in 7.0.
How we support
- Offer ongoing support, upgrades and testing as a retainer after the go-live.
- Agree the support boundary in writing, including who patches plugins after future Redmine releases.
- Confirm which Redmine line you will run after go-live, since update coverage differs between 6.x and 7.0.
