Ik heb het zelf weer aan den lijve ondervonden. Verhuizen is geen prettige aangelegenheid. Het levert veel stress op, vreet energie en kost vaak meer geld dan van te voren ingecalculeerd. Hoewel ik refereer aan een verhuizing in de privésfeer zijn er toch meer gelijkenissen met een ICT- verhuizing dan je vooraf misschien denkt. Onderstaand enkele tips die kunnen bijdragen aan het succes van een verhuizing. Onderwerp van de verhuizing is een storage omgeving, inclusief de bijbehorende servers en applicaties van een middelgrote organisatie.
Zonder een heldere scope is een verhuizing gedoemd te mislukken. Het moet vooraf goed duidelijk zijn wie, wat, waar, waarom, wanneer en hoe? Inventarisatie is de eerster stap. Wat moet er allemaal verhuisd worden? Waar staat het en wie is er verantwoordelijk voor? Dat zijn vragen die vooraf beantwoord moeten worden. Dit proces wordt vaak nog handmatig uitgevoerd. Op zich niets mis mee. Maar bij grote omgevingen ondoenlijk en tijdrovend. Ook is bij een handmatige inventarisatie de kans op het maken van fouten groter. Dus probeer hier slim mee om te gaan en maak gebruik van tooling en CMDB’s ( mits up to date ).
Hier gaat het echter meestal fout. Er is vaak wel netjes geïnventariseerd wie, wat, waar en wanneer, maar de onderlinge relaties en afhankelijkheden zijn nog wel eens onduidelijk. Levensgevaarlijk natuurlijk. Want hoe kun je iets verhuizen als je niet weet wie en wat er allemaal bij elkaar hoort?
Het is daarom van groot belang om de onderlinge relatie en afhankelijkheden vooraf in kaart te brengen. Welke processen maken gebruik van de bedrijfskritische applicatie? Hoe zijn deze opgebouwd? Wat zijn de afhankelijkheden? Wat is hier voor benodigd? Welke servers en services maken hier gebruik van? Zo kan ik nog wel tig vragen bedenken. Breng deze relaties en afhankelijkheden goed in kaart. Definieer ‘move-groups’ of ‘workloads’. Je ontkomt er gewoon niet aan en je kunt geen zaken los en apart migreren.
Planning en kosten
Zodra de scope en afhankelijkheden geïnventariseerd en vastgesteld zijn kun je beginnen met het opstellen van de planning en het daarbij horende kostenplaatje. Wees niet te ambitieus en plan niet te strak. Hier zie ik het tijdens verhuizingen nog wel eens mis gaan. Natuurlijk snapt iedereen dat je de verhuizing zo snel mogelijk achter de rug wilt hebben maar dit moet niet ten koste gaan van alles. Een te strakke planning levert uiteindelijk alleen maar veel stress, discussie en frustratie op.
Definieer vooraf per fase de kosten. Vergeet hier niet mogelijke aanpassingen op het gebied van hardware, software, netwerk en mensen in op te nemen. En blijf dit dagelijks bewaken. Uit ervaring blijkt dat een verhuizing vaak meer kosten met zich mee brengt dan vooraf verwacht. Laat dit kostenplaatje daarom altijd door een ervaren verhuizer dubbelchecken.
Infrastructuurproblemen
Ook een heikel punt zijn de infrastructuurproblemen. Apparatuur die al een aantal jaar onafgebroken staat te draaien kan soms moeilijk worden aan- en uitgezet. Ook is deze apparatuur over het algemeen wat kwetsbaarder. Het is daarom zaak om voorafgaand aan de verhuizing een goede back-up van de data te hebben. Definieer ook een fail/roll-back scenario. Alleen met een goede back-up ben je er nog niet. Het aanwezig hebben van spare en swing apparatuur is ook cruciaal. Alles wat draait kan een keer stuk gaan dus het is geen overbodige luxe om wat op de plank te hebben liggen of stand-by te hebben staan.
Netwerkverbindingen en andere problematiek
Het fysiek verhuizen van ict-omgevingen heeft nogal wat impact op de netwerkinfrastructuur. Denk hierbij aan netwerk- en internetverbindingen en connectiviteit, DNS, ip,wan, vpn’s en dergelijke. Tijdens de inventarisatiefase moet dit ook goed in kaart gebracht worden. Helaas wordt dit nog wel eens vergeten. Met alle gevolgen van dien.
Bij een verhuizing komt het geregeld voor dat er ook zaken gemigreerd dienen te worden. Dit maakt het vaak nog complexer. Dus probeer het aantal migraties te beperken. Vaak ontkom je er niet aan omdat apparatuur fysiek vervangen dient te worden. Mijn ervaring is dat je beter vooraf aan de verhuizing kan migreren dan tijdens..
Kennis, ervaring en documentatie
Zorg dat er voldoende kennis en ervaring op het gebied van verhuizingen aanwezig is. Is dit nieuw voor de organisatie huur dit dan in. Want verhuizen is en blijft een vak apart. En al doende leert men. Dergelijke kennis kan worden ingehuurd bij ict-partijen (intergrators ) die hier in gespecialiseerd zijn.
Verhuizen is de ultieme manier van het testen van je documentatie. Mijn ervaring is dat de kwaliteit en actualiteit van de documentatie nog wel eens te wensen over laat. En veel kennis nog bij de mensen zelf aanwezig is en niet op papier staat. Hoe voorkom je dit? Definieer een aantal testen. Welke functionaliteiten moeten het doen? Wat zijn onze eisen op basis van performance? Hoe zet ik data terug? En documenteer deze testen vooraf kort en bondig. Te veel informatie zorgt nu eenmaal voor verwarring. Goede en bijgewerkte documentatie is cruciaal bij een verhuizing. Niet alleen vooraf maar ook achteraf. Documenteer ook goed waarom er bepaalde beslissingen gemaakt zijn.
Testen- Fallback scenario
Na iedere stap in je verhuisplan dient er getest te worden. Is alle functionaliteit nog aanwezig? Werkt dit hetzelfde als voor de verhuizing? Dit zijn de twee belangrijkste vragen die je je als projectteam dient af te vragen. Het is daarom zaak om vooraf een goed, duidelijk en functioneel testplan op te stellen. Ook is het van cruciaal belang een fall-back plan/scenario hier in op te nemen. Ervaring leert dat het bij verhuizingen nog wel anders loopt dan als vooraf verwacht. Vaak zie je dan dat er keihard gewerkt wordt om het alsnog voor elkaar te krijgen. Belangrijk daarin is om goed de energie, tijd en kosten van deze inspanning in beeld te houden. En dit wordt juist dan nog wel eens vergeten. Natuurlijk is het van belang om het weer aan de praat te krijgen maar niet tegen alle kosten. Soms is het gemakkelijker en effectiever om gebruik te maken van het fall-back-scenario.
Verhuizen blijft zoals ik al eerder aangaf, een vak apart. Ik ben daarom erg benieuwd naar jullie ervaringen, tips en trucs op het gebied van verhuizen.
@Wim: de grote mainframe verhuizingen deden we altijd in paas- of pinksterweekenden; simpelweg omdat je dan 3 dagen hebt. Kan je net dat beetje extra ademruimte geven.
@ Pavake,
Dit is natuurlijk een goede optie. En geeft wat meer tijd en lucht.
Ook kerst is hier een goede optie voor.
Ruud,
Een leuk stuk waar je het vooral hebt over de uitvoering maar de reden van verhuizing achterwege laat. Verhuizen om het verhuizen is tenslotte een zinloze bezigheid, kost tijd en levert vaak weinig plezier op. Dit geldt ook voor de IT waar soms verhuisd moet worden door reorganisatie, door een te klein of tegenwoordig ook vaak te groot datacenter maar waar de reden niet altijd gecommuniceerd wordt naar de business. En deze blijft vaak niet alleen onveranderlijk zitten maar verwacht voor, tijdens en na de transitie ook gewoon dezelfde service. Hierdoor wordt het achterhalen van eigenaarschap van data, systemen en applicaties soms bemoeilijkt omdat de gebruikers de reden voor het verstrekken van de informatie dus niet zien.
Dat in tegenstelling tot een privé verhuizing waarbij iedereen van het gezin zich vaak ook een beetje verheugd op het nieuwe huis, de nieuwe omgeving en alle andere spannende dingen die erbij komen kijken. Daardoor is de wil om op te ruimen van wat niet meer gebruikt wordt of past dus ook groter om zodoende te voorkomen dat je de dozen van zolder naar zolder verhuisd. Vergelijkend met de verhuizingen die ik prive zelf gedaan heb, van kleiner maar dichter bij het werk naar weer groter, is een service als Shurgard trouwens best wel handig. Het geeft namelijk een keus tussen behouden en afstoten wanneer je bijvoorbeeld die dingen die je niet dagelijks gebruikt, zoals allerlei seizoensgebonden kleding, (sport)artikelen en vele andere dingen, op deze manier opslaat. Als je goed bijhoudt wat waar is opgeslagen en je de opslag handig inricht zodat je niet alles onderste boven hoeft te halen als je voor een week je ski’s of schaatsen nodig hebt is het een win-win situatie. En de dingen die uiteindelijk helemaal niet meer gebruikt worden omdat ze bijvoorbeeld niet meer passen, iets wat nog weleens gebeurt met snel opgroeiende kinderen, kunnen altijd nog op Marktplaats gezet worden.
Om ontopic te blijven zie je in de ICT ook de lifecycle van baby tot bejaarden waarbij mijn ervaring leert dat sommigen nimmer afscheid kunnen nemen van hun ‘kindje’ en je dus lastige situaties krijgt. Bijvoorbeeld wanneer de voortschrijdende ontwikkeling van techniek geen gelijke tred houdt met applicaties of processen en waarover ik in een eerdere opinie: “Oud maar nog niet vervangen” ook al iets schrijf. Vooral de onopgeloste problemen met applicaties zorgen bij een verhuizing dan ook voor hoofdpijn, zeker als je de infrastructuur gelijktijdig wilt moderniseren, consolideren en rationaliseren want afhankelijkheden zitten er op alle lagen van de infrastructuur. Niet alleen in onderlinge communicatie, waarbij sommige applicaties trouwens ‘hardcoded’ adressen gebruiken waardoor omnummering van IP’s of veranderen van MAC-adres voor verrassingen zorgt. Bij een verhuizing kom je ze dan ook altijd weer tegen, de (besturing)systemen en oplossingen die al lang niet meer ondersteund worden maar niet uitgezet kunnen worden.
Omdat een datacenter verhuizing vaak gedaan wordt vanuit een economisch perspectief, IT operations moet vooral goedkoper, zijn het deze ‘constraints’ die altijd weer voor hoofdpijn zorgen. Zoals dat er een dure vleugel verhuisd moet worden waar dochterlief nauwelijks op speelt en dus eigenlijk net zo goed door een handzamer en goedkopere digitale piano vervangen kan worden maar het gevoel uiteindelijk bepalend is. Om dus terug te komen op mijn eerste zin, vergeet niet om de business te betrekken bij een verhuizing als je meerdere doelen hebt binnen deze exercitie. Het kostenplaatje moet dus niet alleen gaan om de verplaatsing maar vooral om de verbetering die echter soms ook nog weleens tegen kan vallen voor de gebruiker wanneer data en systemen op afstand geplaatst worden.
@ Ewout,
Zoals gewoonlijk weer een goede reactie van je. Waar voor dank. Je hebt helemaal gelijk dat verhuizingen politiek gevoelig liggen en vaak ook nog eens emotioneel beladen zijn.
Ik sluit mij aan dat een verhuizing ook iets moet opleveren. Vaak wordt er alleen naar de kosten op de kortere termijn gekeken. En dit levert op langere termijn soms een teleurstelling op.
Eerst alles naar de Cloud verhuizen, dan kun je daarna doen wat je wilt!
Jeffrey,
Bij een verhuizing naar de cloud kom je ook nog veel van de eerder genoemde uitdagingen tegen. En een verhuizing uit de cloud is ook erg tijdrovend aangezien je dan afhankelijk bent van de desbetreffende cloud leverancier en technologieen die hier achter hangen.
In mijn ogen is cloud hier niet het ultimie wondermiddeltje voor. Hoe je went of keert blijft verhuizen altijd lasting.
Ik heb zelf in dit soort trajecten gezeten en herken de meeste zaken. Een onderwerp dat niet wordt aangesneden is het moeten maken van verbeteringen die nodig zijn omdat de situatie anders is. Een voorbeeld is bijvoorbeeld een datacenter waar men vroeger naar toe kon lopen, maar nu op 500 kilometer afstand is. Dit is een trigger voor verbeteringen te maken. Hoe gaat men om met spare-parts? Er zijn ook technologische verbeteringen te maken. Zo hebben wij indertijd wat configuratie veranderingen op Active Directory, Antivirus distributie en het patch-management proces moeten maken om de verhuizing tot een succes te maken. Kortom dit is een behoorlijk complex traject, maar niet ondoenlijk zolang iedereen dezelfde focus heeft.
@ Ruud,
Je haalt een goed punt aan. Waar voor dank!
Spare-parts zijn vaak wel via je leverancier/hardware vendor in te regelen. Maar vaak is het goedkoper om zelf wat spullenboel op de plank te hebben.
@ Ruud M.
als je ze toch op de plank hebt liggen zou ik ze actief opslaan, met andere woorden er een redundant systeem van maken. Spullen die “passief” op de plank liggen zijn stuk op het moment dat je ze activeert, dus wanneer je er spanning op zet.
Maarten,
Dit is afhankelijk van de apparatuur. Maar in veel gevallen gaat dit natuurlijk op. Het is sowieso zaak om de apparatuur zo nu en dan te testen als je er voor kiest om het niet actief in te zetten.