Redmine implementation plan and cost

Overview

A Redmine implementation puts the application on infrastructure your organization controls, then shapes it around how your teams actually track work. The core deliverables are an installed and supported Redmine instance, projects and trackers that match your delivery model, workflows and roles that reflect who may change what, a short list of plugins you have reviewed, a working authentication setup, imported historical data, and a handover your administrators can operate without the implementer. Redmine is licensed under the GNU General Public License v2 and has no paid edition, so the license line on the budget is zero. Every other cost sits in people, hosting, database operations, plugin upkeep and upgrades.

Most organizations start this work for one of three reasons: spreadsheets have stopped scaling for issue and task tracking, an aging tracker is out of vendor support or too costly to change, or several project teams need one shared record instead of separate tools. A fourth common trigger is leaving a hosted tool, where data residency, pricing changes or feature limits make self-hosting attractive. Each trigger changes the scope. A spreadsheet replacement mostly needs trackers and roles designed from scratch. An aging tracker migration adds data mapping work. A consolidation adds decisions about which teams keep their own projects and which share a hierarchy.

Teams with a capable Linux administrator, someone who can own Ruby and database upgrades, and time to learn Redmine's permission model often build the first version in-house. Teams without those skills, or with a tight go-live date, usually bring in a partner for the setup and the handover, then run upgrades themselves or under a retainer. Either path should begin with a written list of decisions: hosting and database choice, authentication source, which plugins are required, and who approves workflow changes after go-live.

Ask before you commit: confirm which Redmine line you will run. The download page lists 7.0.x as the fully supported line, so a new deployment should target it unless you have a specific reason not to. Confirm your Ruby version against the installation guide, since 7.0 supports Ruby 3.2 through 4.0 and not JRuby. Confirm that your planned database is one the installation guide supports, and note that its SQLite option is not suited to multi-user production use.

What the implementation includes

Each card below is a work package in a Redmine rollout. The deliverables are agreed in writing before work starts, and the scope you sign off is what drives the quote.

Environment build

Installation of the Redmine application server, the chosen database (PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, or SQL Server 2012 or higher), and persistent file storage for attachments. Optional components such as Sidekiq for background jobs, ImageMagick, Ghostscript and Pandoc are included only if you request them. Confirm which Ruby version your chosen Redmine line supports before agreeing the stack.

Configuration baseline

A documented starting point for projects, trackers, custom fields, workflows and role-based access. This is where most scope disputes start, so the agreed list should name each tracker, each workflow state transition and each role with its permissions. Changes requested after sign-off are priced as change requests.

Authentication setup

Native LDAP authentication, including how users are created on first login and which directory attributes map to Redmine fields. Single sign-on through SAML or OpenID Connect is not part of core Redmine, so it is scoped separately as plugin or authenticating reverse proxy work with its own review of plugin compatibility.

Email settings for issues and notifications

Configuration of outbound notification email and inbound email-based issue creation, including the mailbox, the handling rules and the sender addresses. Testing with real mail flows across your mail platform is part of the deliverable, because mail relay policies often decide whether this works on the first attempt.

User training and documentation

Role-based training sessions and written guidance for end users, project managers and administrators, built around the workflows and roles agreed in the baseline. Ask for the number of sessions, their length and the audience for each in the written scope.

Written runbook

An operations document covering installation layout, backup and restore steps, the upgrade procedure, plugin inventory and who to contact for each task. Its completeness determines how much of the ongoing administrator effort stays in-house after handover.

What drives cost and duration

This table lists the factors that change the effort and recurring cost of a Redmine rollout, why each one matters, and how to keep it under control, so you can read a quote against the same set of drivers.

