Megszűnt az SQL Server 2016 támogatása: mi a teendő?

Utoljára frissítve: 2026-09-12  |  Olvasási idő: kb. 11 perc

A Microsoft SQL Server 2016 kiterjesztett támogatása 2026. július 14-én véget ért. Ettől az adatbázis nem áll le, és az üzleti alkalmazások sem válnak egyik napról a másikra használhatatlanná. A működés feltételei viszont megváltoztak: támogatási és biztonsági terv nélkül minden újonnan felfedezett sérülékenység egyre nagyobb üzleti kockázatot jelent. Megmutatjuk, hogyan érdemes józanul dönteni az átmeneti védelem, a verziófrissítés és a hosszabb távú modernizáció között.

Mi változott 2026. július 14-én?

A Microsoft termékei meghatározott támogatási életciklust követnek. Az SQL Server 2016 általános támogatása már 2021-ben lezárult, a kiterjesztett támogatás pedig 2026. július 14-én ért véget. A kiterjesztett időszakban a hangsúly már elsősorban a biztonsági frissítéseken volt; annak lezárása után a normál javítási csatorna is megszűnt.

Ez nem egy technikai „lejárati kapcsoló”. A változás inkább abban áll, hogy a szervezetnek már saját döntéssel kell kezelnie a támogatás nélkül maradó platform kockázatát: fizetett átmeneti védelmet választ, újabb helyszíni verzióra frissít, felhőbe költözik, vagy indokolt esetben rövid ideig kontrolláltan tovább használja a meglévő rendszert.

A támogatás vége nem jelent azonnali leállást

A meglévő adatbázisok, lekérdezések, integrációk és üzleti alkalmazások a támogatás lezárása után is működhetnek. Ezért könnyű azt gondolni, hogy nincs teendő: ha tegnap ment, ma is megy. A probléma általában nem a következő reggelen jelentkezik, hanem akkor, amikor új sérülékenység válik ismertté, kompatibilitási gond merül fel, vagy egy üzletkritikus hiba elhárításához már nincs gyártói támogatás.

A jó döntéshez tehát nem pánik, hanem környezetfelmérés kell. Nem minden SQL Server 2016-ot szükséges ugyanazon a napon lecserélni, de minden ilyen példányhoz kell felelős, dokumentált terv és konkrét határidő.

Milyen kockázatot jelent a további használat?

A támogatás nélküli adatbázis nem automatikusan feltört adatbázis. A kitettség azonban idővel nő, mert az új hibákhoz és támadási módszerekhez már nem érkezik normál gyártói javítás. Egy üzletkritikus rendszerben ennek több oldala van:

• Biztonság: egy később felfedezett sérülékenység tartósan javítatlan maradhat.
• Megfelelőség: auditnál nehezebb indokolni egy támogatáson kívüli komponens használatát.
• Üzemeltetés: egy hiba vagy teljesítményprobléma mögött már nincs teljes körű gyártói segítség.
• Kompatibilitás: az új operációs rendszerek, illesztőprogramok és üzleti alkalmazások egyre kevésbé igazodnak a régi platformhoz.
• Költség: a halogatás technikai adósságot építhet, amely később drágább és kockázatosabb migrációhoz vezet.

Négy reális út az SQL Server 2016 után

1. Frissítés egy támogatott helyszíni SQL Server-verzióra

A legtöbb olyan szervezetnél, amely meg akarja tartani a saját infrastruktúra feletti kontrollt, ez a legkézenfekvőbb hosszú távú irány. Az újabb verzió támogatott biztonsági alapot, hosszabb életciklust és korszerűbb funkciókat ad. A célverziót azonban mindig az üzleti alkalmazások és a gyártói kompatibilitási nyilatkozatok alapján kell kiválasztani.

2. Extended Security Updates mint átmeneti híd

Ha egy kulcsalkalmazás még nem támogat újabb SQL Servert, az ESU időt adhat a tesztelésre és az átállásra. A program legfeljebb három évig, 2029. július 17-ig biztosíthat kritikus biztonsági frissítéseket a jogosult SQL Server 2016 rendszerekhez. Ez nem teljes körű támogatás: nem hoz új funkciókat, általános hibajavításokat vagy korlátlan műszaki segítséget.

Az ESU jogosultsági és beszerzési feltételei telepítési modelltől függnek. Helyszíni vagy más felhőben futó kiszolgálóknál az Azure Arc is része lehet a megoldásnak. Mivel a program költséges és időben korlátozott, csak konkrét migrációs tervvel együtt érdemes alkalmazni.

3. Átköltözés SQL Serverre Azure virtuális gépen

