1 25/05/2026 8 min

Fine supporto: il punto non è “se”, è “quanto costa restare fermi”

Quando un’infrastruttura continua a usare SCCM 2007 e FEP 2010, il problema non è solo la mancanza di patch. Il problema vero è che si resta agganciati a un modello operativo vecchio: agenti, console, distribuzione software, policy di sicurezza e reporting finiscono per dipendere da componenti che non ricevono più correzioni né aggiornamenti di compatibilità. In pratica, ogni mese in più aumenta il rischio tecnico e diminuisce la libertà di cambiare il resto dell’ambiente.

La domanda utile non è “posso tenerli ancora un po’?”, ma “quali funzioni sto ancora affidando a questi prodotti e quali alternative ho già disponibili?”. Se la risposta è vaga, è il segnale che la piattaforma è diventata un punto cieco: si usa perché esiste, non perché sia ancora una scelta difendibile.

Cosa significa davvero fine supporto per SCCM 2007 e FEP 2010

Fine supporto vuol dire che non ci si può aspettare correzioni di sicurezza, fix di bug, supporto ufficiale su nuove versioni di sistemi operativi e, spesso, nemmeno compatibilità affidabile con i cambiamenti dell’ecosistema Microsoft e dei prodotti terzi. Non è un dettaglio amministrativo: è una perdita concreta di affidabilità operativa.

Per SCCM 2007 il tema è ancora più evidente perché il prodotto vive in un contesto dove cambiano spesso client, OS, prerequisiti di distribuzione e aspettative di gestione centralizzata. Per FEP 2010 il discorso è simile: la protezione endpoint basata su un motore vecchio diventa un punto debole sia sul piano della sicurezza sia su quello della gestione. Anche quando “funziona”, non è detto che stia lavorando bene nel contesto attuale.

Il rischio reale: non solo sicurezza, ma anche operatività

Il rischio più facile da capire è la sicurezza: nessuna patch, nessuna correzione nota, nessun ciclo di hardening aggiornato. Ma nella pratica quotidiana spesso pesa di più il rischio operativo. Un sistema fuori supporto tende a creare attrito su quattro fronti: inventario impreciso, distribuzione software fragile, integrazioni che saltano e troubleshooting più lento perché mancano strumenti moderni e log più chiari.

Il risultato è quasi sempre lo stesso: il team IT passa più tempo a tenere in piedi una catena fragile che a migliorare il servizio. E quando si arriva a una migrazione sotto pressione, tutto costa di più: tempo, test, finestre di manutenzione e rischio di errore umano.

Prima mossa: fotografare l’uso reale, non la documentazione vecchia

La migrazione va impostata partendo da ciò che il sistema fa davvero oggi. Molti ambienti hanno installazioni nate per un obiettivo iniziale e poi cresciute per accumulo: pacchetti software, baseline di sicurezza, task di inventario, distribuzioni di driver, raccolta eventi, protezione endpoint, query di reporting. Se non si separano le funzioni, si rischia di migrare il nome del prodotto senza migrare il servizio che eroga.

La verifica utile è semplice: elenco delle feature effettivamente usate, numero di client coinvolti, siti/collegamenti, dipendenze su SQL, ruoli di server e integrazioni con AD o con strumenti esterni. Se non hai già questi dati, il gap va chiuso con una raccolta puntuale da console, log e configurazioni esportate, non con supposizioni.

Un controllo pratico è esportare la configurazione disponibile e confrontarla con gli oggetti ancora attivi. Nei sistemi legacy spesso emergono oggetti orfani, collezioni non più usate e task rimasti accesi per abitudine. Quello è materiale da riduzione del perimetro, non da portare in avanti.

Strategia corretta: contenere, migrare, dismettere

La sequenza giusta non è “spengo tutto e rifaccio da capo”. Prima si contiene il rischio, poi si migra per blocchi, infine si dismette. Questo approccio vale sia per SCCM 2007 sia per FEP 2010, perché in entrambi i casi il problema non è solo la sostituzione del software, ma la continuità dei processi che vi girano intorno.

Contenere significa ridurre l’esposizione: limitare accessi amministrativi, separare i server legacy dalla rete più ampia, verificare backup, controllare la presenza di account di servizio con privilegi eccessivi, e congelare ogni change non essenziale. Migrare per blocchi significa portare prima le funzioni meno rischiose e più standardizzabili. Dismettere significa spegnere davvero i componenti rimasti inutili, dopo aver verificato che non servano più a nessun processo.

Come leggere il perimetro tecnico prima di scegliere la destinazione

La scelta della piattaforma sostitutiva dipende dal ruolo che SCCM e FEP svolgevano nel tuo ambiente. Se SCCM 2007 era usato soprattutto per deployment software e inventario, la migrazione può puntare a una versione moderna della stessa famiglia o a strumenti diversi, a seconda della maturità del parco client. Se FEP 2010 era il motore di protezione endpoint, la scelta va valutata insieme alla strategia di sicurezza complessiva, non come semplice upgrade di versione.