Driver	Why it matters	How to keep it down
Number of projects, users and groups	Each additional project adds permission design, membership and onboarding work, and larger user counts raise hosting capacity and support load.	Start with the projects that must move first, define a standard project template, and ask the quote to state the user and project counts it assumes.
Number and complexity of trackers and workflows	Every tracker needs its own status transitions and role permissions, and cross-tracker rules multiply testing effort during build and each upgrade.	Limit trackers to real work types, use one shared workflow where possible, and document each transition before the build starts.
Custom fields and role matrix	Custom fields touch forms, filters, reports and the API, and a detailed role matrix requires review with each team lead and assessor sign-off on access.	Reuse existing fields, cap custom fields per tracker, and agree the role matrix in a single workshop with written approval.
Plugin count and upgrade compatibility	Each plugin is a separate dependency that must be selected, tested, and checked again at every Redmine upgrade, and some plugins lag behind new Rails or Ruby releases.	Keep plugins to a short approved list, confirm the Redmine 7.0 compatibility of each one, and budget maintenance as a recurring line item.
Database choice	SQLite is not suited to multi-user production use, so the usual paths are PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, or SQL Server 2012 or higher, each with different admin and backup skills.	Pick the engine your team already operates, confirm the supported version with the Redmine installation guide, and ask the quote to name the database platform.
LDAP or SSO requirements	Native LDAP is part of Redmine, but SAML or OpenID Connect depends on plugins or a reverse proxy, which adds design, testing and ongoing maintenance.	Decide the identity source before the build, use native LDAP where it meets the need, and separate SSO work into its own scoped line.
Historical data volume and source system	Trac and Mantis built-in importers no longer work, and third-party scripts for Jira or Bugzilla are untested, so migration is often the largest one-time item.	Archive closed projects that do not need history, limit the import to agreed date ranges, and ask the quote to split migration from the core build.
Number of environments	Test, staging and production each need their own install, data copy, plugin set and deployment steps, which multiplies setup and upgrade rehearsal time.	Keep a single staging environment that mirrors production, and agree which environments the quote includes and who maintains each.
Availability and backup targets	Higher uptime needs multiple application servers, a replicated database, shared attachment storage and tested restores, each of which adds hosting and operations cost.	Define the recovery needs per data type, start with a single-node setup where the business risk allows, and ask for the backup and restore test to be priced separately.
Compliance evidence needs	Assessors may ask for access reviews, change records, backup restore evidence and documented upgrade decisions, and each artifact must be produced and kept.	List the evidence required before scoping, reuse the existing change process, and confirm with your assessor which artifacts they expect.
One-time versus recurring cost split	One-time work covers build, import, training and plugin selection, while recurring work covers hosting, plugin maintenance, upgrades and administrator time, and the two are often blended in a single figure.	Ask every quote to show one-time and recurring totals separately, with the assumptions behind each line, so you can compare options fairly.

Project phases and outputs

The sequence moves from agreed requirements to a documented, tested and handed-over Redmine installation, with each phase closing on a written output.

Run discovery and requirements
The team inventories projects and trackers, builds a role matrix, maps current workflows and records the authentication decision, such as local accounts, LDAP or a reverse proxy. The output is a signed requirements document that lists every project, tracker, role and workflow state in scope.
Decide architecture and hosting
The team selects the database engine from the supported options, such as PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, or SQL Server, and confirms the Ruby version for the chosen Redmine line. It also settles the reverse proxy, file storage for attachments and backup targets. The output is an architecture decision record that the client's infrastructure owner approves.
Build and configure in non-production
Engineers install the chosen Redmine release in a non-production environment, configure trackers, custom fields, roles and workflows from the requirements document, and enable the REST API only if an integration needs it. The output is a configured staging instance that matches the agreed design and can be rebuilt from scripts or documented steps.
Evaluate plugins and check compatibility
Each plugin on the list is reviewed for maintenance status, license and its declared support for the target Redmine line, such as 7.0.x, before installation. Any plugin that cannot be confirmed for the target version is replaced or removed from scope. The output is a plugin register with versions, owners and compatibility notes.
Design the data import
The built-in Trac and Mantis importers are obsolete and do not work, and third-party scripts for Jira and Bugzilla are neither tested nor supported by the Redmine project, so the import must be designed and validated as its own work. The team maps users, statuses, fields and attachments, then runs test loads. The output is a mapping specification and a validated trial import report.
Test, train and cut over
Users run acceptance tests against the agreed requirements, administrators and project leads complete role-based training, and the final import and go-live steps are rehearsed. Cutover switches users to the production instance with a rollback plan. The output is signed acceptance test results and a cutover record.
Hand over with a runbook
The team delivers a runbook covering backups, restores, upgrade steps, plugin migration, monitoring and access administration, then transfers ownership to the client's operators. Phase timing for each step should be requested in the written scope before work begins. The output is the signed runbook and a completed handover checklist.