Az Azure VM akkor lehet jó választás, ha az alkalmazásnak továbbra is teljes SQL Server- és operációsrendszer-hozzáférésre van szüksége, de a szervezet csökkentené a saját hardver üzemeltetési terhét. A környezet költözhet jelenlegi állapotában átmeneti ESU-val, vagy az áthelyezés összekapcsolható verziófrissítéssel.

4. Modernizáció Azure SQL Managed Instance-re

A felügyelt adatbázis-szolgáltatás leveszi a szervezetről a hardver és számos platformüzemeltetési feladat terhét. Sok meglévő SQL Server-terhelés viszonylag kevés változtatással átemelhető, de nem minden funkció és környezeti függőség kompatibilis. A hálózatot, a szolgáltatáskorlátokat és a folyamatos felhőköltséget a döntés előtt modellezni kell.

SQL Server 2019, 2022 vagy 2025?

A legújabb verzió nem minden esetben automatikusan a legjobb cél. Egy régebbi üzleti alkalmazás gyártója lehet, hogy SQL Server 2019-et támogat biztosan, míg egy új, hosszú távra tervezett környezetnél a 2022 vagy a 2025 életciklusa nyomhat többet a latban.

A támogatási dátum fontos, de nem dönthet egyedül. A tényleges választás előtt ellenőrizni kell az adatbázis kompatibilitási szintjét, az alkalmazásgyártói támogatást, a használt kiegészítőket, a magas rendelkezésre állási megoldásokat, az operációs rendszert és a teljesítményigényt.

Kell-e mindent egyszerre lecserélni?

Egy SQL Server-frissítés nem jelenti automatikusan a teljes szerverpark cseréjét. Sok környezetben a projekt szakaszolható: először az adatbázis és az alkalmazás kompatibilitását rendezik, majd később következik az operációs rendszer vagy a hardver. Ez csökkentheti az egyszeri projektkockázatot és időben eloszthatja a beruházást.

A szakaszolás csak akkor biztonságos, ha minden köztes állapot támogatott. A Microsoft rendszerkövetelményein túl az üzleti alkalmazás gyártójának feltételeit is ellenőrizni kell. Ami technikailag elindul, nem feltétlenül minősül támogatott üzemi konfigurációnak.

A licencelés nem csak egy termék ára

Az SQL Server költségét nem lehet egyetlen licenc árából megítélni. Számít a kiadás, a fizikai vagy virtuális magok száma, a felhasználók és eszközök köre, a virtualizáció módja, valamint az is, hogy Server + CAL vagy magalapú licencelés illeszkedik-e a környezethez.

Egy kevés, jól azonosítható felhasználót kiszolgáló rendszer és egy sok külső kapcsolatot kezelő szolgáltatás teljesen eltérő konstrukciót kívánhat. Verzióváltáskor a meglévő kiszolgáló- és CAL-jogosultságokat sem szabad automatikusan átvihetőnek tekinteni: a pontos használati jogot a beszerzési dokumentumokkal együtt kell ellenőrizni.

Biztonságos átállás hét lépésben

1. Készíts leltárt: verzió, kiadás, Service Pack, kumulatív frissítés, példányok, adatbázisok, licencek és függőségek.
2. Osztályozd a terheléseket: üzleti kritikusság, adatérzékenység, rendelkezésre állás és helyreállítási célok szerint.
3. Kérj kompatibilitási állásfoglalást: ellenőrizd minden kulcsalkalmazás gyártójánál a támogatott SQL Server-verziókat.
4. Válassz célarchitektúrát és licencmodellt: helyszíni frissítés, Azure VM, Managed Instance vagy időben korlátozott ESU.
5. Építs tesztkörnyezetet: friss mentésből próbáld ki az adatbázisokat, integrációkat, jogosultságokat és ütemezett feladatokat.
6. Mérj és tervezz visszaállást: hasonlítsd össze a teljesítményt, határozd meg az állásidőt, és legyen kipróbált rollback-terv.
7. Dokumentáld az éles átállást: felelősök, időablak, ellenőrzőlista, mentés, utóellenőrzés és a régi rendszer biztonságos kivezetése.

A verzióváltás jó alkalom a régi, már nem használt adatbázisok, belépések és integrációk felülvizsgálatára is. Az adat törlését vagy összevonását azonban csak üzleti jóváhagyással, megfelelő mentés és megőrzési szabályok mellett szabad elvégezni.

Gyors döntési segédlet

Ha még nincs kész leltár és alkalmazás-kompatibilitási lista, ne a verziószámmal kezdd. Előbb azt térképezd fel, mit szolgál ki a jelenlegi SQL Server, meddig kell működnie, és mekkora kiesést visel el a vállalkozás. Ebből már megalapozott műszaki és licencelési döntés születhet.