In 2010 heb ik een artikel geschreven met de titel ‘Migreren is vooruitzien’. Ogenschijnlijk is er in de afgelopen vier jaar weinig veranderd. Of misschien toch wel? Onderstaand een update.
In 2010 heb ik een artikel geschreven met de titel ‘Migreren is vooruitzien’ . We zijn nu een viertal jaren verder en tot mijn spijt moet ik vaststellen dat ik eigenlijk de tekst van dat artikel bijna in het geheel kan hergebruiken. Ik moet alleen Windows Server 2000 vervangen door Windows Server 2003/R2 en dan klopt het allemaal weer. O ja, datum is deze keer niet 13 juli, maar 14 juli en dan natuurlijk in het jaar 2015.
‘Is er dan helemaal niets veranderd? De omstandigheden, knelpunten en hete hangijzers waren er vier jaar geleden ook.’ Maar vier jaar heeft wel degelijk een verandering gebracht, deze keer komen er twee aspecten veel sterker om de hoek kijken: security en compliancy. Natuurlijk was dat ook in 2010 al relevant maar vandaag de dag is dit veel sterker geworden. Bedrijven worden steeds strenger gecontroleerd en moeten aantoonbaar hun security en compliancy op orde hebben.
Applicaties die op Windows Server 2003 /R2 draaien zullen op 15 juli 2015 met één klap op een niet meer ondersteund operating system (os) draaien. En als het os niet meer ondersteund wordt, vervalt vaak ook de garantie van de leverancier van de applicatie. En dan is de compliancy ook zoek.
Natuurlijk kan er extra support voor het os gekocht worden, maar dat is een dure pleister op de wond en het helpt hooguit een beetje de pijn te verlichten. Of dit ook weer helpt om compliant te worden, is maar de vraag. Daarnaast is deze oplossing maar van korte duur. Uiteindelijk vervalt ook deze vorm van support. En dan moet alsnog de volgende stap worden genomen: migreren.
Optie
De enige echte optie is: Migreren. Dat klinkt eenvoudig, maar is het in veel gevallen niet. Er komen allerlei vragen naar voren: welke applicaties draaien nog op Server 2003, kunnen die op een hogere versie van Windows (liefst Server 2012 R2), hoe zit het met de overgang van 32-bit naar 64-bit, moet de applicatie ook nog naar een nieuwere versie met eventueel bijbehorende conversies van databases en applicatiebestanden, nieuwe packages voor de client-applicaties, et cetera, et cetera.
Het proces om het besturingssysteem onder de bedrijfsapplicaties te vernieuwen bestaat uit een aantal stappen. Allereerst moet er uitgezocht worden om welke applicaties het gaat. Daarna moet er bepaald worden wat de typering van de applicatie is; bijvoorbeeld: bedrijfskritisch, overbodig, complex, eenvoudig, et cetera. Vervolgens moet er bepaald worden wat er met de applicatie gedaan moet worden. Immers nu is het moment heel geschikt om een heroverweging te doen: op een nieuwere versie van het os laten draaien, of meteen een upgrade van de applicatie zelf doen?
Zouden we de applicatie wellicht in de cloud kunnen plaatsen? Of misschien helemaal vervangen door een totaal andere applicatie of dienst van een andere leverancier? Op basis van de antwoorden op bovenstaande (en andere) vragen kan er een plan gemaakt worden hoe de migratie aangepakt kan worden en hoeveel effort hiermee gemoeid is. En dan moet de migratie natuurlijk ook nog worden uitgevoerd.
Als dan na deze migraties de zaak weer op orde is, hoe zorgen we er dan voor dat dit ook zo blijft? Met de komst van de cloud (private, public of hybride) zijn er een heleboel opties bijgekomen en is het eigenlijk alleen maar complexer geworden. Des te belangrijker is het om dit strak te organiseren en heldere afspraken te maken omtrent de verantwoordelijkheden van de business en IT.
Heel veel succes (en sterkte) gewenst met de komende projecten!
Beste naamgenoot,
Migreren is vooruitzien en de wetmatigheden en regels van vier jaar geleden, acht jaar geleden, twaalf en zestien jaar geleden zijn nog net zo valide als nu. Of dat vreemd is? Nee hoor. Als je weet hoe je de onderliggende standaard beschrijft is elke migratie uiteindelijk hetzelfde trucje. Alleen de kleur en volume kunnen dan nog wel eens verschillen.
Grappige constatering nietwaar?