What teams keep in-house and what they outsource

This table compares each part of a Redmine rollout with its usual owner and the skills it needs, so you can see which work an internal team can usually carry and which parts are commonly bought from outside.

Work part	Usual owner	Skills needed	Why it sits there
Tracker and workflow design	Internal, with partner support	A named process owner plus Redmine configuration skill	Only your teams know how work moves, so the process owner decides; configuration is routine once the design is agreed
Role and permission model	Internal, with partner review	Knowledge of Redmine role-based access control and your data classification	Access decisions carry compliance weight, so the rules should be written and approved by your staff before anyone configures them
Hosting and database administration	Internal if Rails hosting experience exists	Rails and Ruby deployment, PostgreSQL or MySQL administration, backups	Teams that already run Rails applications can usually absorb this; a team without that experience often buys the initial build
Plugin selection and review	Internal decision, partner technical review	Ability to check plugin compatibility with the chosen Redmine line and review code	Each plugin adds upgrade work, so the team should decide which ones are worth keeping and check them before production
LDAP integration	Internal or partner, depending on directory skills	Directory administration, LDAP bind settings, test accounts	Needs access to your directory team and security approval, so the work depends on how your identity team operates
Data import scripting over the REST API	Partner, commonly bought	Scripting, mapping of source fields, REST API use, validation of results	Built-in importers for Trac and Mantis no longer work, so most imports are custom scripts that need repeated test runs
Training content	Internal, with partner drafting	Knowledge of your workflows, documentation and training delivery	Staff know their own processes best, so they should review and own the material after the first version
Day-two administration	Internal	Routine Redmine administration, user management, backup checks, log review	Ongoing operation stays with the owning team; the first upgrade cycle is the point where outside help is often bought again
First upgrade cycle	Partner, commonly bought	Ruby and Rails version changes, database migrations, plugin compatibility checks	The first upgrade tests every earlier choice at once, so teams without recent upgrade practice often buy this work

What usually goes wrong

Most Redmine rollouts that struggle do so for predictable reasons. Each card names a failure point and the step that prevents it, so the plan can assign an owner and a check before go-live.

Plugins chosen without compatibility checks

Teams often add plugins for features they want before checking whether each one supports Redmine 7.0 and its Rails and Ruby requirements. Before approving a plugin, confirm its compatibility with the 7.0 line, its maintenance status and whether its last update predates the release you plan to run. Record this in the plan.

Workflows copied from the old tool

Trackers, statuses, custom fields and workflows exported from a previous system often carry over history that no longer matches how teams work. Map each one to a current business step, remove unused fields, and have the process owners sign off on the design before it is built in Redmine.

Roles that grant too much access

Default or broadly scoped roles can expose private projects, time entries or issue fields to people who should not see them. Define roles from the access model first, test each one with a non-administrator account, and review the permissions on every project that holds sensitive work.

Undersized database or SQLite in production

The installation guide says SQLite is not suited to multi-user production use, so a production instance should run PostgreSQL, MySQL 8.0 to 8.4 with READ COMMITTED isolation, or SQL Server 2012 or higher. Size the database host for concurrent users and growth, and confirm the choice before hosting is priced.

LDAP accounts without an on-the-fly policy

When LDAP users are created on first login without a defined policy, accounts may receive the wrong default role, group or status, and leavers may keep access. Decide in advance which directory groups map to which Redmine roles, when accounts are created or locked, and who approves exceptions.

