RedminePRO runs a done-for-you Redmine migration service. Our engineers move your instance — projects, issues with full history, wikis, attachments, users and permissions, custom fields, workflows, time entries, and every compatible plugin — onto fully-managed Redmine on AWS. You don't touch a server, and you don't spend a Saturday discovering your 2019 attachment paths were absolute.
The general case is below. If you are on one of these, start with its page — the details differ enough to matter.
Every Redmine upgrade is a weekend project with a rollback plan. Ours happen continuously, invisibly, for you.
When your Redmine admin leaves, the instance becomes a liability. Managed hosting removes the key-person risk.
A backup that's never been restored is a hope, not a backup. We run encrypted backups with point-in-time recovery, tested as part of our DR process.
A Redmine instance is three things: a database, a files directory, and a configuration. Everything a user thinks of as “our Redmine” lives in the first two. The third is the part that does not travel, and it is where migrations go wrong. Here is the explicit inventory. If something you rely on is not on this list, ask about it in the assessment — we would rather tell you before the move than after.
| What | Migrated | Notes |
|---|---|---|
| Projects and subprojects | Yes | Full hierarchy, identifiers, visibility, module enablement |
| Issues with full history | Yes | Every journal entry, status/field change, author and timestamp |
| Issue relations and subtasks | Yes | Blocks, relates, duplicates, precedes/follows, parent-child |
| Wikis and wiki history | Yes | Every page, every revision, attachments on pages |
| Documents, news, forums | Yes | Core Redmine modules move with the database |
| Files and attachments | Yes | The whole files tree, re-linked to their records |
| Users, groups, roles, permissions | Yes | Including salted password hashes — no resets needed |
| Custom fields | Yes | Definitions, per-tracker enablement, every stored value |
| Trackers, statuses, workflows | Yes | The full workflow matrix, role-by-status transitions |
| Enumerations | Yes | Priorities, activities, document categories |
| Time entries | Yes | With activities, comments and issue associations |
| Versions, categories, queries | Yes | Including saved custom queries, public and private |
| Repository links | Yes, with rework | Remote repos re-point; filesystem-local repos need rehosting first |
| Compatible plugins and data | Yes | Audited during assessment — “compatible” does real work here |
This is the section other migration pages leave out. Read it before you plan the move.
None of this list is unusual and none of it stops a migration. It exists so that the assessment finds these things instead of the cutover finding them.
1. Share your setup. Tell us your Redmine version, user count, database engine, approximate data size and plugin list in the assessment form. We review it and confirm a plan within one business day. If we are not the right fit, we say so.
2. Plugin and version audit. We check every plugin against the target Redmine version and hand you a written list: runs as-is, has a maintained replacement, or is dead. You decide what to keep before any data moves. This is where the surprises are supposed to happen.
3. First pass — a full dry run. We take a copy of your database and files and build a complete working workspace on RedminePRO. Nothing about your production system changes. You get a URL and an admin login for the copy.
4. You validate. Log in as yourself, open the projects you care about, check that issue history reads correctly, attachments open, saved queries return what they returned before, and workflows behave. Find something wrong, tell us, we fix it and re-run. There is no limit on iterations before you are satisfied.
5. Cutover. When you sign off, we schedule the final sync at a time you choose, take a delta of everything that changed since the dry run, apply it, and switch DNS. Typical downtime: minutes. Your old instance stays exactly where it is.
6. Post-cutover. Your old system stays available read-only for as long as you want it, on your infrastructure — we never touch it. If anything looks wrong in the first week, the dry-run instance and your original system are both still there.
Two different clocks get confused in migration conversations.
Project duration is how long the whole exercise takes from assessment to cutover. Most migrations complete within hours; large instances with many plugins can take a few days including validation. The assessment gives you a real estimate for your instance, not an average.
Downtime is how long your team cannot use Redmine. That is only the final delta sync and the DNS switch — typically minutes, scheduled when you choose. It is short because the hard work already happened during the dry run, on a copy, while everyone kept working normally.
To be exact about it: the assessment is free; the migration itself is a one-time professional-services fee, quoted after the assessment, with no surprises. What that done-for-you service covers:
What sits outside that scope, and is quoted separately if you want it: custom plugin development (including re-implementing a core patch as a plugin, an Enterprise-plan capability); data cleanup, re-modeling or merging projects as part of the move; and rebuilding a workflow or field structure differently from how it exists today.
Redmine 7.0.0 was released on 30 June 2026 and requires Rails 8.1 and Ruby 3.2, 3.3, 3.4 or 4.0 (redmine.org, checked 2 August 2026). For a self-hosted instance that is rarely a single afternoon: the Rails major, the Ruby version, the application server and often the database all move together, and every installed plugin needs checking against the new version before you find out the hard way which one no longer loads.
There is no cliff here and we are not going to invent one. The 6.1.x line still exists and plenty of teams will sit on it for a while. But if the Redmine 7 upgrade was already on the list and has not moved, it is a reasonable moment to ask whether you want to be the one doing it. We handle the Redmine 7 upgrade as part of the migration, with the plugin compatibility check and the rollback plan described below.
One concrete detail from Redmine's own documentation, in case it saves you an evening: Ruby 4.0.0 through 4.0.3 have a significant wiki rendering slowdown, and Ruby 4.0.4 or later is recommended for Redmine 7.0.
If the upgrade has you reconsidering self-hosting altogether, rather than just this one version: Redmine cloud covers what changes when Redmine is run as a service, and hosted Redmine covers what to check across vendors before you pick one.
Every migration should have an answer to “what if this goes wrong”, and most vendors don't publish one.
Before cutover there is nothing to roll back. Your production Redmine has not been modified — we work on copies. If validation fails, you walk away having lost nothing but the time you spent looking at a test instance.
At cutover the rollback is a DNS change. Your old instance is untouched and still holds every issue up to the sync point. The only thing at risk is work created between the final sync and a decision to roll back — which is why cutover is scheduled at a quiet hour.
Later, Redmine is open source and this is not a one-way door. We provide your full database dump and files archive (SQL + files) on request at any time, so you can move back to self-hosted, or to another host, whenever you choose. We earn your renewal; we don't lock it in.
Fully-managed Redmine on AWS, in US, EU or India — you choose the region at signup and your data resides in that region. Encryption at rest via AWS KMS (FIPS 140-2 validated), AES-256; TLS 1.2+ in transit; continuous encrypted backups with point-in-time recovery. HAZERCLOUD maintains active ISO/IEC 27001 certification covering its information security management system, and RedminePRO operates inside that certified ISMS. You get full Redmine administrator access on your workspace — the point of migrating to us rather than to a host that takes the admin panel away along with the server. Plans start at $29/month for up to 25 users with unlimited projects. Managed hosting · Security · Pricing.
Tell us what you're running. We'll come back within one business day with a migration plan and a real estimate. No obligation — if we're not the right fit, we'll tell you.