Opsgenie End of Life: chiusura nel 2027 e alternative

Opsgenie chiude il 5 aprile 2027. Scopri cosa smette di funzionare, qual è il percorso di migrazione di Atlassian e quando basta un livello leggero per il recapito degli avvisi.

Indice

Opsgenie chiude il 5 aprile 2027. Da quella data il prodotto non sarà più accessibile, le sue integrazioni e le API REST smetteranno di funzionare e i dati dei clienti non migrati verranno eliminati.

Per la maggior parte dei team, il percorso ufficiale di Atlassian verso Jira Service Management è il sostituto completo più sicuro. Ma se usi Opsgenie soprattutto per trasformare gli eventi di monitoraggio in avvisi urgenti sul telefono, è anche il momento giusto per decidere se ti serve davvero ancora una piattaforma completa di gestione degli incidenti oppure basta un livello di notifica più piccolo.

Questa guida spiega la scadenza, cosa cambia e come scegliere un percorso di migrazione senza lasciare buchi nella reperibilità.

Le date della fine vita di Opsgenie

DataCosa cambia
4 marzo 2025Atlassian annuncia la fine della vendita e del supporto di Opsgenie.
4 giugno 2025Si chiudono le nuove vendite di Opsgenie. Non è più possibile cambiare piano né creare nuovi site.
5 aprile 2027Opsgenie viene spento e non è più accessibile. I dati dei clienti non migrati vengono eliminati.

I clienti esistenti possono continuare a usare Opsgenie fino alla data di spegnimento, ma ridursi alle ultime settimane significa correre un rischio del tutto evitabile. Atlassian consiglia di completare il passaggio prima del 5 aprile 2027. Per la tempistica aggiornata vedi la pagina ufficiale sulla migrazione di Opsgenie e le FAQ sulle licenze Opsgenie.

Cosa smette di funzionare dopo il 5 aprile 2027?

Quando Opsgenie viene spento, i team perdono l'accesso al prodotto e a qualsiasi flusso di lavoro che ancora ne dipenda. Nello specifico:

  • Gli avvisi e i flussi on-call di Opsgenie
  • L'app mobile Opsgenie
  • Le integrazioni Opsgenie rimaste attive
  • Gli endpoint della REST API di Opsgenie
  • Dati e configurazioni non migrati

Lo spegnimento riguarda molto più della dashboard web. Un monitor può continuare a rilevare un disservizio mentre la vecchia integrazione Opsgenie diventa silenziosamente un vicolo cieco. La guida di Atlassian su cosa succede quando Opsgenie viene spento consiglia di spostare per primi tutti i flussi di alerting e di reperibilità.

Il sostituto ufficiale: Jira Service Management

Jira Service Management è la scelta naturale quando devi conservare il modello operativo completo di Opsgenie: avvisi, turni, policy di escalation, flussi di gestione degli incidenti e dati storici.

Chi amministra un account Opsgenie può aprire Settings → Plan your move per vedere il piano Jira Service Management consigliato e pianificare la migrazione. Secondo Atlassian, una volta scelto e approvato il piano di destinazione, gran parte dei dati e delle configurazioni di Opsgenie può essere sincronizzata in automatico.

Non dare per scontato che ogni funzionalità si sposti immutata. Il confronto tra le funzionalità pubblicato da Atlassian elenca i metodi di contatto che dipendono dal piano, le funzioni deprecate, le integrazioni da riconfigurare a mano e gli endpoint API da aggiornare.

Un vincolo importante: lo strumento di migrazione integrato nel prodotto supporta le destinazioni Atlassian Cloud, non Jira Service Management Data Center. I team che restano su Data Center devono valutare un'altra strada invece di aspettarsi una migrazione diretta. Atlassian documenta il limite nella guida alla pianificazione della migrazione.

Quando ha senso un'alternativa leggera a Opsgenie

Non tutti gli account Opsgenie usano rotazioni, alberi di escalation, timeline degli incidenti e analytics. Alcuni team piccoli lo usano per un compito molto più circoscritto:

  1. Uno strumento di monitoraggio rileva un evento critico.
  2. Un'integrazione inoltra l'evento.
  3. Un telefono fa abbastanza rumore da far reagire qualcuno.

Se è così anche da te, sostituire l'intera piattaforma rischia di aggiungere più processo di quanto ti serva. Echobell è un livello di recapito specializzato: riceve trigger via webhook o email e invia sul telefono avvisi normali, urgenti o con chiamata.

Echobell non è un sostituto uno a uno di Opsgenie. Non rimpiazza la pianificazione avanzata dei turni, le policy di escalation, il coordinamento degli incidenti o la reportistica post-incidente. Per quei flussi ti servono Jira Service Management o un'altra piattaforma completa di gestione degli incidenti.

Echobell può bastare quando:

  • La tua fonte di monitoraggio decide già quali eventi sono critici.
  • Un gruppo piccolo e stabile si divide la reperibilità.
  • Vuoi un recapito diretto dal webhook al telefono senza rimettere mano al monitor.
  • Ti servono livelli di urgenza diversi per eventi critici, di avvertimento e informativi.
  • Vuoi collaudare il recapito degli avvisi in modo indipendente, prima di toccare il resto dello stack.