Attachments left out of the backup plan

Backing up only the database leaves uploaded files unprotected, and the upgrade guide calls for backing up both the database and uploaded files. Include the files directory in backup jobs, test a full restore that brings back issues and attachments together, and record the retention period.

No test environment for upgrades

Redmine upgrades run database migrations and plugin migrations, and a plugin that breaks can stop the release. Keep a staging copy built from a current backup, rehearse the upgrade steps from the upgrade guide there, and confirm each plugin works before the production change window.

Unclear ownership after go-live

Without a named owner for administration, plugin decisions, upgrades and user requests, issues pile up and security patches wait. Assign an administrator, a backup owner and an escalation path in the plan, and state which support and upgrade work is in scope for a retainer.

Historical data imported without validation

Moving projects, issues and users from another tracker without a field mapping produces duplicate users, broken references and lost history. The built-in Trac and Mantis importers no longer work, so plan a scripted import with a mapping document, sample runs and reconciliation counts agreed before cutover.

How the work changes by starting point

Teams moving from spreadsheets or email usually have no structured history to carry over, so the scope centers on defining the model before anything is configured. Expect the largest share of effort in trackers, statuses, workflows, roles and custom fields, plus a decision on which old spreadsheet rows are worth importing at all.

Scope: trackers, workflows, roles and projects are designed with the owners first, then built.
Database and storage: PostgreSQL or MySQL 8.0 to 8.4 is the production choice. SQLite is not suited to multi-user production use, according to the Redmine installation guide.
Data import: plan a small, cleaned import through the REST API or a scripted load, not a copy of every sheet.
Testing effort: user acceptance on real workflows, email notifications and permission checks per role.
Confirm with your team how many people will create issues by email before deciding on inbound mail setup.

What the client needs to provide

Scoping a Redmine rollout depends on a short list of inputs that only your organization can supply. Start by naming a business owner who decides which workflows matter and a project sponsor who can approve scope changes. Without both, the quote will carry assumptions that surface as change requests during the build.

Next, gather the structure of the work itself: every project to be migrated or created, the trackers each one uses, and the current workflow for each tracker, including statuses, who moves an item between them, and which fields are required at each step. Add a role and permission matrix, or at minimum a written description of who creates, edits, assigns and closes issues. Redmine's role-based access control is flexible, so the matrix determines how many roles and workflows the build must define. Also list the plugins or integrations your teams rely on today, such as time tracking exports, repository links or reporting, and state whether each one is required at go-live.

Identity and hosting decisions need concrete inputs. Provide the authentication directory details (for example, Active Directory or another LDAP service), a service account with read access to it, and a decision on whether single sign-on through SAML or OpenID Connect is required. Redmine authenticates against LDAP natively, but SSO depends on plugins or an authenticating reverse proxy, so this choice affects both effort and cost. Confirm whether the REST API will be used by other systems and who approves API access. Document hosting targets, network rules, the database engine you require, and your backup and retention policy, since the quote must reflect how backups and attachments are stored and restored.

Provide sample or full exports of current data and name the administrators who will own Redmine after go-live. Data volume and quality drive import effort more than any other input. If you are moving from Trac, Mantis, Jira or Bugzilla, note that the built-in importers for Trac and Mantis no longer work and the third-party scripts are untested, so the import method will be scoped from your samples. Keep a decision log from discovery onward. Record each decision, its owner and its date. A complete log shortens the quote and reduces rework during the build.

Frequently asked questions

How much does a Redmine implementation cost and what drives it?

Redmine itself has no license fee, so the cost of a deployment comes from people and infrastructure: scoping, hosting, the database, plugins, data import, training and ongoing administration. The Redmine home page states the software is released under the GNU General Public License v2 and that no paid edition exists. The largest drivers are the number of trackers, workflows and roles you need, how many plugins must be selected or built, whether historical data must be migrated, and how many users and integrations the system must serve. A written quote should itemize each of these as a separate line, with one-time work listed apart from recurring costs such as hosting, upgrades and plugin maintenance.

