Upgrading Redmine to 7.0: what changes, what breaks, and the steps

Redmine 7.0 moved to Rails 8.1 and runs on Ruby 3.2 to 4.0. Here is what that means for your plugins, the exact upgrade procedure from redmine.org, and the checklist that keeps the upgrade to one afternoon.

Redmine 7.0.0 was released on 30 June 2026, and 7.0.2 followed on 1 October alongside 6.1.5. If you run Redmine yourself, this is the upgrade of the year, and it is a bigger step than the 6.0 to 6.1 move was, because the framework underneath changed. This guide covers the three things that decide whether your upgrade is an afternoon or a week: the requirements, the plugins, and the order of operations. The commands are redmine.org's own, quoted from the RedmineUpgrade wiki page, so you can check every line against the source.

If you are on a managed plan, the upgrade is your provider's job. The useful questions to ask them are at the end.

What changed underneath

The requirements table on redmine.org's RedmineInstall page is the whole story in four lines. Redmine 7.0 runs on Ruby 3.2, 3.3, 3.4 or 4.0 and on Rails 8.1. Redmine 6.1 runs on Ruby 3.2 to 3.4 and Rails 7.2. Redmine 6.0 runs on Ruby 3.1 to 3.3 and Rails 7.2. For databases, 7.0 supports PostgreSQL 14, MySQL 8.0 to 8.4, SQLite 3 and SQL Server newer than 2012, the same as 6.1.

Two consequences follow. First, if your server still runs Ruby 3.1, which 6.0 allowed, you must upgrade Ruby before you upgrade Redmine, because 7.0 will not start on it. Second, and this is the one that costs time, Rails moved from 7.2 to 8.1. Redmine plugins are Rails engines, and a plugin written against Rails 7.2 may or may not load under 8.1. The core application is tested on it. Your plugins are not, until you test them.

One footnote from the same page is worth repeating: on Ruby 4.0, redmine.org recommends 4.0.4 or later, because 4.0.0 to 4.0.3 slow down wiki rendering.

What 7.0 brings

The 7.0.0 changelog is long, and most of it is quality of life. The items that change how people use the application day to day are these. Sudo mode is now on by default, so administrative actions ask for the password again. Microsoft Office and LibreOffice Writer files can be previewed in the browser, PDF attachments and repository files open in the browser instead of downloading, and AVIF images are supported. Users can choose to be added as watchers automatically when they are assigned an issue, and there is a notification option that sends mail for watched objects only. New issues can carry a default due date set as an offset from today, and the private flag can have a default value. The assignee drop-down can be ordered by users or by group, and the "use current date as start date for new issues" setting is off by default on new installations. Two things were deprecated: the Mantis and Trac migration rake tasks, which the changelog describes as broken.

None of that requires action during the upgrade. Two of them deserve a look afterwards: the sudo mode default, which your administrators will notice the first time they open a settings page, and the start-date default, which only affects fresh installations and leaves an upgraded one as it was.

Before you start: the plugin check

This is the step that decides the week. Make a list of every plugin in your plugins directory and, for each one, find out three things: who maintains it, whether a release states support for Redmine 7.0 or Rails 8.1, and when it was last updated. A plugin with no release since the 7.0 announcement in June is a risk, not a certainty, but it is the first one to test. A plugin whose maintainer has gone quiet for a year is a decision you should make before the upgrade, not during it: either find a replacement or plan to run without it.

Then build a staging copy. Restore last night's backup onto a second server or a container, run the upgrade there first, and let the people who use the plugins try their daily work on it. Our guide to backing up and restoring Redmine covers the restore. If the staging upgrade is clean, the production upgrade is a repeat of it. If it is not, you have found the problem on a copy nobody depends on.

The upgrade, in redmine.org's order

These are the steps from the RedmineUpgrade wiki page for a stable release downloaded as an archive. The wording below is ours, the commands are theirs.

Check the requirements. Ruby, Rails and the database from the table above. Upgrade Ruby first if you have to.

