Your Redmine fell behind. We get it moving again.
A team based in Geneva
Redmine is rarely deployed as it ships. It grows into a business platform, then it freezes: nobody dares upgrade it any more. That is where we come in.
What we do
Upgrades and maintenance
We move production instances from Redmine 4 to Redmine 7, Rails and Ruby included, without losing your customisations. Heavily modified instances included.
Custom plugins and engines
Your process does not fit stock Redmine. We write the Rails plugin that carries it, inside the core conventions, so it survives the next upgrade instead of blocking it.
Security and audit
Dependency fixes, content security policy, authorisation holes, static analysis findings. We already work under external audit in large organisations.
A few figures
- 15 years of experience
- with Redmine, as users, administrators and developers
- 9
- Redmine plugins published as open source
- 4 → 7
- the major versions we take instances across, Rails and Ruby included
- thousands
- of users on the most customised platform we maintain
Why a Redmine ends up frozen
Every customisation adds a reason not to upgrade. A plugin that reaches into the core, a model override, one extra field in a view: at the next release, all of it has to be reapplied.
After two or three skipped versions, upgrading stops being maintenance and becomes a project. Upstream security fixes are out of reach, and every business change is argued against the platform.
Our job is to shrink that debt rather than grow it: back onto a supported release first, then strip out the changes that are no longer needed.
Tell us where you stand
Your current version, your plugins, what is blocking you. We reply with a first assessment, no strings attached.