Redmine upgrade services for installs older than the 7.0 line
An upgrade from an older Redmine install to the 7.0 line is a planned project that covers application code, the Ruby and Rails runtime, plugins and the database together, and most teams weigh doing it in-house against a fixed-scope engagement with a partner. The right answer depends on how far the install has drifted, how many plugins it carries, and how much time your administrators can spare without putting the tracker out of service. The trigger is usually one of four things. The branch you run may have reached end of support, which the Redmine download page places at 5.1.x and older, with 6.0.x now limited to important security updates. A security finding may require a fix that only ships on a supported line. A plugin may have stopped working after a Redmine or Rails change, leaving a workflow or custom field broken. Or the operating system, database server or Ruby version underneath the install may be changing for reasons unrelated to Redmine. Any one of these can start the project, and the first step is to write down which trigger applies to you.
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. Confirm your target Ruby version against the installation guide before you choose a host image, because an older Ruby on a long-lived server is often the first blocker. Check the database as well. Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, SQL Server 2012 or higher, and SQLite, which the installation guide says is not suited to multi-user production use. If your install runs on a database version outside those ranges, the database upgrade may need to happen before or alongside the Redmine upgrade. Plugins deserve their own inventory. For each plugin, record its source, the version installed, whether its maintainer has published a release for the 7.0 line, and whether you have made local changes to it. Plugins that were forked or patched in place are the most common source of delay, because the patches must be reapplied or rewritten. Ask your team to confirm which plugins are business-critical, since those should be tested first in any staging copy.
The upgrade procedure in the Redmine upgrade guide follows a fixed sequence: back up the database and uploaded files, copy configuration, uploads and third-party plugins to the new installation, run the database migrations, run the plugin migrations, clear the cache and restart. The sequence is simple on paper. The work lies in the checks between steps, such as confirming that attachments resolve, that custom fields keep their values, and that workflows and roles still grant what they did before. Plan a staging environment built from a recent backup so these checks happen before any production cutover. Backups need particular care. Take a database dump and a copy of the files directory, and confirm you can restore both to a separate host before you begin. Record the current Redmine version, Ruby version and plugin list so that a rollback target exists. Decide in advance who has authority to roll back and what conditions trigger it.
Ongoing support after the upgrade is a separate decision from the upgrade itself. Ask any partner to state in writing which Redmine branch will be maintained, how plugin compatibility will be rechecked when a new release arrives, who applies security updates, and how long an upgrade window is expected to last. Ask also what happens when a plugin is abandoned. DeployOpen plans, implements, upgrades, documents and supports Redmine inside your own cloud accounts, data centers or air-gapped networks, and ongoing support, upgrades and continuous testing can be arranged as retainers. A quote follows from a written scope, so list your plugins, database, hosting model and required uptime before you request one.
What a Redmine upgrade and support engagement includes
A Redmine upgrade moves a live tracker across Ruby, Rails, database and plugin changes without losing projects or history. The work is delivered in packages that are agreed in writing before work starts, so each deliverable and each client responsibility is clear. An optional retainer then keeps the upgraded line supported after cutover.
Version, Ruby and plugin inventory
The inventory records the installed Redmine version, Ruby and Rails versions, database engine and version, every installed plugin with its version, and the configuration files and upload directories the upgrade must carry forward. It also identifies the target line, such as 7.0.x, and the Ruby versions that line supports, so gaps surface before any change is made. Ask for the inventory as a written document you can review before the rehearsal starts.
Upgrade rehearsal on a copy
The rehearsal runs the full upgrade against a copy of the production database, uploaded files and configuration, on infrastructure that does not serve users. It exposes migration errors, slow steps and plugin breakage while the live system stays untouched. Record each step and any manual fix, because the same sequence becomes the production runbook. Confirm who holds the copy and how it is protected.
Plugin compatibility checks and fixes
Each third-party plugin is checked against the target Redmine version and its Rails release. A plugin that fails is updated to a compatible release, patched where the source is available and the license allows it, or removed with the affected features documented. Abandoned plugins are a common cause of blocked upgrades, so confirm each plugin's maintenance status before scoping. The written scope should list the covered plugins and who decides on removals.
Production cutover procedure
Cutover follows the upgrade procedure in order: back up the database and uploaded files, copy configuration, uploads and third-party plugins to the upgraded installation, run db:migrate and redmine:plugins:migrate, clear the cache, and restart. The maintenance window and rollback point are agreed before the change begins. Keep the pre-upgrade backup until verification passes, since a failed migration is difficult to reverse without it. The scope should name the approver and the on-call contacts for the window.
Post-upgrade verification and handover
Verification checks that projects, issues, users, roles, attachments, custom fields, email notifications, LDAP logins and repository links behave as they did before the upgrade, using the checklist built from the inventory. The handover package then records the final versions, the plugin list, configuration changes, backup and restore steps and any open issues. Ask for the handover documents to be named in the written scope and delivered to the people who will run the system.
Optional support retainer
The optional retainer covers monitoring of the supported Redmine branch, security and bug fix updates for the line in use, plugin updates and recurring upgrades as new releases ship. Redmine 7.0.x receives new features, bug fixes and security updates, while 6.1.x and 6.0.x receive narrower updates, so the retainer scope should state which line is covered. Confirm response expectations, which fees recur and which are per engagement, and how out-of-scope requests are quoted.
What makes a Redmine upgrade take longer or cost more
This table compares the factors that most change the effort of moving a Redmine install to the 7.0 line, with why each one adds work and how to keep it manageable. Read each row as a question to answer about your current installation before asking for a quote, since the largest drivers are often plugin count and the number of hops required.
| Driver | Why it adds effort | How to reduce it |
|---|---|---|
| Number of version hops to 7.0 | Each intermediate release can carry its own migrations, plugin API changes and Rails or Ruby requirements, so an install several lines behind is tested in stages. Redmine 5.1.x and older are unsupported, so those installs carry the most change. | Confirm your current version first, then agree the upgrade path in writing. Clearing unused data and settings before the first hop limits what each step has to migrate. |
| Count and age of third-party plugins | Each plugin must be checked for compatibility with the target release and Rails version, and some may need replacing or patching. Older plugins with no active maintainer are the most common blockers. | Remove plugins nobody uses, inventory the rest with their versions and maintainers, and decide keep, replace or retire for each before the upgrade starts. |
| Custom fields, trackers and workflows | Custom fields, workflow rules and role permissions are stored in the database and must migrate cleanly. Heavy custom configuration makes testing longer because each project's behavior needs checking. | Export a list of trackers, custom fields and workflows, delete obsolete ones, and freeze configuration changes during the upgrade window. |
| Ruby and Rails runtime changes | Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0 but not JRuby. Servers on older Ruby versions or custom application servers need runtime work before the application code can even start. | Confirm the Ruby version on each server and plan runtime upgrades in the same test cycle. Confirm the chosen Ruby version against the installation guide. |
| Database engine and version | Migrations run differently across PostgreSQL, MySQL and SQL Server, and MySQL requires READ COMMITTED isolation. SQLite is not suited to multi-user production, so a move to a production database may be needed alongside the upgrade. | Record the engine and version, confirm it is in the supported list for 7.0, and rehearse db:migrate on a copy of production data. |
| Attachment volume | Large attachment stores lengthen backup, copy and migration steps, and file-level checks take longer to validate after the move. | Measure total attachment size and file count, clean up obsolete uploads where policy allows, and plan the copy window around it. |
| LDAP or SSO integration | LDAP settings and user mappings must be re-verified after the upgrade. Any SSO that relies on a plugin or reverse proxy adds a second component to test, since SAML and OpenID Connect are not part of core Redmine. | List each authentication path, document the settings, and test a sign-in with a sample of each user type on the upgraded staging system. |
| Number of environments | Each environment (test, staging, production) needs the same upgrade steps and checks, and drift between them is a common reason for failed cutovers. Fewer environments usually mean less rehearsal. | Keep staging close to production in version, plugins and data. Agree which environment is the rehearsal target and who signs off each stage. |
| Existing backups and tested restores | Without a recent database and file backup, the upgrade needs a backup project first. Backups that have never been restored are a risk because the rollback plan depends on them. | Confirm current database and upload backups, run a restore test on a separate host, and write the rollback steps before the upgrade date is set. |
How a Redmine upgrade runs from inventory to handover
The sequence moves an older Redmine install onto a supported line through documented checks, a rehearsal on current data, and a controlled cutover, ending with a handover the operating team can run without the implementation team. Each phase produces a written output that the next phase depends on.
Inventory the current installation and its plugins
The team records the running Redmine version, Ruby and Rails versions, database engine and version, web and application server layout, attachment storage location, configuration files, and every installed plugin with its version and source. Optional components such as ImageMagick, Ghostscript, Pandoc and Sidekiq are noted as present or absent. The output is a written inventory that the client confirms against its own environment, because server access and change records are the basis for every later decision. The phase is complete when the client has reviewed and signed off the inventory.
Design the target environment and upgrade path
Using the inventory, the team selects the target Redmine line, which for current installs means the fully supported 7.0 branch, and confirms that the planned Ruby version is one that Redmine 7.0 supports. It checks the database engine against the supported list, decides whether SQLite is in use and should be replaced, and lists which plugins must be updated, replaced or retired. The output is a target design document with the new host layout, version pins, and a list of open compatibility questions for each plugin, which the client should confirm with plugin authors or the plugin repository.
Rehearse the upgrade on a recent copy of production data
The team builds a staging instance and restores a recent copy of both the production database and the attachments directory, so that the rehearsal reflects real records, custom fields and uploaded files. The upgrade steps from the Redmine upgrade guide are run against this copy: configuration and uploads are placed in the new installation, third-party plugins are copied in, the database migration and plugin migration tasks are run, the cache is cleared and the application is restarted. Each error, warning and manual fix is logged. The rehearsal is complete when the upgraded copy passes the smoke checks agreed in the design phase, and the rehearsal log is handed to the client.
Remediate plugins and verify behavior
Plugins that failed in the rehearsal are updated to compatible versions, patched, replaced with a maintained alternative, or removed with the client's approval. The team then tests the workflows the business depends on, including issue creation by email if used, role and permission checks, LDAP logins if configured, REST API calls if integrations rely on them, and any SCM links. The output is a remediation register that lists each plugin, its final state, the test that covered it, and any residual risk the client accepts in writing.
Execute the cutover following the upgrade guide
During an approved change window, the team takes a fresh backup of the production database and uploaded files, puts the application into the agreed maintenance state, and repeats the rehearsed steps from the upgrade guide: copying configuration, uploads and remediated plugins, running the database and plugin migrations, clearing the cache and restarting. The same backup used for the rehearsal logic is kept as the rollback point. The output is a cutover record with timestamps, the backup identifiers and the post-restart checks, which must match the rehearsal results before the change is closed.
Stabilize operations and hand over
After cutover, the team watches logs, background job queues where Sidekiq is used, email delivery and authentication for an agreed period, then fixes any issues found in production. It confirms that backups run and that a restore has been tested. The handover package contains the final inventory, configuration notes, plugin register, runbook for the upgrade and rollback steps, and a list of items that remain with the client's administrators. Handover is complete when the client's operators have run the routine tasks themselves or walked through them with the team, and the open items are assigned.
Which Redmine support line your install is on and what that means
Your first task is to identify which Redmine support line your installation belongs to, because that determines what the project will still fix for you. Redmine 7.0.x is the fully supported line and receives new features, bug fixes and security updates. Redmine 6.1.x receives bug fixes and security updates only, so it will not gain new functionality. Redmine 6.0.x receives only important security updates. Redmine 5.1.x and older are unsupported, which means an install on those branches should be treated as a priority for upgrade planning rather than routine maintenance. Check your running version directly in the application and in the server's deployed release, not only in your change records, since installs are often patched in place and the documented version can drift.
The reference points to check against are the latest stable releases listed on the Redmine download page at the time of writing: 7.0.2 and 6.1.5, both dated October 1, 2026, and 6.0.11, dated August 26, 2026. Use these as the comparison points for how far behind your install is, not as a guarantee of what is current on the day you read this. Before you plan an upgrade or sign a support scope, open the Redmine download page yourself and confirm which releases are listed, their dates and whether a newer patch has appeared. Ask any partner quoting upgrade work to state which release they will target and to show the check they ran against the download page.
Moving from 6.0 or 6.1 to 7.0 is not only a Redmine version 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 server runs an older Ruby than the 7.0 baseline, the Ruby runtime must be upgraded as part of the work, and that change can affect every gem and plugin the install loads. Record the current Ruby, Rails and gem versions, along with the operating system and web server, before you choose a target. A Ruby upgrade on the application host is a separate risk from the Redmine code change, so it should appear as its own line in the plan, with its own rollback path.
Treat the support line as an input to three decisions. First, decide whether a patch within your current line is enough or whether you need to move to 7.0 to keep receiving fixes beyond security. Second, decide whether your plugins have 7.0-compatible releases, since an unmaintained plugin can block the move even when Redmine itself is ready. Third, set a review date tied to the next published release so the install does not drift back into an unsupported state. Ask your delivery partner to confirm, in writing, the support line you are starting from, the target release and the Ruby and Rails versions that release requires in your environment.
Which upgrade tasks your team can keep and which to outsource
This table splits Redmine upgrade work into tasks that usually stay with your own staff and tasks that partners often take on. Read each row for the skills the task needs, then compare those skills with what your team already has. Tasks that depend on business decisions or production access tend to stay in-house, while technical analysis and rehearsal work are common outsourcing candidates.
| Upgrade task | Usually kept in-house or outsourced | Skills needed | Confirm before deciding |
|---|---|---|---|
| Business sign-off on the target version | Kept in-house | Project ownership, change approval, knowledge of which projects depend on Redmine | Who approves the 7.0 line move and the cutover window |
| Test case ownership | Kept in-house | Knowledge of daily workflows, trackers, custom fields and reports | Which teams write and maintain acceptance tests |
| User communication | Kept in-house | Change management, internal messaging, support desk coordination | Notice periods and downtime messaging owned by your organization |
| Access to the production environment | Kept in-house | Linux administration, access control, change records | Who holds production credentials and approves deployments |
| Version and runtime analysis | Often outsourced | Ruby and Rails operations, reading Redmine installation requirements for Rails 8.1 and supported Ruby versions | Current Ruby, Rails and database versions on each server |
| Plugin compatibility work | Often outsourced | Plugin development, reading plugin source, Rails upgrade experience | Full plugin inventory and whether each plugin has a maintained release for the target version |
| Database migration rehearsal | Often outsourced | Database administration for PostgreSQL, MySQL or SQL Server, running db:migrate on a copy | Database engine, version and transaction isolation settings for MySQL |
| Cutover runbook | Shared, often outsourced | Linux administration, Redmine upgrade procedure, rollback planning | Maintenance window length and rollback tolerance set by your team |
| Post-upgrade security review | Often outsourced | Web application security testing, configuration review, plugin review | Whether security review evidence is needed for an audit or internal policy |
What goes wrong in Redmine upgrades and how to prevent it
Most failed Redmine upgrades trace back to a short list of causes: plugins, runtimes, databases, custom code, backups and the components that were never moved to the new host. Each card below names one of these failure modes and the check that prevents it before the cutover window opens.
Plugin with no target release
A plugin that has no release for the Redmine version you are moving to will break the upgrade or the pages it touches. Before scheduling anything, list every installed plugin, its current version and whether its maintainer has published a build for the target line. Where no build exists, decide whether to replace the plugin, rebuild it, or drop the feature. Make that decision in the scope document, not during the maintenance window.
Skipped plugin migrations
The upgrade procedure runs database migrations for the core application and then for plugins. Teams that run only the core step leave plugin tables and columns out of date, and the errors often appear hours later when a user opens a plugin screen. Include the plugin migration step in the runbook, record its output, and check that each plugin page loads in staging before production is touched.
Unsupported Ruby version
Redmine 7.0 supports Ruby 3.2, 3.3, 3.4 and 4.0. A host running an older or unlisted Ruby release will fail at bundle install or at boot, and the error messages do not always point to the runtime. Confirm the Ruby version on the target host before the upgrade, pin it in the service definition, and rebuild gems against that exact version rather than copying the old vendor directory.
JRuby runtime in use
Redmine does not support JRuby. Some older deployments run under JRuby for reasons tied to a former application server or an internal standard, and the new host is often built from the same template. Check the runtime on the existing server and the new build before planning. If JRuby is in use, the runtime change is a separate project that needs its own testing, not a line item in the upgrade.
Custom code relying on removed behavior
Local patches, theme overrides, custom hooks and scripts written against an older Rails or Redmine API can stop working after the upgrade without raising an error at startup. Inventory every local modification, mark which ones reach core code, and rerun each one against the target version in a staging copy. Custom code that depends on internal methods is the most likely to need rework.
Missing or untested backups
The upgrade guide calls for backing up the database and the uploaded files before any change. A backup that has never been restored is not a tested backup. Take both, record checksums, restore them to a separate host, and confirm that issues, attachments and users open correctly. Keep the rollback path documented so that the restore is a known procedure during the window.
MySQL isolation level not set
Redmine requires MySQL transaction isolation set to READ COMMITTED on the MySQL 8.0 to 8.4 releases it supports. Hosts that keep the server default may run without an error during testing and then show inconsistent counters, duplicate numbering or odd issue state under concurrent use. Confirm the isolation setting on the database server and in the client configuration before the upgrade, and repeat the check on the new database host.
SQLite in multi-user production
The installation guide states that SQLite is not suited to multi-user production use. Some installations begin on SQLite for a pilot and keep it as users grow. Before the upgrade, confirm which database engine production uses. If it is SQLite, plan the move to PostgreSQL, MySQL or SQL Server as a separate migration with its own data validation, not as part of the version change.
Optional components left behind
Sidekiq for background jobs, ImageMagick, Ghostscript and Pandoc are optional, but features that depend on them stop working quietly when they are missing on the new host. Background mail, thumbnails and document conversion are typical examples. List which components the current server runs, install them on the new host, and test the features that use them, including queued jobs and attachment previews.
How the upgrade changes for old, plugin-heavy or air-gapped installs
An install several major versions behind usually carries an old Ruby, older gems and schema changes from many releases. Redmine 5.1.x and older are unsupported, so these installs sit outside the supported line today. Planning starts with an inventory of the current Redmine, Ruby and database versions, then a check of the upgrade path in the Redmine upgrade guide before any target is chosen.
- Ruby first: Redmine 7.0 runs on Ruby 3.2, 3.3, 3.4 or 4.0 and does not support JRuby. An older Ruby must be replaced before the application upgrade, which can also mean new operating system packages.
- Rails baseline: Redmine 7.0 runs on Rails 8.1. Gems and plugins that pin older Rails versions need a compatibility check before testing begins.
- Intermediate releases: Confirm whether an intermediate release is required. Rehearse the full migration chain on a copy of production data, not only on a fresh install.
- Migration runtime: Schema changes across many releases take longer and can fail on old records. Time the dry run and log every error so the window is based on evidence.
Confirm with the environment owner the exact current version, the Ruby and database versions, and whether the change window covers the longest rehearsed run.
Plugins are the most common cause of upgrade delay. Each one has its own release history, and a plugin written for an older Rails version may load but fail in views, hooks or background jobs. The plan should treat the plugin list as a dependency inventory with an owner for each entry.
- Compatibility matrix: Record each plugin's source, installed version, the Redmine versions it declares support for, and whether its maintainer still publishes releases.
- Core overrides: Changes made to core files or themes can be lost during an upgrade. Review each override and re-apply it, or move it into a plugin.
- Plugin migrations: The upgrade runs the plugin migration task after the core database migration, so plugin schema changes must succeed inside the same window.
- Retire or replace: Some plugins duplicate features now in core or can be dropped. Make those decisions before testing, not during cutover.
Confirm with the application owners which plugins are business-critical, who will test each one, and who accepts the risk of dropping or forking a plugin that has no maintainer.
Redmine runs on PostgreSQL, MySQL, SQL Server and SQLite, but the engine sets how much configuration work the upgrade needs. A change of engine during the upgrade is a separate migration project with its own rehearsal and sign-off. The version and settings of the current engine should be checked against the supported list before any change is made.
- MySQL isolation: Redmine supports MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED. Check the server and session settings before running migrations.
- SQL Server version: Redmine supports SQL Server 2012 or higher. Confirm the server version and the database driver on every application server.
- SQLite in production: The installation guide says SQLite is not suited to multi-user production use. If the current install relies on it, plan a move to a supported server engine as part of the upgrade.
- Backup and restore: Confirm the dump and restore procedure for the chosen engine, and test a restore into a separate instance before the upgrade starts.
Confirm with the database administrator the engine version, the isolation setting, the character set and the backup tooling, and who signs off the restore test.
Login changes affect every user, so this tab concerns authentication testing more than code. Redmine authenticates against LDAP directories natively. Single sign-on through SAML or OpenID Connect is not part of core Redmine and depends on a plugin or an authenticating reverse proxy, so those components join the compatibility review.
- LDAP settings: After the upgrade, confirm the connection, bind account, search base and attribute mapping. Test with one user who already exists in Redmine and one who logs in for the first time.
- Reverse proxy identity: If the proxy passes the user identity to Redmine, test header trust, logout and session expiry through the same proxy path used in production.
- SSO plugins: Check each SSO plugin's declared Redmine version before scheduling. A plugin that works on the current release may not work on 7.0.
- API authentication: If the REST API is enabled, confirm that the authentication method in use still works, since API key and HTTP basic authentication are tested separately.
Confirm with the identity team the directory details, the certificate or proxy configuration, and which accounts must keep working during cutover.
In an air-gapped network, the upgrade cannot fetch Ruby packages, gems, database drivers or plugin sources at run time. Everything the upgrade needs must be staged inside the network before the change window. That staging is a planned deliverable with its own review, approval and record of what was loaded.
- Ruby and gem bundle: Stage the Ruby release, the gems for Redmine 7.0, the gems for every plugin and the operating system packages, each verified against the versions approved for the change.
- Plugin sources: Plugins installed from a source repository or archive need their source copied in. Record the exact commit or release used so it can be reproduced later.
- Optional components: If ImageMagick, Ghostscript, Pandoc or Sidekiq are in use, stage them too. The installation guide lists them as optional, but any feature that depends on them needs them present.
- Matching documentation: Keep copies of the upgrade and installation guides that match the target release, since the live website may not be reachable during the change.
Confirm with the network and change owners how packages cross the boundary, who approves each staged artifact, and whether the test environment is built from the same bundle as production.
What you need to provide before a Redmine upgrade starts
Before an upgrade starts, the client needs to supply a short list of access, inventories and decisions. Without them, the upgrade team spends its first days discovering what the system does rather than testing whether it still works. The most important inputs are access to the current Redmine server and its database, a copy of the configuration files and the uploads directory, and an up-to-date inventory of installed plugins with the source each one came from. Plugins are the usual source of delay, so the inventory should record the plugin name, the installed version, where it was obtained (the Redmine plugin directory, a vendor, an internal team or a fork) and whether anyone still maintains it.
Access should be checked early, not on the day of the change. Confirm that the upgrade team can reach the server over the agreed channel, that a database account with dump rights exists, and that the uploads directory can be copied without breaking attachment paths. Ask the current administrator to confirm the Redmine version, Ruby version and database type in use, since these determine which upgrade path applies. The Redmine upgrade guide asks for a database backup and a copy of uploaded files before any migration runs, so both should be confirmed as recent and restorable, not just present.
Test accounts are the client's responsibility and are often underestimated. Provide one test account for each role that matters in daily work, including administrators, project managers, developers, reporters and any role used for read-only access or API integrations. Each account should have the same project memberships and permissions as a real user. A named business owner must then sign off test results for each workflow, such as creating and closing issues, time entry, reporting and email notifications. That person should have the authority to accept or reject the upgrade, not just to attend meetings.
Change windows and the rollback decision must be agreed in writing. Confirm the dates and hours when the system can be unavailable, who can approve an extension, and who communicates with users. Decide in advance what rollback means for this installation: restoring the pre-upgrade backup, reverting to the previous application directory, or accepting a forward fix. The rollback trigger, meaning the specific failure that causes it, should be named before the window opens. Finally, decide three things before the work begins: the target Redmine version, whether the current hosting stays in place or moves, and who will own support after handover. A partner can plan the work against these answers, but cannot make them on the client's behalf.
Redmine upgrade questions buyers ask before hiring help
What drives the cost of a Redmine upgrade?
Scope is the main driver: the number of installed plugins, custom fields, workflows, the database engine, attachment volume, and how far the current install is from the 7.0.x line. Redmine has no license fee, so the quote covers people and hosting. One-time costs include the assessment, the upgrade in a staging copy, plugin work, testing and cutover. Recurring costs include hosting, backups and any support retainer, which is priced separately. To request a fixed-scope quote, send your current Redmine and Ruby versions, database type, a list of plugins with versions, user count, attachment size, and whether you run background jobs. Ask for deliverables, acceptance tests, exclusions and the rollback plan in writing before work starts. DeployOpen does not publish prices, and a quote follows from the written scope.
How long does a Redmine upgrade take?
The timeline depends on how far the install is behind, how many plugins need changes, and how much testing the business requires. Moving from an unsupported line usually involves more steps than a minor update, because the Ruby and Rails versions may change along with the application. Each database migration and plugin migration step has to run cleanly on a copy of production data before it is scheduled for production. Test periods depend on how many people must sign off on workflows, permissions and reports. Ask for the schedule in the written scope along with its assumptions: who approves each phase, which test cases count as acceptance, and what happens if a plugin has no release for the target version. DeployOpen does not publish fixed durations, so any estimate should come from your own inventory.
Can our internal administrator upgrade Redmine alone?
An experienced Redmine administrator can perform an upgrade alone, but the work involves more than running commands. The official procedure covers backing up the database and uploaded files, copying configuration, uploads and third-party plugins to the new installation, running the database and plugin migrations, clearing the cache and restarting. The harder parts are confirming Ruby and Rails support, checking each plugin, and testing workflows and permissions afterward. One administrator also becomes a single point of failure during cutover. Consider whether a second person can review the plan, test the restore and cover the change window. DeployOpen can carry out the full upgrade, or review your plan as a separately scoped engagement.
What does a Redmine upgrade need from our team?
Your team provides access, decisions and people who know the business. Expect to supply administrative access to the current server, database and file storage, along with a current inventory of plugins, themes and custom code. Someone must identify the projects, roles, trackers and workflows that matter most, and name a person to approve test results. Confirm maintenance windows, who receives notice, and which users will test. If you use LDAP, single sign-on or the REST API, list those integrations so they can be retested after the upgrade. Your team also owns the go-live decision. Ask the partner to state each dependency in the scope, so you can plan staff time before work begins.
How is plugin compatibility checked before a Redmine upgrade?
Compatibility is checked against the target Redmine 7.0 line and the Ruby and Rails versions it requires, which means checking more than the plugin name. Start by listing every installed plugin with its version and source, then confirm whether the author publishes a release for the target version. Plugins without a release, unmaintained plugins and custom code each need a review. Run the upgrade on a copy of production data, execute the plugin migrations, and test the features each plugin provides, such as custom workflows, reports or themes. Record the results in an inventory so the decision to keep, replace or remove each plugin is documented. Ask the partner to deliver this inventory as part of the scope.
Can a Redmine upgrade be rolled back?
Yes, but only if the rollback plan is prepared before cutover. The safe approach is to keep the original server and a verified database and file backup untouched until acceptance is complete, so you can return to the previous installation. Test the restore procedure on a copy, because a backup that has never been restored is unproven. Database migrations change the schema, so reverting normally means restoring the pre-upgrade database. Ask for the rollback steps, the decision point, the time each step takes on your hardware, and who authorizes the rollback, all written into the scope. Keeping the old server available for an agreed period is the main control that makes a return possible.
What does ongoing Redmine support cover after go-live?
Ongoing support covers the work you agree in a retainer or separate scope, such as monitoring, applying patches within the supported line, plugin updates, backup verification, user administration help and incident response. Redmine's support status shapes this work: 7.0.x receives new features, bug fixes and security updates, 6.1.x receives only bug fixes and security updates, and 6.0.x receives only important security updates. Older lines, including 5.1.x and earlier, are unsupported. Plan the next upgrade before a line leaves support. Ask whether the retainer includes testing each new release before production, how incidents are prioritized, and what is excluded, such as custom development. DeployOpen offers ongoing support and upgrades as retainers, and the terms come from the written agreement.
Which Redmine and Ruby versions should we upgrade to?
Target the 7.0.x line, the fully supported branch, and confirm the latest 7.0 patch release when you plan. Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0. JRuby is not supported. Check your current Ruby version, because the jump may require a Ruby upgrade first. Confirm that your database is supported: PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, SQL Server 2012 or higher, or SQLite. The installation guide says SQLite is not suited to multi-user production use, so a database move may belong in the same project. Your partner should check these requirements against the official release notes on the day the upgrade is scheduled.
How DeployOpen works on this
DeployOpen plans Redmine upgrades as written, fixed-scope engagements inside your own infrastructure, starting from your current version, plugins and database. Each upgrade is built, tested and documented against an agreed plan, then handed to your team with ongoing support available as a retainer.
How we scope
- Inventory your current Redmine version, Ruby and Rails versions, database engine and hosting layout before quoting any work.
- List every installed plugin and check its compatibility with the target Redmine 7.0.x release line.
- Agree in writing which environments, data sets and rollback points the upgrade covers, and what it excludes.
How we build
- Stand up a staging copy of production and run the upgrade there first, following the documented Redmine upgrade procedure.
- Back up the database and uploaded files, copy configuration, uploads and third-party plugins, then run the database and plugin migrations.
- Test core workflows, custom fields, workflows, roles, email handling and any REST API integrations before cutover.
How we hand over
- Document the final versions, configuration changes, plugin versions and the migration steps actually performed.
- Walk your administrators through the rollback plan, cache clearing and restart sequence used during cutover.
- Deliver a written runbook your team can repeat for the next Redmine release on the supported branch.
How we support
- Offer ongoing support as a retainer covering monitoring, patch review and planned upgrades to later supported releases.
- Review plugin compatibility each time Redmine, Ruby or Rails changes, and flag plugins that need replacing or maintenance.
- Confirm with your team which support hours, response expectations and backup restore tests apply before signing a retainer.