Back up. The database and the files directory, together, off the server. Do not skip this because the staging run was clean.

Extract the new release into a new directory. Set the owner and group so the application server can read it, and make files, log and tmp writable.

Copy your configuration across. config/database.yml and config/configuration.yml go into the new config directory. The wiki marks one line in capitals and so will we: do not overwrite the new config/settings.yml with your old one.

Copy the files directory from the old installation into the new one.

Copy your plugins, and only the ones you installed yourself, into the new plugins directory. Plugins that shipped with your previous version stay behind.

Install the gems.

bundle config set --local without 'development test'
bundle install

If you keep gems that Redmine itself does not need, they belong in a Gemfile.local in the Redmine root. Check public/themes for themes you installed and copy them over, preferably after checking for a newer version of each.

Migrate the database. From the new directory:

bundle exec rake db:migrate RAILS_ENV=production

Then the plugins' own migrations:

bundle exec rake redmine:plugins:migrate RAILS_ENV=production

This is the redmine db migrate step that people search for when it fails. When it fails, the message names the migration and, almost always, the plugin that owns it. That is the plugin from your list that was not ready for 8.1.

Clear the cache and restart.

bundle exec rake tmp:cache:clear RAILS_ENV=production

Restart the application server, whichever you run. Then open Administration, Roles and permissions, and check the permissions for anything new, because new features arrive with their permissions unset.

When it goes wrong

Three failures account for most of the upgrade stories we hear.

The application will not start, and the log names a gem or a method that no longer exists. That is a plugin written for the old Rails. Move it out of plugins, restart, and decide whether to update it or live without it.

The core migration runs and a plugin migration fails. Same cause, one step later. The core database is already migrated at that point, which is why you do this on staging first.

Everything starts and a page is blank or throws an error. Usually a theme or a plugin that overrides a view that changed. Switch to the default theme first, then disable plugins one at a time.

In every case the recovery is the backup you took in step two: restore it onto the old installation directory, which you have not deleted, and you are back where you were.

If someone else runs your Redmine

On a managed plan, the questions to ask your provider are simple. Which version is the workspace on today, and when is 7.0 scheduled? Which plugins are installed, and has the provider tested each one on 7.0? Is there a staging copy you can try before the production upgrade? What is the rollback if it fails?

RedminePRO is managed Redmine at a flat $29 a month for 25 users, with full Redmine admin access on every plan. Your workspace runs in the US, Ireland, France or India, your choice at signup, and migration from your current Redmine is done for you. Upgrades are part of what the plan includes, which is the point of paying for one: the plugin check, the staging run and the rollback plan above are the provider's work, not yours.

If you are weighing the two, the what is Redmine guide puts a number on the time self-hosting takes, and the migration service starts with a free assessment of what you have.

Frequently asked questions

Can I upgrade straight from Redmine 5.x or 6.0 to 7.0?
The RedmineUpgrade page gives one procedure for all stable releases, so there is no required stop at 6.1. The constraints are the requirements: 7.0 needs Ruby 3.2 or newer, so a 6.0 server on Ruby 3.1 upgrades Ruby first, and every plugin has to load under Rails 8.1 regardless of where you start.

Which Ruby version should I use for Redmine 7.0?
Redmine 7.0 supports Ruby 3.2, 3.3, 3.4 and 4.0. If you choose 4.0, redmine.org recommends 4.0.4 or later because 4.0.0 to 4.0.3 slow down wiki rendering.

What does rake db:migrate do during a Redmine upgrade?
It applies the database changes the new version needs, in order. redmine:plugins:migrate does the same for each plugin's tables. If the second command fails, the message names the plugin whose migration did not run, and that plugin is the one to update or remove.

Is Redmine 6.1 still supported after 7.0?
Yes. As of October 2026, 7.0 is the latest stable version and 6.1 continues to receive bug fixes and security updates, while 6.0 is listed as legacy. 6.1 is a sound place to be for a few months. 6.0 is not.