Why a Redmine 6 to 7 upgrade cannot wait for the next maintenance window
If you run Redmine 6.0 or 6.1 with plugins, LDAP authentication or a reverse proxy in front of it, the upgrade to 7.0 should be scheduled as its own project, separate from routine patching. Redmine 7.0.x is the fully supported line, receiving new features, bug fixes and security updates. Redmine 6.1.x receives only bug fixes and security fixes, and 6.0.x receives only important security updates, so the gap between your installation and the supported line widens with each release. Your exposure depends on the line you run as much as on when you last patched.
The supported path leads to 7.0.2, the latest stable release listed on the Redmine download page, which is dated October 1, 2026. Confirm the current listing before you plan, because the latest release on each line can change. Treat the move as a platform change. 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. If your servers run an older Ruby or a JRuby-based stack, the interpreter has to change before Redmine can start. A version number bump does not cover that work.
Plugins carry most of the compatibility risk. Each plugin in your installation needs a 7.0-compatible release from its maintainer, and some may depend on Rails behavior or view code that changed with Rails 8.1. Build an inventory now: list every plugin, its current version, its source, whether it is still maintained, and the Ruby gems it pulls in. Check your LDAP settings and your reverse proxy configuration too, since authentication and the headers passed through the proxy are part of the working system. Ask each plugin maintainer, in writing, which 7.0.x release they test against.
Waiting has a cost even when nothing breaks today. Each 6.x line receives fewer fixes than 7.0.x, so a defect in core or in a plugin may remain open on your line. Plan the window around a tested rollback. The upgrade guide calls for backing up the database and uploaded files, copying configuration, uploads and third-party plugins to the new installation, then running db:migrate and redmine:plugins:migrate before clearing the cache and restarting. Keep the original installation and its backup intact until the new one has been verified, so that reverting is a documented step you have already tested.
What changes in Redmine 7.0 and what each change means for your installation
This table lists the Redmine 7.0 changes that affect an upgrade from 6.0 or 6.1, with the impact on your installation and the action to take before cutover. Use it as a checklist for plugin, Ruby, runtime and administrator review. Exact release note wording and any further removals are published on the Redmine site, so confirm them there before you finalize the plan.
| Change | Impact on your installation | Action needed |
|---|---|---|
| Rails 8.1 as the framework | Redmine 7.0 runs on Rails 8.1, so the framework underneath the application changes. Plugin code and customizations that depend on framework behavior may need changes. | Test plugins and custom code against Rails 8.1 in a staging copy before upgrading production. |
| Supported Ruby versions 3.2, 3.3, 3.4 and 4.0 | Redmine 7.0 supports these Ruby versions. A server running another Ruby version must be changed before the upgrade can run. | Record your current Ruby version, plan a Ruby upgrade if needed, and confirm the supported list in the release notes. |
| Removal of JRuby support | Redmine 7.0 does not support JRuby. An installation that runs on JRuby cannot move to 7.0 on that runtime. | Confirm which Ruby runtime your installation uses. If it is JRuby, plan a move to a supported Ruby before the upgrade. |
| Removed icon classes | Plugins and themes that reference the removed icon classes may show missing icons or broken layouts in menus and administration pages. | Search plugins and themes for the removed classes, update or replace them, and test menus, forms and admin pages. |
| Sudo mode on by default | Administrators may be asked to re-authenticate before sensitive actions. API and automation users that perform those actions may fail or need a changed process. | Brief administrators on the change. Confirm which actions and API calls require sudo mode, then update scripts and integrations to handle it. |
| Outgoing webhooks added in 7.0 | Redmine 7.0 can send event notifications to external systems. This adds an outbound data path that your security and integration teams should review. | Decide whether to use webhooks. If you do, review the data each event sends and its destination, and confirm the setup steps on the Redmine site. |
Which Redmine 6 release you are on decides the first step
The first step in a Redmine 6 to 7.0 upgrade depends on which 6.x line your installation is on, because the support each line receives is different. Redmine 7.0.x is the fully supported line, receiving new features, bug fixes and security updates. Redmine 6.1.x receives bug fixes and security updates only. Redmine 6.0.x receives only important security updates. An installation on 6.0.x therefore sits on the narrowest support track of the three, and it should be planned for upgrade without delay. Confirm the line before you schedule anything, because the answer changes the order of the work.
Start by recording the exact version. Signed in as an administrator, open Administration and then Information, which shows the running Redmine version. Record the full patch number, such as 6.0.x or 6.1.x with its third digit, not only the minor line. Then compare it with the latest stable releases listed on the Redmine download page: 7.0.2 and 6.1.5, both dated October 1, 2026, and 6.0.11, dated August 26, 2026. If your patch level is behind the latest release on your line, note the gap. That gap is a finding in its own right, and it should be reviewed with your team before any upgrade is designed.
Next, confirm in the Redmine upgrade guide whether an installation on 6.0 should first move to 6.1 before it moves to 7.0. Do not assume either answer from the version numbers alone. If the guide calls for an intermediate step, each step needs its own database and file backup, its own plugin and theme compatibility check and its own rollback point. That multiplies the test cycles and extends the schedule, so the answer should be settled before you request a quote or set a cutover window.
Write down three things before you talk to any implementation partner: the exact installed version, the support line it belongs to, and whether the upgrade guide requires an intermediate step for your starting point. Ask the partner to confirm the upgrade path in writing against that information and to state which assumptions the quote depends on. A quote built on the wrong starting release will need to be revised, so this short check protects both the schedule and the budget.
Preparation before the upgrade begins: backups, inventory and a test environment
Four preparation tasks come before any Redmine 6.0 or 6.1 installation is changed. Each one produces a document or a restorable copy that the upgrade depends on, and each one protects the team if the upgrade must be reversed.
Database and files backup verified
Take a database dump and a copy of the uploaded files directory, then prove both can be restored to a separate host. The upgrade guide calls for these two backups before anything else changes. Check that attachments, the configuration file and any custom directories are included, because a dump alone does not hold uploaded files. Record the Redmine version, the database engine and the backup timestamp next to each copy so the restore team knows exactly what they are restoring.
Inventory of integrations and access
List every configuration setting, installed plugin, theme, LDAP or reverse proxy authentication path, SCM integration and REST API consumer. Note the Subversion, Git, Mercurial, Bazaar or CVS repositories linked to projects, and the scripts or services that call the API with keys or basic authentication. For each plugin and theme, ask the maintainer whether a Redmine 7.0 version exists. Themes and plugins that relied on icon classes removed in the 6.x line need checks, and any consumer you cannot name becomes a surprise after cutover.
Staging environment matching production
Build a staging environment on the same database engine and version family as production, running a Ruby version from the Redmine 7.0 installation guide (3.2, 3.3, 3.4 or 4.0). Restore a recent production backup into it and run the full migration there first. Using SQLite for this test is not a valid substitute, because the installation guide says it is not suited to multi-user production use and its behavior differs from MySQL or PostgreSQL. Staging also gives plugin owners and integration users a place to test before the production window.
Written change window and rollback owner
Agree a written change window that covers the migration, the plugin migration step, cache clearing, the restart and smoke testing. Name one rollback owner who has authority to call the rollback and knows the restore procedure from the backup card. Define go and no-go criteria in advance, such as which integrations must respond before the window closes. Tell users when Redmine will be unavailable and whether sudo mode, now on by default in Redmine 7.0, will ask administrators to re-authenticate after the upgrade.
The Redmine 6 to 7 upgrade sequence, with checks and rollback points
This sequence moves a Redmine 6.0 or 6.1 installation to 7.0 by following the upgrade guide in order. Each step closes with a check, and a rollback point is marked before any database migration runs, so the team can return to the prior release if a check fails.
Back up the database and uploaded files
The team that runs the current installation takes a full database dump and a copy of the uploaded files directory. Confirm with the upgrade guide whether the application must be stopped or placed in a maintenance window during the dump, and plan for that in advance. Restore the dump into a scratch database and compare the file copy with its source. The step is complete when the restore succeeds and both backups are stored away from the server being upgraded.
Install Redmine 7.0 beside the current release
Deploy a new 7.0 installation in its own directory, leaving the running 6.x release untouched. Confirm that the Ruby version on the host is one that Redmine 7.0 supports, which the installation guide lists as 3.2, 3.3, 3.4 or 4.0, and that the database server meets the requirements for the chosen engine. Install the bundled gems and start the default application once. The step is complete when the 7.0 installation starts and its home page loads with an empty database connection check.
Copy configuration, uploads and plugins
Copy the configuration files, the uploaded files and every third-party plugin from the current installation into the 7.0 directory. Review each plugin against its own release notes, because some plugins may need a newer version for Redmine 7.0 and an older copy can fail at startup. Keep the original files in place. The step is complete when the 7.0 installation lists the plugins it expects and the configuration file loads without errors when the application starts.
Mark the rollback point before migrating
Before any migration runs, record a named rollback point that includes the database backup from the first step, the path to the 6.x code tree, and a copy of the configuration. Write down the current schema version and the plugin versions. Confirm that the team can restore the backup into the existing database and start the 6.x release from its original directory. The step is complete when the rollback steps have been written down and someone other than the person performing the upgrade has reviewed them.
Run database and plugin migrations
From the 7.0 directory, run the database migration task and then the plugin migration task, as the upgrade guide sets out. Read the output for errors and for any plugin that reports it has no migration path. If a migration fails, stop and use the rollback point rather than running it again against a partly changed schema. The step is complete when both tasks finish without errors and the schema version reported by the application matches the 7.0 release.
Clear the cache and restart
Clear the Rails cache and any cached assets, then restart the application server and background job workers if your deployment runs them. Check the application log for startup warnings about deprecated settings or missing plugin assets. Open the home page and confirm that it loads without a server error. The step is complete when the application responds on its public address, the log shows a clean startup, and the admin login page is reachable.
Verify login, sudo mode, API and plugins
Sign in as an administrator and confirm that the admin pages load. Test the sudo mode prompt on a sensitive action, such as changing an administrator setting, and confirm that it appears and behaves as the 7.0 release notes describe, since sudo mode is enabled by default in this release. Call the REST API with a known user API key and confirm that a request for issues returns data. Open the pages of each installed plugin and check for missing icons or broken layouts, which can follow the removal of icon classes in theme or plugin code. The step is complete when each check passes or has a logged remediation.
How to test the upgrade and roll back if the 7.0 installation fails
Test the 7.0 staging copy against the work your users do on 6.x, not only against the migration log. A clean db:migrate and a dashboard that loads only show that the schema moved. The failures that matter in Redmine tend to appear in everyday paths: an issue created from the web form, a status change that should fire a workflow, a custom field that must still be required, or an email that should create an issue in the correct project. Write a short test script before the window opens, assign each check to a named person, and record the result. Run the script against a copy of production data restored into staging, because an empty database will hide problems with old custom field values, attachments and plugin settings.
Cover the integration paths separately, because each one authenticates differently. Sign in with an existing LDAP account and with an account that has never signed in to Redmine, since first login creates or updates the user record. Call the REST API with a per-user API key sent in the X-Redmine-API-Key header, and with HTTP basic authentication if any integration uses it. Confirm that issues, projects, users and time entries return the fields your scripts expect. Upload and download an attachment, including one created before the upgrade. If users reach Redmine through a reverse proxy or an SSO layer, test that path end to end, including logout and session expiry. If Sidekiq processes background jobs in your deployment, confirm that queued notifications run on the 7.0 workers. Check the Ruby and Rails requirements and any changes to sudo mode in the 7.0 release notes and the installation guide before you finalize the script.
Define the rollback before cutover and write down the decision point. The rollback restores the database and the uploaded files from the backup you verified before the upgrade began, then returns traffic to the 6.x installation. Keep the 6.x application code, its configuration files and its third-party plugins available so the old instance can start without a rebuild. Restoring the database returns Redmine to its pre-upgrade state, so any issues, comments or time entries created on 7.0 after cutover will be lost unless you capture them first or accept that loss in advance. Decide who may call the rollback, which failed checks trigger it, and how long the team will work on a failing step before it reverts.
Rehearse the restore in staging before the production window, not during it. Restore the verified database dump and the files onto a clean host, point a 6.x instance at them, and time each step, including file copy and verification. Check that attachments open, that LDAP and API logins work, and that the 6.x plugins start. The rehearsal also tests the backup itself, because a dump that fails to restore is discovered only when it is needed. Record the commands, the owner of each step and the order of operations in a runbook, and confirm the restore duration with the people who own the change window. A team that finds a missing database permission or an uploads directory left out of the backup during a rehearsal can fix it in an afternoon. The same team discovering it during a production cutover has no good option.
What makes a Redmine 7.0 upgrade take longer or cost more
This table lists the factors that change how much inventory, code review and testing a Redmine 6.0 or 6.1 to 7.0 upgrade needs. Read each row as a question to answer before requesting a quote, because effort usually comes from checking what is installed and testing it on production-like copies. The main takeaway is that a complete inventory of plugins, customizations, integrations and environments predicts scope more reliably than the version number alone.
| Driver | Why it adds effort | What to ask for in a quote |
|---|---|---|
| Third-party plugins: count and age | Each plugin must be checked against Rails 8.1 and a supported Ruby version. Plugins without a 7.0 release may need replacing or removing, and their migrations run during the upgrade. | A plugin inventory with versions, a 7.0 compatibility status for each, and a named owner for every replace or remove decision. |
| Custom themes and icon usage | Redmine 7.0 removes icon classes that older themes and plugin views may reference, so pages can render with missing icons or broken layouts. | An audit of icon and CSS references in themes and plugin views, plus a visual test plan covering the main project, issue and admin pages. |
| Custom code in the Ruby application | Patches to core models, controllers or views must be reviewed against the new framework version. Patches are harder to upgrade than plugins because they sit inside core code. | A list of patched core files, a decision on whether each patch moves to a plugin or is removed, and the Ruby version targeted. |
| Authentication: LDAP, reverse proxy and SSO plugins | LDAP is built in, but SSO depends on plugins or an authenticating reverse proxy. Sudo mode is on by default in 7.0, which can change login and sensitive action flows for users. | The authentication method for each user group, login tests for every path, and confirmation that SSO plugins or proxy rules support 7.0. |
| REST API and webhook consumers | Scripts, CI jobs and external systems that use API keys or basic authentication must keep working. Outgoing webhooks in 7.0 add consumers that need their own testing. | A list of API and webhook consumers with the endpoints used, the test cases for each, and an owner who signs off on results. |
| Database size and attachment volume | Migrations run against the full schema and data set, and large attachment stores lengthen backup, restore and rollback tests. | The database size and attachment volume from the current system, and a restore test on a copy to confirm rollback timing in your environment. |
| Database engine and any migration needed | PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED, and SQL Server 2012 or higher are supported. Moving to another engine adds a data migration on top of the version upgrade, and SQLite is not suited to multi-user production use. | Confirmation of the current engine and version against the 7.0 installation guide, and whether an engine change is included in the scope. |
| Number of environments to validate | Each environment needs its own migration run and test pass. Staging must match production plugins, themes and data closely enough for the results to count. | The number of environments, how staging data will be refreshed, and whether test results are documented per environment. |
| Optional components | ImageMagick, Ghostscript, Pandoc and Sidekiq each need version checks and functional tests. Sidekiq queues add background jobs that must be verified after the upgrade. | The list of optional components installed, the versions in use, and whether Sidekiq background jobs are in production. |
Redmine 6 to 7 upgrade questions buyers ask before hiring help
How much does a Redmine 6 to 7 upgrade cost?
The software is free, so the cost is the work around it. Redmine is released under GPL v2 with no paid edition, so the upgrade budget pays for people and infrastructure: scoping, a staging copy, plugin and theme work, testing, the production cutover, a rehearsed rollback and documentation. DeployOpen does not publish a price list. A quote follows from a written scope that names the components in play, such as plugins, themes, custom code, integrations and the database. Ask for costs by phase, and ask which items are one-time (the upgrade project) and which recur (hosting, security update retainers, plugin maintenance). Ask what is excluded. The figures in this section come only from supplied facts, so confirm any amount against your written scope.
How long does a Redmine 6 to 7 upgrade take?
Duration depends mostly on plugins, custom code and the number of environments. A simple installation with few plugins and a staging copy moves faster than one with several third-party plugins, custom themes, integrations through the REST API or LDAP, and separate test, staging and production systems. Database size affects migration run time, and the number of change windows available affects the calendar. The core sequence is documented in the upgrade guide: back up the database and files, copy configuration, uploads and plugins, run the database and plugin migrations, clear the cache and restart. Teams usually rehearse that sequence in staging before production. No duration figure is supplied for this topic, so ask for a written schedule with milestones and the assumptions behind it.
What does our team need to provide for a Redmine upgrade?
Inventory, approvals, test users and a change window. Start with an inventory of every plugin, theme, custom patch, integration and scheduled job, along with the current Ruby, database and operating system versions. Confirm backup access and who can restore from it. Business owners should approve the test scope and the cutover decision. Provide test users who can run real workflows, such as creating issues, logging time, editing wiki pages and using the REST API, because technical checks alone miss user-facing breakage. Finally, agree a change window with a clear rollback decision point and a named person who can make that call during the window.
Can an internal team upgrade Redmine 6 to 7 without outside help?
Often yes, if the team has Ruby on Rails operations experience and a small footprint. The upgrade guide describes the steps, and an internal team that already runs Redmine with a staging environment can follow them. The work gets harder when several plugins lack 7.0 support, when there is custom code to adapt, when Sidekiq, a reverse proxy or external authentication is in use, or when the team has no spare time to test. Estimate the effort honestly by listing the plugins and customizations first. A fixed-scope engagement covers planning, the upgrade and testing, and a retainer can cover updates afterward. Confirm the team's capacity against your own environment before deciding.
Does Redmine 6.0 need an intermediate step before 7.0?
Confirm the path for your exact starting version in the upgrade guide and release notes. The supplied facts do not establish a required intermediate release for every 6.0 installation, so do not assume one or skip one without checking. Support status matters for the decision: 6.0.x receives only important security updates, 6.1.x receives bug fixes and security updates, and 7.0.x is the fully supported line. Whether to move to a 6.1.x release first is a planning decision that depends on your plugins, your starting patch level and your test results. Record the path you choose, the versions tested at each step and the rollback point for each step.
What happens to Redmine plugins that do not support 7.0?
They can break at upgrade time, so check each one before cutover. Compare every plugin's declared compatibility with Redmine 7.0 and Rails 8.1 against your inventory. For each plugin that does not support 7.0, decide among four options: upgrade to a vendor release that does, patch it, replace it with a supported alternative, or retire the feature it provided. Plugins that include database changes run through the plugin migration step, so test them in staging with a copy of production data. Keep an untouched copy of every third-party plugin and its configuration. Confirm the status of each plugin with its maintainer, since the supplied facts cover Redmine itself and not individual plugins.
How do sudo mode and removed icon classes affect Redmine users?
Sudo mode can add a confirmation step, and removed icon classes can break custom screens. Sudo mode is on by default in Redmine 7.0, so users may be asked to confirm their identity before sensitive actions. Test which actions prompt for it, how it behaves for users who sign in through LDAP or a reverse proxy, and whether scripts or integrations are affected. Icon classes removed in 7.0 can leave missing icons or broken layouts in themes and plugins that reference them. Audit custom CSS, views and plugin templates, and walk through menus, buttons and forms with test users. Tell users about the sudo prompt before cutover so help requests do not pile up on go-live day.
What does a tested rollback look like for a Redmine 7.0 upgrade?
A rollback is a rehearsed restore, not a guess made during the window. Keep a verified backup of the database and uploaded files taken immediately before cutover, along with the configuration and the plugin set that matched the old version. Rehearse restoring that backup into staging and time it, because a database that has been migrated generally cannot be expected to run the old code without a restore. Write down the rollback trigger, the person who makes the call, and the steps to repoint users. Confirm the restore procedure against the upgrade guide and your own backup tooling before the change window.
How DeployOpen scopes, delivers and supports a Redmine 7.0 upgrade
DeployOpen plans and implements Redmine 6 to 7 upgrades inside your own infrastructure, with the written scope agreed before work starts. Engagements are fixed-scope, so the Rails 8 move, Ruby checks, plugin and theme fixes, and rollback testing are defined in advance. Ongoing support is available as a retainer.
How we scope
- The written scope lists each Redmine 6.0 or 6.1 instance, its database, and its operating system.
- Plugin and theme inventory marks which extensions need updates for removed icon classes in 7.0.
- Ruby version check confirms the runtime is 3.2, 3.3, 3.4 or 4.0 before any work begins.
How we build
- Staging copy of the production instance, built from a fresh backup of database and uploaded files.
- Upgrade runs db:migrate and redmine:plugins:migrate, then cache is cleared and the service restarts.
- Sudo mode, now on by default in 7.0, is tested with administrator and user login flows.
How we hand over
- Rollback procedure is rehearsed on staging, with restore timings recorded in the runbook.
- Written runbook covers the upgrade steps, plugin changes, configuration diffs and post-upgrade checks.
- Your team receives a walkthrough of the cutover and the rollback steps before go-live.
How we support
- Post-upgrade monitoring checks logs and plugin behavior after cutover, as agreed in the scope.
- Ongoing support under a retainer can cover Redmine 7.0.x patching, upgrades and testing.
- Plugins that lack a 7.0-compatible release are listed with replacement or patch options for your decision.