How long does a Redmine rollout take, and what sets the timeline?

The timeline depends mostly on scope decisions made before build starts: how many projects and trackers are needed, how complex the workflows and permission model are, which plugins are required, and whether data must come in from another tool. Hosting and database choices, identity integration and the number of environments (test, staging, production) also add steps. A fixed-scope engagement sets out deliverables and milestones in writing before work begins, so ask for the milestone plan in the quote rather than a single end date. Your own review and sign-off time is often the factor that moves the schedule most.

Can our own team deploy and run Redmine without a partner?

Yes, many teams do, because Redmine is a Ruby on Rails application with documented install and upgrade procedures. The questions to answer honestly are whether someone on your team can administer a Rails stack, keep the server on a supported branch, manage the database and backups, and review plugin compatibility at each upgrade. The supported lines at the time of writing are 7.0.x, 6.1.x and 6.0.x, with 6.1.x and 6.0.x receiving only fixes and security updates, so staying current requires routine work. If those skills or hours are not available, a partner can take on some or all of this under a written scope.

What does the work need from our team?

Expect to supply decisions and people, not just access. Your side typically provides a business owner who signs off trackers, statuses, workflows and role permissions, a technical contact for hosting, network, certificates and identity, and a source of truth for historical data if an import is needed. Named reviewers for test cycles and training sessions are also needed. Ask the provider to list these responsibilities in the scope document, with the expected review points, so your team can plan its time before the project starts.

Which database should we choose for Redmine?

For multi-user production use, choose between PostgreSQL, MySQL and SQL Server, based on the database skills and backup tooling your organization already runs. The Redmine installation guide supports PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, and SQL Server 2012 or higher. The guide states SQLite is not suited to multi-user production use. Confirm the exact version compatibility for your chosen Redmine line before purchase, and ask how database backups and restores will be tested as part of the handover.

Does Redmine support single sign-on, and can we import from Jira or Trac?

Redmine authenticates natively against LDAP directories, but SAML or OpenID Connect single sign-on is not part of core Redmine. It depends on a plugin or an authenticating reverse proxy, so the choice should be made during scoping. For migration, the built-in importers for Trac and Mantis are marked obsolete and not working, and third-party scripts for systems such as Jira are described as neither tested nor supported. Plan imports as a separate, scripted piece of work with mapping and validation, and ask the provider to confirm which source systems and data types are in scope.

How DeployOpen scopes, delivers and supports Redmine

DeployOpen plans, implements, customizes, documents and supports Redmine inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped network. Engagements are fixed-scope, so the plan, deliverables and timeline are agreed in writing before the build starts.

How we scope

Written scope lists the hosting model, database choice (PostgreSQL, MySQL 8.0 to 8.4 or SQL Server) and the Ruby and Rails versions for the Redmine 7.0 line.
Scope names each tracker, workflow, role and custom field, so the cost of configuration work is visible before the build starts.
Plugins are listed one by one with a compatibility check and an owner for maintenance, since each one adds upgrade effort later.

How we build

Installation covers the application server, database, background job queue and optional components such as ImageMagick and Pandoc, as agreed in scope.
Authentication is configured as scoped, for example native LDAP, with SSO through plugins or a reverse proxy where that was agreed.
Data import is tested on a copy first, with mappings checked for users, projects, issues and attachments before any cutover.

How we hand over

Handover documents the installed version, configuration, plugin list, backup jobs and the restore steps your team needs to run.
Test evidence records the import checks, role and workflow tests, and the results agreed in the written acceptance criteria.
Administrator training covers day-to-day tasks, the upgrade procedure and how to review API access if the REST API is enabled.

How we support

Ongoing support, upgrades and plugin compatibility checks are available as a retainer, scoped separately from the build.
Upgrade work follows the Redmine upgrade procedure, with database and uploaded file backups taken before migrations run.
Ask in the quote which Redmine branch will be supported after handover, since 6.x and older lines receive narrower security coverage.