Hiába állítja le egyes termékeinek támogatását egy adatbázisszoftver-gyártó, az ügyfelek nem rohannak átállni a következő, támogatott verzióra. Helyette inkább fizetik a sokszor borsos kiterjesztett támogatást a szoftver életciklusa végéig. Jó példa erre a Microsoft SQL Server 2019, amelynek a közelmúltban szűnt meg a támogatása, ám a cégek továbbra is inkább használják ezt a verziót, mint utódját, az SQL Server 2022-t.

A hálózaton futó eszközök felderítéséhez és leltározásához megoldást kínáló Lansweeper szerint jelenleg a SQL Serverek 29 százaléka 2019-es verziójú, ezzel szemben a 2022-es kiadás részesedése mindössze 0,1 százalék! Olyan verziók is megelőzik, mint a SQL Server 2008, 2005 és 2008 R2 (utóbbira a Premium Assurance program keretében 2026-ig biztosít kiterjesztett támogatást a gyártó).

Az új verziók bevezetésének azonban csak részben az az oka, hogy az SQL Server 2019-hez egészen 2030 januárjáig lehet vásárolni kiterjesztett támogatást. Esben Dochy, a Lansweeper SecOps evangélistája a konkrét esetet két okkal magyarázta a The Registernek: a 2022-es kiadás lényegesen drágább, és elsősorban olyan új funkciókat kínál, amik csak felhős környezetben hasznosak. Ha pedig az újdonságok között nincs "killer feature", akkor a cégek értelemszerűen úgy érzik: többe kerül a leves, mint a hús.

Hasonlót figyeltek meg szakértők a MySQL esetében. Az 5.7-es verzió támogatását már 2023-ban leállították, mégis az egyik legnépszerűbb verzió. Az ok: az aktuális, 8-as kiadás sem hoz annyi többletet, hogy megérje a váltásba pénzt-energiát ölni.

Üzletmenet-folytonosság vagy naprakészség?

Egy a lapnak nyilatkozó, egyébként nyílt forráskódú projektekben érdekelt szakértő szerint két eset tartja a helyén a régi rendszereket, a kereskedelmi szoftvereket és a nyílt forráskódú megoldásokat (PostgreSQL, MongoDB stb.) egyaránt: vagy túl fontosak, vagy szerepük elhanyagolható az üzletmenet szempontjából.

Az üzletkritikus alkalmazásoknak (a vállalatok éles üzleti adatait tartalmazó adatbázisok jellemzően ilyenek) folyamatosan futniuk kell, frissítésük ezért jelentős üzleti kockázattal jár.

Azokat az alkalmazásokat, melyek az üzletmenet szempontjából érdektelen adatokat kezelnek, rendre kijelölik frissítésre, ám ha nincs valamilyen külső kényszerítő erő (pl. compliance), nem elég fontosak ahhoz, hogy üzleti értelemben érdemes legyen a cseréjükre erőforrásokat pazarolni. Az upgrade ugyanis nemcsak a szoftver frissítését jelenti, az új verzió alá gyakran új a infrastruktúra is kell. Tehát itt valóban nagy az esélye annak, hogy többe kerül a leves...

Ha hosszabb ideig nem merül fel új üzleti igény, akkor szerepet játszik az "ami nem romlott el, ne akard megjavítani" szemlélet. Egy adatbázis esetében az arra alkalmazást fejlesztők számára sem érdekesek az új verzióval érkező funkciók, mert alkalmazásaikat azokra a lehetőségekre építették, melyek fejlesztéskor rendelkezésre álltak.

Mindezek az érvek azonban csak ideig-óráig érvényesek. Jöhetnek olyan (pl. biztonsági) problémák, amik már lényegesen nagyobb kockázatot jelentenek, mint egy upgrade. Másrészt fontos szempont az is, hogy ha egy adatbázis több verzióval elmarad más, hozzá kapcsolódó rendszerektől, az mind az infrastruktúrára, mind pedig az IT-részlegre jelentős terheket róhat.