RedminePRO propose un service de migration Redmine pris en charge de bout en bout. Nos ingénieurs déplacent votre espace de travail vers un Redmine entièrement géré : projets, demandes avec leur historique complet, wikis, pièces jointes, utilisateurs et permissions, champs personnalisés, workflows, temps passé, et chaque extension compatible. Vous ne touchez pas à un serveur, et vous ne passez pas un samedi à découvrir que vos chemins de pièces jointes de 2019 étaient absolus.
Le cas général est décrit ci-dessous. Si vous êtes sur l’une de celles-ci, commencez par sa page. Les détails diffèrent suffisamment pour compter. Ces pages sont en anglais.
Correspondance des champs, ce qui est transféré, ce que vous reconstruisez. Lire
Reprise de la pile logicielle et le problème de la mise à jour. Lire
Exports, accès aux extensions, et HostedRedmine. Lire
Le changement de nom, le renouvellement, et ce qu’un fork vous coûte. Lire
Chaque mise à jour de Redmine est un projet de week-end avec un plan de retour arrière. Les nôtres se font en continu, sans que vous les voyiez, pour vous.
Quand votre administrateur Redmine s’en va, l’installation devient un risque. L’hébergement géré supprime la dépendance à une personne clé.
Une sauvegarde qui n’a jamais été restaurée est un espoir, pas une sauvegarde. Nous exécutons des sauvegardes chiffrées avec restauration à un instant donné, testées dans le cadre de notre processus de reprise après sinistre.
Une installation Redmine, c’est trois choses : une base de données, un répertoire de fichiers, et une configuration. Tout ce qu’un utilisateur appelle « notre Redmine » vit dans les deux premières. La troisième est la partie qui ne voyage pas, et c’est là que les migrations échouent. Voici l’inventaire explicite. Si quelque chose dont vous dépendez ne figure pas dans cette liste, posez la question lors de l’évaluation. Nous préférons vous le dire avant le déplacement plutôt qu’après.
| Élément | Migré | Remarques |
|---|---|---|
| Projets et sous-projets | Oui | Hiérarchie complète, identifiants, visibilité, modules activés |
| Demandes avec historique complet | Oui | Chaque entrée de journal, changement de statut ou de champ, auteur et horodatage |
| Relations et sous-tâches | Oui | Bloque, lié à, doublon, précède et suit, parent-enfant |
| Wikis et historique des wikis | Oui | Chaque page, chaque révision, les pièces jointes des pages |
| Documents, annonces, forums | Oui | Les modules natifs de Redmine suivent la base de données |
| Fichiers et pièces jointes | Oui | L’arborescence complète, reliée à ses enregistrements |
| Utilisateurs, groupes, rôles, permissions | Oui | Y compris les mots de passe salés et hachés, donc aucune réinitialisation |
| Champs personnalisés | Oui | Définitions, activation par tracker, chaque valeur stockée |
| Trackers, statuts, workflows | Oui | La matrice de workflow complète, transitions par rôle et par statut |
| Énumérations | Oui | Priorités, activités, catégories de documents |
| Temps passé | Oui | Avec les activités, les commentaires et les liens vers les demandes |
| Versions, catégories, requêtes | Oui | Y compris les requêtes personnalisées enregistrées, publiques et privées |
| Liens vers les dépôts | Oui, avec reprise | Les dépôts distants sont repointés. Les dépôts locaux au serveur doivent d’abord être réhébergés |
| Extensions compatibles et leurs données | Oui | Auditées lors de l’évaluation, où « compatible » a un vrai sens |
C’est la section que les autres pages de migration omettent. Lisez-la avant de planifier le déplacement.
Rien dans cette liste n’est inhabituel et rien n’empêche une migration. Elle existe pour que l’évaluation trouve ces points au lieu que la bascule les trouve.
Décrivez votre installation. Indiquez votre version de Redmine, le nombre d’utilisateurs, le moteur de base de données, le volume de données approximatif et la liste des extensions dans le formulaire d’évaluation. Nous l’examinons et confirmons un plan sous un jour ouvré. Si nous ne sommes pas le bon choix, nous le disons.
Audit des extensions et des versions. Nous vérifions chaque extension par rapport à la version cible de Redmine et vous remettons une liste écrite : fonctionne telle quelle, a un remplaçant maintenu, ou est morte. Vous décidez ce que vous gardez avant que la moindre donnée ne bouge. C’est ici que les surprises sont censées arriver.
Premier passage : une répétition complète. Nous prenons une copie de votre base et de vos fichiers et construisons un espace de travail complet et fonctionnel sur RedminePRO. Rien ne change sur votre système de production. Vous recevez une URL et un identifiant administrateur pour la copie.
Vous validez. Connectez-vous avec votre propre compte, ouvrez les projets qui comptent, vérifiez que l’historique des demandes se lit correctement, que les pièces jointes s’ouvrent, que les requêtes enregistrées renvoient ce qu’elles renvoyaient avant, et que les workflows se comportent comme prévu. Vous trouvez un problème, vous nous le dites, nous le corrigeons et nous relançons. Il n’y a pas de limite au nombre d’itérations avant que vous soyez satisfait.
Bascule. Quand vous validez, nous planifions la synchronisation finale à l’heure de votre choix, prenons le delta de tout ce qui a changé depuis la répétition, l’appliquons, et basculons le DNS. Interruption typique : quelques minutes. Votre ancienne installation reste exactement où elle est.
Après la bascule. Votre ancien système reste disponible en lecture seule aussi longtemps que vous le souhaitez, sur votre infrastructure. Nous n’y touchons jamais. Si quelque chose semble anormal la première semaine, l’instance de répétition et votre système d’origine sont toujours là.
Deux horloges différentes se confondent dans les conversations sur la migration.
La durée du projet, c’est le temps que prend l’ensemble, de l’évaluation à la bascule. La plupart des migrations se terminent en quelques heures. Les grosses installations avec beaucoup d’extensions peuvent prendre quelques jours, validation comprise. L’évaluation vous donne une estimation réelle pour votre installation, pas une moyenne.
L’interruption, c’est le temps pendant lequel votre équipe ne peut pas utiliser Redmine. Ce n’est que la synchronisation finale du delta et le basculement DNS, en général quelques minutes, planifiés quand vous le choisissez. C’est court parce que le gros du travail a déjà eu lieu pendant la répétition, sur une copie, pendant que tout le monde continuait à travailler normalement.
Pour être précis : l’évaluation est gratuite, et la migration elle-même est une prestation de services unique, chiffrée après l’évaluation, sans surprise. Ce que couvre ce service pris en charge :
Ce qui sort de ce périmètre, et qui est chiffré séparément si vous le souhaitez : le développement d’extensions sur mesure, y compris la réimplémentation d’une modification du cœur sous forme d’extension, qui est une capacité du forfait Enterprise. Le nettoyage de données, la refonte ou la fusion de projets dans le cadre du déplacement, et la reconstruction d’un workflow ou d’une structure de champs différente de celle qui existe aujourd’hui.
Redmine 7.0.0 est sorti le 30 juin 2026 et exige Rails 8.1 et Ruby 3.2, 3.3, 3.4 ou 4.0 (redmine.org, vérifié le 2 août 2026). Pour une installation auto-hébergée, c’est rarement l’affaire d’un après-midi : la version majeure de Rails, la version de Ruby, le serveur d’application et souvent la base de données changent en même temps, et chaque extension installée doit être vérifiée par rapport à la nouvelle version avant que vous ne découvriez à vos dépens laquelle ne se charge plus.
Il n’y a pas de précipice ici et nous n’allons pas en inventer un. La branche 6.1.x existe toujours et beaucoup d’équipes y resteront un moment. Mais si la mise à jour vers Redmine 7 était déjà sur la liste et n’a pas bougé, c’est un moment raisonnable pour vous demander si vous voulez être celui qui la fait. Nous prenons en charge la mise à jour vers Redmine 7 dans le cadre de la migration, avec la vérification de compatibilité des extensions et le plan de retour arrière décrit ci-dessous.
Un détail concret tiré de la documentation de Redmine, au cas où il vous épargne une soirée : Ruby 4.0.0 à 4.0.3 présentent un ralentissement important du rendu des wikis, et Ruby 4.0.4 ou supérieur est recommandé pour Redmine 7.0.
Si la mise à jour vous fait reconsidérer l’auto-hébergement dans son ensemble, plutôt que cette seule version : l’hébergement Redmine géré décrit ce qui change quand Redmine est exploité comme un service, et ce qu’il faut vérifier chez chaque prestataire avant d’en choisir un.
Chaque migration devrait avoir une réponse à « et si ça tourne mal », et la plupart des prestataires n’en publient pas.
Avant la bascule, il n’y a rien à annuler. Votre Redmine de production n’a pas été modifié. Nous travaillons sur des copies. Si la validation échoue, vous repartez sans avoir rien perdu, sinon le temps passé à regarder une instance de test.
À la bascule, le retour arrière est un changement de DNS. Votre ancienne installation est intacte et contient encore chaque demande jusqu’au point de synchronisation. La seule chose exposée est le travail créé entre la synchronisation finale et une décision de retour arrière. C’est pourquoi la bascule est planifiée à une heure calme.
Plus tard, Redmine est open source et ce n’est pas une porte à sens unique. Nous fournissons l’export complet de votre base de données et l’archive de vos fichiers (SQL et fichiers) sur demande, à tout moment, pour repasser en auto-hébergement ou changer de prestataire quand vous le décidez. Nous méritons votre renouvellement. Nous ne le verrouillons pas.
Un Redmine entièrement géré, aux États-Unis, en Irlande, en France ou en Inde. Vous choisissez la région à l’inscription et vos données y résident. Pour une équipe française, la région Paris signifie que vos données restent en France. Chiffrement AES-256 au repos, TLS 1.2 ou supérieur en transit, et sauvegardes continues chiffrées avec restauration à un instant donné. Vous obtenez l’accès administrateur complet à Redmine sur votre espace de travail : c’est tout l’intérêt de migrer chez nous plutôt que chez un hébergeur qui retire le panneau d’administration en même temps que le serveur. Les forfaits commencent à 29 $ par mois pour 25 utilisateurs au maximum avec des projets illimités. Hébergement géré · Sécurité · Tarifs.
Dites-nous ce que vous utilisez. Nous revenons vers vous sous un jour ouvré avec un plan de migration et une estimation réelle. Sans engagement. Si nous ne sommes pas le bon choix, nous vous le dirons.