Qui il punto critico è non confondere compatibilità tecnica con sostenibilità. Un prodotto può anche essere installabile in un laboratorio, ma questo non significa che sia una buona base per un ambiente con compliance, auditing, segmentazione e requisiti di risposta agli incidenti. La destinazione va valutata con criteri di gestione, telemetria, aggiornamento e supporto del vendor, non solo con il test di installazione.

Le domande da farsi prima di toccare un client

Prima di iniziare la migrazione, conviene rispondere a una serie di domande molto concrete. Quanti client dipendono ancora dai vecchi agenti? Esistono sistemi critici che non possono essere toccati subito? Quali pacchetti software vengono distribuiti da SCCM e quali possono essere spostati su altri canali? FEP 2010 è usato solo come antivirus o anche come parte di una policy più ampia di endpoint security?

Se manca una risposta, non si inventa. Si chiude il gap con un inventario verificabile: console, report, query sul database, esportazioni di policy e controllo dei gruppi di appartenenza. Nei passaggi delicati, il dato manca quasi sempre perché nessuno l’ha mai reso esplicito, non perché non esista.

Una migrazione sensata parte dai controlli, non dal software

Prima di cambiare piattaforma, è utile definire i controlli minimi che devono restare veri dopo il passaggio: inventario aggiornato, distribuzione affidabile, gestione patch, protezione endpoint, reportistica, audit e capacità di rollback. Se un requisito non è misurabile, non è ancora un requisito operativo.

Per esempio, se oggi usi SCCM per distribuire software, il controllo non è “il pacchetto parte”. Il controllo è: il pacchetto raggiunge il target giusto, fallisce in modo tracciabile quando non può essere applicato, e lascia log consultabili senza interventi manuali eccessivi. Lo stesso vale per la protezione endpoint: non basta “l’icona verde”, serve sapere se i client ricevono definizioni, policy e aggiornamenti con continuità.

Un piano pratico di uscita: blocchi piccoli, verifiche rapide

Un piano efficace si può leggere in tre fasi. Prima si mette in sicurezza l’esistente: backup, snapshot se supportati, esportazione configurazioni, verifica spazio disco, controllo account di servizio e revisione dei permessi amministrativi. Poi si crea un ambiente nuovo in parallelo, con una funzione alla volta. Infine si spostano i client in modo progressivo, con finestre di osservazione e criteri di stop chiari.

La regola utile è semplice: ogni blocco migrato deve essere verificabile in autonomia. Se il nuovo sistema gestisce inventario, bisogna vedere un campione di client comparire con dati coerenti. Se gestisce distribuzione software, bisogna validare almeno un pacchetto standard e uno più delicato. Se gestisce endpoint protection, bisogna verificare aggiornamenti, stato del servizio e report di conformità.

Perché la fretta è il modo migliore per fare danni

In questi progetti la fretta produce due errori tipici. Il primo è migrare senza capire cosa stia davvero facendo il sistema legacy, e ritrovarsi con funzioni dimenticate che saltano settimane dopo. Il secondo è lasciare il vecchio in parallelo troppo a lungo, trasformando la migrazione in un doppio carico operativo che consuma tempo e fiducia.

Il punto di equilibrio è mantenere il vecchio solo finché serve come rete di sicurezza, ma con una scadenza precisa. Se non c’è una data di dismissione, il sistema legacy tende a sopravvivere per inerzia. E quando un’infrastruttura sopravvive per inerzia, di solito lo fa perché nessuno vuole essere il primo a prendersi la responsabilità di spegnerla.

Che cosa fare subito se SCCM 2007 o FEP 2010 sono ancora in produzione

La priorità operativa è tripla: ridurre il rischio, misurare l’esposizione, pianificare la rimozione. Ridurre il rischio significa limitare chi può amministrare questi sistemi e verificare che backup e restore siano ancora validi. Misurare l’esposizione significa sapere quanti endpoint, server e processi dipendono ancora da loro. Pianificare la rimozione significa fissare una roadmap con date, responsabilità e criteri di completamento.

Se il sistema è ancora esposto oltre il minimo necessario, il primo intervento non è l’upgrade: è la riduzione della superficie operativa. Meno accessi, meno dipendenze, meno componenti attivi. Poi si lavora sulla sostituzione.

Segnali che la migrazione è stata davvero completata

La migrazione non è finita quando il nuovo sistema è installato. È finita quando il vecchio non serve più a nessun flusso produttivo, quando i client sono stati riallineati, quando i report mostrano il nuovo stato e quando i team operativi non si appoggiano più al vecchio per emergenza o abitudine.

Un buon indicatore è la scomparsa delle eccezioni: se ogni volta che qualcosa non torna si finisce ancora a consultare SCCM 2007 o FEP 2010, allora la dipendenza non è stata recisa. Il vecchio sistema può anche essere spento, ma se resta mentalmente nel processo, il lavoro non è chiuso.

La lezione pratica

Il fine supporto di SCCM 2007 e FEP 2010 non va letto come una notizia di calendario, ma come un promemoria architetturale: le piattaforme di gestione e sicurezza non possono restare ferme mentre il resto dell’ambiente cambia. Ogni mese di ritardo aumenta il costo della migrazione e riduce la qualità del controllo. La scelta migliore è trattare il legacy come un progetto di uscita, non come un servizio da tenere acceso finché regge.