Per una scelta funzionalità per funzionalità, vedi Echobell vs Opsgenie.

Come collaudare Echobell prima della chiusura di Opsgenie

La migrazione più sicura è un test in parallelo, non un unico passaggio secco alla scadenza.

1. Scegli una sola fonte di avvisi critici

Parti da un servizio in produzione con responsabilità chiara e volume di avvisi prevedibile. Evita di spostare tutte le integrazioni insieme.

2. Crea un canale Echobell

Crea un canale per quel servizio e condividilo con le persone che devono ricevere l'avviso. Ogni iscritto sceglie sul proprio dispositivo il comportamento di notifica più adatto.

3. Aggiungi una seconda destinazione webhook

Lascia attivo il percorso Opsgenie esistente e aggiungi alla fonte di monitoraggio il webhook del canale Echobell. Un payload di prova essenziale è questo:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Production API is down",
    "body": "Health check failed in us-east-1",
    "severity": "critical",
    "externalLink": "https://status.example.com/incidents/123"
  }'

Negli script e nei gestori di segreti usa un token segnaposto: non mettere mai sotto controllo di versione l'URL webhook reale di un canale. La documentazione sui webhook spiega variabili e modelli del payload.

Se la fonte supporta le email ma non i webhook, usa invece un trigger email.

4. Assegna l'urgenza con criterio

Riserva gli avvisi con chiamata agli eventi che richiedono una reazione immediata. Usa gli avvisi urgenti per le segnalazioni importanti e le notifiche normali per gli eventi informativi. Così il canale urgente resta credibile, invece di ricreare l'affaticamento da avvisi dentro una nuova app.

5. Fai girare i due percorsi durante una reperibilità vera

Confronta tempi di recapito, chiarezza dei messaggi, falsi positivi e reazione di chi è di turno. Prova anche le notifiche di ripristino, non solo quelle di guasto.

6. Metti per iscritto ciò che Echobell non sostituisce

Prima di togliere Opsgenie da quel servizio, assegna un responsabile a ogni requisito rimasto scoperto: turni, escalation, presa in carico, audit o reportistica. Se quei requisiti sono irrinunciabili, tienili dentro un sistema completo di gestione degli incidenti.

Checklist per la migrazione da Opsgenie

Usa questa checklist prima dello spegnimento del 5 aprile 2027:

  • Fai l'inventario di ogni integrazione in ingresso, heartbeat, client API e integrazione email.
  • Esporta o migra i dati storici che il tuo team deve conservare.
  • Annota turni, policy di escalation, regole di notifica e responsabilità.
  • Individua le funzioni e le integrazioni deprecate che vanno sostituite a mano.
  • Aggiorna gli script che chiamano endpoint opsgenie.com o opsgenie.net.
  • Prova avvisi, ripristini, prese in carico e recapito fuori orario.
  • Fai girare vecchio e nuovo percorso in parallelo per almeno un ciclo di reperibilità rappresentativo.
  • Rimuovi il vecchio percorso solo dopo che chi è di turno conferma che il sostituto funziona.

Domande frequenti

Opsgenie viene davvero dismesso?

Sì. Le nuove vendite si sono chiuse il 4 giugno 2025 e il supporto termina il 5 aprile 2027. Atlassian dichiara che a quel punto il prodotto verrà spento e non sarà più accessibile.

Che cosa sostituisce Opsgenie?

Il percorso ufficiale di Atlassian è Jira Service Management, dove stanno confluendo le funzionalità di alerting e reperibilità di Opsgenie. L'alternativa giusta dipende da cosa serve al tuo team: una gestione degli incidenti completa oppure solo un recapito affidabile degli avvisi.

Echobell può sostituire completamente Opsgenie?

No. Echobell sostituisce il livello di notifica urgente sul telefono, nei flussi in cui questo basta. Non riproduce i turni, gli alberi di escalation, i processi di gestione degli incidenti o la reportistica di Opsgenie.

Possiamo usare Echobell durante la migrazione da Opsgenie?

Sì. Punta una fonte di avvisi verso entrambe le destinazioni, verifica il recapito durante un ciclo di reperibilità reale e tieni attivo Opsgenie finché il nuovo percorso non ha dato prova di funzionare.

Quando conviene iniziare a migrare?

Comincia subito con l'inventario e con il test pilota. La data della migrazione definitiva dipende dal numero di integrazioni, dai requisiti di conformità e dal fatto che tu stia passando a Jira Service Management o ridisegnando tutto lo stack di alerting.

Scegli il sostituto più piccolo che copre il lavoro reale

La chiusura di Opsgenie fissa una scadenza netta, ma non significa che a tutti i team serva lo stesso sostituto.

Scegli Jira Service Management se usi Opsgenie come sistema completo di reperibilità e gestione degli incidenti. Valuta un livello di recapito specializzato se i tuoi monitor contengono già la logica di instradamento e il requisito principale è far arrivare in fretta un evento critico sui telefoni giusti.

Scarica Echobell per iPhone oppure scaricalo da Google Play, poi prova un avviso di produzione mentre il tuo percorso Opsgenie attuale è ancora attivo.

Articoli correlati