Quitter Opsgenie avant le 5 avril 2027

Atlassian a arrêté les nouvelles ventes d’Opsgenie le 4 juin 2025 et en arrête le support le 5 avril 2027, date à laquelle l’éditeur indique supprimer les données clients non migrées. Voici ce qu’il faut migrer, et dans quel ordre.

Sur cette page

Si votre astreinte tourne sur Opsgenie, vous avez une date fixe au calendrier et une décision à prendre avant elle.

Les conseils qui suivent sont neutres vis-à-vis des fournisseurs et couvrent quatre sujets :

  • ce qui disparaît avec le produit
  • ce qu’il faut inventorier
  • l’ordre qui préserve la couverture pendant la migration
  • la manière de dimensionner l’effort

Perstat apparaît à la fin, avec la question de la consolidation, et non comme point de départ.

Deux dates fixent votre calendrier

Atlassian a mis fin aux nouvelles ventes le 4 juin 2025 et arrêtera le support le 5 avril 2027. Selon la page de licence, les clients existants peuvent ajouter des utilisateurs jusqu’au 5 avril 2027 et ne renouveler que si leur période d’abonnement se termine avant cette date.

Le mot qui gouverne votre planification est non migrées. La même page de licence indique que les données clients non transférées vers Jira Service Management sont supprimées à cette date. La documentation d’arrêt d’Atlassian ajoute qu’Opsgenie s’arrête automatiquement 120 jours après une migration si vous ne l’arrêtez pas manuellement. Avant cette date, exportez tout ce que vous voulez conserver en dehors des parcours de migration proposés.

C’est une décision produit d’Atlassian, énoncée clairement. Elle ne dit rien des outils voisins et fixe seulement votre calendrier.

Pour une équipe réglementée, l’historique d’incidents conservé peut alimenter la documentation interne et les déclarations. DORA s’applique depuis le 17 janvier 2025. Ni un historique exporté ni l’outil de remplacement ne déterminent si DORA s’applique, et aucun des deux n’établit la conformité d’une organisation.

Faire l’inventaire avant de chercher un outil

Passez une heure dans la console Opsgenie et notez ce que vous utilisez. L’inventaire sera peut-être plus court que vous ne le craigniez, et il peut révéler des dépendances oubliées. Cinq catégories suffisent.

Relever les plannings et les rotations

Notez qui est d’astreinte, quand, et pour quelles équipes et quels fuseaux horaires. Notez aussi les remplacements et les règles des jours fériés. Ce sont ces détails qui cassent sans bruit après une migration.

Consigner les règles d’escalade

Notez chaque chaîne : qui est alerté, au bout de combien de temps, et ce qui se passe si personne n’acquitte. Relevez les délais, pas seulement l’ordre.

Lister les intégrations et les sources d’alertes

Listez chaque système qui ouvre une alerte :

  • les outils de monitoring
  • les alarmes des fournisseurs cloud
  • les outils de suivi des erreurs
  • les webhooks
  • les passerelles e-mail

Les intégrations peuvent demander un travail conséquent. Chaque source doit être rebranchée et testée dans le nouveau système.

Documenter le routage et les équipes

Notez comment les alertes se répartissent entre équipes, tags et priorités. Les règles de routage contiennent un savoir accumulé, et une bascule précipitée peut le faire perdre.

Exporter l’historique et les rapports

Cette catégorie regroupe les alertes passées, les chronologies d’incidents et les rapports d’astreinte. Décidez de ce que vous devez garder. Exportez-le tôt, dans le format que fournit Opsgenie, avant la fin de votre accès à Opsgenie.

Migrer dans un ordre qui préserve la couverture

Ne basculez pas tout d’un coup. Faites tourner les deux systèmes en parallèle et déplacez les sources d’alertes une par une.

  1. Exportez l’historique et les rapports maintenant, avant tout autre changement.
  2. Terminez l’inventaire ci-dessus. Choisissez ensuite entre un remplacement ciblé et une consolidation, comme le décrit la section suivante.
  3. Reconstruisez les plannings et les règles d’escalade dans le nouvel outil. Gardez-les d’abord identiques, puis améliorez-les.
  4. Rebranchez les intégrations une source à la fois. Vérifiez que chacune alerte bien une personne avant de passer à la suivante.
  5. Faites tourner les deux systèmes en parallèle pendant une rotation d’astreinte complète. Testez de manière contrôlée chaque route d’alerte prévue avant la bascule.
  6. Basculez, puis démantelez Opsgenie une fois que vous avez exporté tout ce dont vous avez besoin.

