Wat is een upgrade package bij managed services?

Een upgrade package is een vooraf afgebakend pakket voor de versie-upgrade van een data-omgeving, met een vaste prijs per onderdeel en een vast programma dat risico’s stap voor stap opspoort voordat ze de productieomgeving bereiken. Regelmatig upgraden is geen kwestie van willen maar van moeten: verouderde versies van Qlik Sense (client-managed), erwin Data Modeler of Talend, en van de drivers en connectors waarmee pipelines op Snowflake aansluiten, verliezen ondersteuning, security-patches en compatibiliteit met nieuwe koppelingen. Wie te lang wacht, upgradet uiteindelijk toch, maar dan onder tijdsdruk en met meer risico.

Waarom upgraden zo vaak wordt uitgesteld

Ik merk dat organisaties upgrades zelden uitstellen uit onwil. Meestal is het onzekerheid over de kosten en de impact. Een upgrade raakt zelden één systeem: een nieuwe Snowflake-connector raakt de ETL-pipelines, een Talend-upgrade de Remote Engine of de Runtime, een Qlik-upgrade dashboards die al jaren ongewijzigd draaien.

Daarnaast wordt vaak gewacht op het perfecte moment. Dat moment komt niet, want er loopt altijd een rapportagecyclus, een piekperiode of een project dat niet onderbroken mag worden. Een upgrade die vooraf gepland en gefaseerd is, lost ook dat op: de planning houdt vanaf het begin rekening met de organisatie, in plaats van te wachten op een rustige periode die nooit komt.

Vaste pakketten, vaste prijzen

Bij cimt Managed Services zijn upgrades afgebakende pakketten met een vaste prijs per onderdeel: het platform zelf, de onderliggende pipelines, de koppelingen en de dashboards of rapportages die ervan afhangen. Bij een integratielaag op Talend betekent dat bijvoorbeeld een aparte prijs voor Studio, de Runtime en de Remote Engine, elk met een eigen impact en testtraject. Zo zijn de kosten van een volledige upgradecyclus vooraf duidelijk, in plaats van een afrekening op uurbasis die pas achteraf zichtbaar wordt.

Een vast programma, stap voor stap

Naast de vaste prijzen werkt cimt met een vast upgradeprogramma dat risico’s zo vroeg mogelijk zichtbaar maakt. Elke omgeving in de OTAP-straat (ontwikkeling, test, acceptatie, productie) wordt na de upgrade eerst getest en draait daarna een periode mee, bijvoorbeeld een week, voordat de volgende omgeving aan de beurt is. Duikt er een probleem op, dan wordt het opgelost in de omgeving waar het ontstond, en niet doorgeschoven naar productie. Zo ziet zo’n programma er in de tijd uit:

Elke upgrade staat aan het begin van de week gepland, zodat de omgeving de rest van die week meedraait voordat de volgende fase start. De week zonder upgrade na DEV-ESB-01 is geen vertraging maar extra monitoringtijd: de eerste geüpgradede omgeving draait langer door, en pas als daar niets uit naar boven komt, gaat de testomgeving aan de beurt. Aan het eind blijft productie nog een week onder extra toezicht draaien.

Wat dit oplevert

Het doel is niet alleen een geslaagde upgrade, maar een upgrade waarvan de kosten en de planning vooraf vaststaan en waarbij een probleem in test nooit een verrassing in productie wordt. Dat is het verschil tussen upgraden als brandjes blussen en upgraden als vast onderdeel van het beheer. Een upgrade package staat los van een SLA voor de data-omgeving of een retainer, maar sluit er goed op aan: de SLA regelt het dagelijkse beheer, het upgrade package de geplande sprong naar een nieuwe versie.

Wilt u weten wat een upgrade package voor uw data-omgeving betekent? Neem contact op, dan brengen we samen in kaart welke onderdelen een upgrade raakt.