Choisir entre remplacement ciblé et consolidation

C’est la vraie décision. Accordez-lui 30 minutes avant d’établir la moindre présélection.

Opsgenie gère l’astreinte et le routage des alertes. Vous pouvez le remplacer par un autre outil d’astreinte dédié et laisser le reste de votre pile intact. C’est la voie qui réserve le moins de surprises, et pour certaines équipes c’est la bonne.

Prenez une pile où l’astreinte côtoie un monitoring d’uptime, une page de statut et un processus d’incident séparés, chez des fournisseurs différents. Si ces fournisseurs ne partagent pas leurs données, la migration est l’occasion d’évaluer une consolidation pendant que vous reconstruisez les plannings et rebranchez les intégrations.

Aucune des deux réponses n’est automatiquement la bonne. Si vos sources d’alertes sont profondément ancrées dans un écosystème, un outil d’astreinte équivalent peut préserver le flux de travail. C’est aussi le cas si vous vous appuyez sur une intégration étroite avec Jira Service Management et le ticketing.

Si l’éparpillement des outils est le problème, la migration est un moment propice pour évaluer la consolidation.

Dimensionner l’effort d’après votre inventaire

N’empruntez pas une durée générique. Comptez les éléments suivants, puis attribuez à chacun un responsable et un test :

  • les plannings et les règles d’escalade
  • les sources d’alertes et les intégrations
  • les rapports
  • les équipes
  • les parcours de formation

Le délai total comprend les validations et une période en parallèle. Le travail effectif découle de l’inventaire.

Définissez les critères de sortie avant de fixer une date :

  • Chaque source d’alertes atteint la route prévue.
  • Chaque planning a un responsable.
  • L’acquittement arrête l’escalade.
  • Un incident contrôlé se termine par un rétablissement.
  • L’ancien chemin reste disponible jusqu’à la réussite de ces vérifications.

Ces critères rendent l’estimation vérifiable, sans prétendre qu’un seul calendrier convient à toutes les organisations.

Garder une courte liste de contrôle

  • Exportez d’abord l’historique des alertes, les registres d’incidents et les rapports d’astreinte.
  • Inventoriez les cinq catégories ci-dessus, puis choisissez entre remplacement ciblé et consolidation.
  • Reconstruisez à l’identique plannings et escalades dans le nouvel outil.
  • Rebranchez les intégrations une par une et testez chacune.
  • Faites tourner les deux systèmes en parallèle pendant une rotation complète.
  • Basculez, vérifiez vos exports, puis démantelez.

Perstat est une option pour consolider

Si la consolidation figure sur votre liste, Perstat est une option à examiner. Il réunit monitoring d’uptime, pages de statut, gestion des incidents et astreinte dans un seul produit. Son plan de contrôle dans l’UE est exploité par la société allemande Datargo GmbH.

Les concepts d’Opsgenie ont des équivalents familiers :

  • Les plannings et les rotations d’astreinte sont inclus dès Sentinel.
  • Le push natif passe par les apps Apple.
  • Les SMS personnels sont inclus dès Pulse.
  • Sentinel ajoute l’escalade d’astreinte du push au SMS puis à l’appel téléphonique.
  • L’acquittement reste une action explicite.

Le monitoring qui vous alerte se trouve dans le même produit. Onze types de checks régionaux, dont HTTP, TCP et DNS, utilisent jusqu’à six régions selon l’offre et une politique régionale configurable, avec un quorum de 2 par défaut. Les monitors agent et heartbeat n’utilisent ni régions ni quorum.

Un composant de page de statut lié peut utiliser le même registre de monitor et d’incident. La publication reste une action explicite.

Perstat tient un registre de disponibilité arbitré. L’ exemple de rapport SLA public est une illustration éditoriale, pas un rapport client généré. Chaque vue de monitor propose un rapport PDF sur 7, 14, 30 ou 90 jours, ni signé ni attesté, et un CSV avec manifeste est fourni manuellement sur demande.

Perstat ne remplace ni Jira Service Management, ni le ticketing, ni l’APM, ni la gestion des logs. Si ces outils sont essentiels pour vous, un outil d’astreinte dédié convient mieux. C’est un bon résultat de cet exercice.

La page de comparaison Opsgenie établit la correspondance concept par concept. Les prix figurent sur la page tarifs, hors TVA, et vous pouvez commencer gratuitement.

Lancez le monitoring gratuitement ou suivez la visite guidée. La visite se fait sans inscription, et les prix se consultent sans rendez-vous commercial.