Dieren migreren met een belangrijke reden: het gras is ergens groener en de temperatuur is er beter. Kortom, er zijn betere omstandigheden. Ze doen het dus voor vooruitgang. Helaas geldt vaak niet hetzelfde voor migraties van ongestructureerde data, oftewel content.
Content groeit, er komen steeds meer collaboratieplatformen en ook de gang naar de cloud wordt steeds meer gemaakt. Daardoor zijn migraties van content aan de orde van de dag, maar vooruitgang wordt hierbij niet of nauwelijks geboekt. Vanuit de waarde van de content gezien is er vaak zelfs sprake van achteruitgang.
Het overzetten van content van een of meerdere systemen naar een nieuw doelsysteem wordt veelal gezien als een noodzakelijk kwaad. De migratie is in de regel het eindstation van het implementatietraject. Alles is onder grote druk geïmplementeerd, maar dan moet de migratie nog even. En wat we vaak zien is dat, door uitloop van het project, de migratie dan quick en dirty moet.
Denk vanuit de waarde van content
Waar het mijns inziens mis gaat, is dat er niet gedacht wordt vanuit de content, maar vanuit het nieuwe systeem. ‘Als we het nieuwe SharePoint eenmaal geïmplementeerd hebben, dan is alles veel beter. Hoe de oude content uit ons dms erin komt, en of het erin komt, dat zien we dan wel weer.’ Dat is een verkeerde gedachte. De waarde zit juist in het vinden en hergebruiken van de waardevolle content die de organisatie al die jaren heeft gecreëerd en verzameld. Natuurlijk zijn de nieuwe mogelijkheden van een nieuw systeem belangrijk, maar vergeet de content zelf niet. Ik meen dat migraties een kans zijn om de informatievoorziening te verbeteren!
Migreren is een kunst
Goed migreren is niet iets dat even aan het einde van een project wordt gedaan. Vanaf de keuze voor systeem en inrichting kan ook al over migratie worden nagedacht. Het is verstandig dit direct in een migratiestrategie en plan van aanpak vast te leggen. Analyses op de te migreren content zijn hierbij essentieel, net als kennis van het doelsysteem en de inrichting. Ik zie migratietrajecten vaak misgaan doordat organisaties kiezen voor een van de volgende scenario’s.
Als eerste de ‘lift en shift’. Die ook soms onder de ‘search lost alles op’ categorie valt. Dit betekent kort gezegd dat alle content vanuit het oude naar het nieuwe systeem wordt overgezet zonder daarbij na te denken. Ik heb vele organisaties gezien die dan later toch nog om een analyse en een opschoning van hun nieuwe systeem vragen. Search-specialisten zullen het met me eens zijn als ik zeg dat een eerste selectie op waarde en metadata toevoegen vele malen betere search-resultaten oplevert.
Een andere keuze die wordt gemaakt, is de content volledig negeren en starten met een leeg nieuw systeem. De zogenoemde sterfhuisconstructie. De netwerkschijven blijven daarbij beschikbaar om oude content in te zien en eventueel over te zetten. Deze situatie is verre van ideaal voor eindgebruikers, want zij moeten zoeken in twee omgevingen. Het verlaagt de, toch al altijd zo lastige, acceptatie van de implementatie van een dms of ecm-systeem en maakt de kans van slagen van het implementatieproject zeer klein. Want ook al is de hoeveelheid waardevolle content klein, zorg ervoor dat het over gaat naar het nieuwe systeem, op de juiste manier met de juiste metadata.
Waarde toevoegen. Hoe doe je dat?
Het klinkt makkelijk, alleen de waardevolle content oppakken, de juiste metadata toevoegen en deze content overzetten naar het nieuwe systeem. Makkelijk is het niet altijd, maar mogelijk is het wel. Nu rijst natuurlijk de vraag: ‘Waarde toevoegen, hoe doe je dat?’ Hieronder vier criteria die essentieel zijn om te komen tot een waardevolle set aan content in het doelsysteem:
- Relevantie: Verplaats alleen de relevante en waardevolle content van de oude systemen en omgevingen naar het nieuwe systeem. Regels op metadata als datum gewijzigd, type, grootte, locatie, inhoud, deduplicatie, versieherkenning en classificatie helpen bij het bepalen van wat er daadwerkelijk nog waardevol is. Bij het overzetten van netwerkschijven naar een document management of samenwerkingsomgeving, ken ik vele praktijksituaties waaruit blijkt dat slechts 15 tot 20 procent relevant is voor de nieuwe omgeving.
- Structuur: Zet de content op de juiste plek in de nieuwe structuur. Vaak wordt in een nieuw systeem anders gewerkt; men gaat van afdelingen naar een processtructuur. Gebaseerd op regels en classificatie van inhoud kan via een geautomatiseerde mapping de content op de juiste plek in de nieuwe omgeving terechtkomen.
- Autorisatie: Zorg voor de juiste autorisatie en minimaliseer risico’s op vertrouwelijke zaken die niet openbaar mogen zijn. Maak ook gebruik van bijvoorbeeld herkennen van bsn-nummers, offertenummers bij de analyse om te zorgen dat deze in een beveiligde omgeving van het doelsysteem komen. Denk hierbij ook aan het toevoegen van het juiste retentiebeleid in het nieuwe systeem.
- Metadata: Verrijk de content in het nieuwe systeem met de benodigde gegevens. Vul het metadatamodel in de nieuwe omgeving zoveel mogelijk aan met de juiste waarden. Door middel van auto classificatie (regels op basis van tekst) kunnen de gewenste metadata voor een groot deel goed worden ingevuld.
Wat levert dit nu echt op?
Al die moeite om alleen maar waardevolle content over te zetten, op de juiste plek, met de juiste autorisatie en verrijkt met metadata. Waarom? Wat levert het op:
- Productievere gebruikers. Zoeken gaat gemakkelijk, geen chaos door waardeloze content, juiste versies worden gevonden.
- Compliancy is verzorgd door te kijken naar autorisatie, maar ook door te kijken naar wat wel of niet archiefwaardig is en welke retentie iets zou moeten hebben.
- Kosten zijn minder. Ik zie omgevingen van honderden terrabytes. Dat wil je niet zomaar in de nieuwe SharePoint omgeving zetten. Kosten van storage zijn nog steeds niet uit te vlakken.
Het lijkt allemaal misschien wel voor de hand liggend, maar toch gebeurt het niet. Terwijl de business case duidelijk is en het geen gigantische exercitie betreft. Het is blijkbaar niet duidelijk dat het toevoegen van waarde een controleerbaar onderdeel van een implementatie kan zijn en gigantisch veel oplevert. Mits gebruik wordt gemaakt van een gestandaardiseerde aanpak en slimme tools. Pas dan wordt uw migratie het feest der vooruitgang!
dieren migreren… en laten iets achter (gras, smelly stuff) .
IT migreert… en neemt ‘alles’ mee. (alle data.. etc.)
Als een koe zijn eigen grasveld mee neemt als deze gaat migreren… dan hebben we een vergelijking.
@Paul, wel de eigen ‘s#it’ ook meenemen natuurlijk, ook dat hoort erbij ;O)
Even kijken,
Nuttig artikel omdat hieruit blijkt dat na jaren migratie men er klaarblijkelijk maar niet in lijkt te slagen een gedegen voorbereiding te treffen, (pre-migration) een goede landing, en ik lees dan ook nog eens iets over kosten. (storage), kortom same old s#it die ik twintig jaar geleden ook al ben tegen gekomen, zij het nog commerciëler van opzet, niettemin, same old s#it.
Migratie dient geen kunst te zijn
( bit.ly/1xaIhGP <- gratis, belangeloos, voor goedwerkende IT projecten, processen en disciplines.) IT ICT, alle onderdelen, alle aspecten, die kun je gewoon behandelen, zien als voorspelbare materie. Ook hetgeen je met al die spullenboel en data doet, volkomen voorspelbaar. Immers, alles wat je met, mij om het even, met IT ICT wil dien, ook data, dat dien je gewoon van te voren goed te overdenken, te specificeren, lees, gedegen voor te bereiden. Data migratie een eitje Wat mij verbaast dat dit eigenlijk nog geen eitje is. Je stelt een datum grens, na twee weken laat je data van voor de gestelde data uit het zicht zakken, je luistert naar de geluiden, zo die al komen, en hopla, je bent van minstens 55% oude te migreren data verlost. Natuurlijk, het kan zijn dat er mensen later nog zullen zijn die iets ergens met die oude data wensen. Guess what, genoeg oude hardware meuk over die gewoon nog even apart kan worden geparkeerd met een kopie van en ik heb eerlijk gezegd nooit zoveel klachten gehoord. Na een half jaar draai je de laatste back up en de oud ijzer boer kan en mag komen. Voorbereiden voorbereiden voorbereiden Ik kan dit nog wel honderd keer kopiëren zonder het idee dat co IT ICT pro's zich er iets van aan zullen trekken. Ook in IT ICT migraties draait het allemaal om voorbereidingen en alle elementen voor die voorbereiding zijn al lang aanwezig. Ook checklists voor een migratie, die zijn er al lang dus wie nu nog wielen wil gaan uit vinden, die heeft het dan volgens mij toch echt nog niet helemaal begrepen. Quick & Dirty regelrechte incompetentie. Maar, in alle respect voor alle betrokkenen in migratie land dan natuurlijk.
Sjoerd,
Met de End-of-Sale aankondiging van Google Search Appliance zullen organisaties hun indexeringen moeten converteren, bedrijfs-intranet migreren naar internet lijkt me namelijk te wringen met de EU GDPR die de eerdere vrijblijvende richtlijnen aangaande opslag en verwerking van persoonsgegevens gaat vervangen. En in het rijtje van de waardetoevoeging mis ik dus nog ‘geo-fencing’ want waar alle persoonsgegevens uiteindelijk daadwerkelijk landen is bepalend.
NumoQuest,
De titel is wat verwarrend maar het gaat niet zo zeer om de migratie van de data maar de conversie van de metadata, het verschil tussen gestructureerd en ongestructureerd. Je gebruikelijke verwachtingen leveren met moderne datasynthese namelijk nog weleens wat verrassingen op. Het gaat namelijk niet om het opslaan maar om het vinden.
@WRM
Ik vond de titel niet zo verwarrend eerlijk gezegd en de lading wel dekkend.
Data
Ik beredeneer zaken altijd vanuit een projectmatige kijk en behandeling. In dit geval betekend dit ook dat je er gewoon een pre-migratie project van zult moeten maken om data, in welke vorm, leeftijd, klasse of format, op migratie zult moeten voorbereiden.
In de praktijk zie je vaak een paar dingen gebeuren. Of men roept, ach, dat doen we er tussendoor wel even bij, of men besteed er geen of te laat aandacht aan, of men pakt het issue pas op na de migratie. In alle gevallen ga je achter de feiten aan lopen dan wanneer je het gewoon als pre-migrationeel project behandeld. In dat opzicht wat aandacht betreft: Puntje voor Sjoerd. :O)
NumoQuest,
Er lijkt sprake te zijn van ‘voortschrijdend inzicht’ in je reacties, 13 april 16:00 ging je nog uit van best practice op basis van gebruikelijke ‘check-in-the-box’ afvinklijst welke je nog had liggen van een voorgaand project. In navolgende reactie van 15 april 09:04 breng je opeens het meerwerk in de vorm van een pre-migratie project ter tafel.
Oja, het vinkje van de ‘bewaartermijn’ dient door de business gezet te worden maar wordt veelal vergeten waardoor we een exponentiële groei zien in de datavolumes. Hierdoor dient eerdere afvinklijstje van voorgaande migratie project aangaande doorlooptijd aangepast te worden. Bij groei-op-groei met 20% toename verdubbeld elke 5 jaar het volume en vergeet hierbij niet de back-up welke nog vaak misbruikt wordt voor archivering.
Ja, meten is weten maar laten is praten want migratie kosten zitten veelal niet verwerkt in het TCO model wat de boekhouding hanteert. En hierdoor wordt de projectmatige aanpak vaak een koehandel omdat de business niet wil betalen voor het oude papier in de digitale archieven. Laat ik je zeggen dat ik hierdoor in de praktijk vaak gaten in de Chain of Custody van alle gedigitaliseerde papierstromen tegenkom.
Conversie van metadata gaat om het migreren van je logische pointers naar de data zelf, de data lay-out op tape kent minder differentiaties dan alle gebruikte filesystemen waardoor de opslagkosten van het bonnetje van Teeven €0,001 waren terwijl het vinden ervan meer dan €40.000 kostte;-)
@WMR
Er is een verschil denk ik tussen wat voor mij standard practice is en wat mensen denken dat ik bedoel. Die discrepantie zet ik natuurlijk graag even recht. Noem het voortschrijdend inzicht wat voor mij slechts ‘ verduidelijking’ betreft. Ik vind het om het even op welke manier het onderwerp zelf word benaderd.
Heb je het over ‘ te migreren’ data, dan is het zeker handig een standaard route te bewandelen waarbij je zegt dat je of die data behandeld voor migratie, of na migratie. Natuurlijk het liefst niet op de manier zoals ik eveneens voorgaand aanhaalde. Daar komt altijd ellende van namelijk.
Chain of custody
Let op, ik heb geen mening over wie op welk moment en op welke wijze die stappen zet of welke methodiek er zou worden gebruikt. Het migreren van die pointers zul je gewoon, maar dat geld voor elke stap in en met IT ICT, gewoon goed moeten overdenken en voorbereiden uiteraard. Het gaat mij, en ook Sjoerd uiteraard, dat je alle onderdelen en stappen van en voor een migratie gewoon goed overdenkt en voorbereid.
Kosten van migratie en TCO
Vanuit mijn ervaren is het vaak zo dat bij migratie een nieuw budget word geformeerd omdat het ondoenlijk is om kosten van een migratie op voorhand te berekenen. Begrijpelijk. Dat betekend in de praktijk gewoon dat een migratie gewoon een IT ICT programma dient te worden waarbij kan worden bekeken welke disciplines/onderdelen tezamen kunnen worden geschoven en gemigreerd en welke, vanwege volume of importantie, als project moeten worden ondergebracht. (opinie RC)
Hoe het ook zij, een migratie dient heden ten dage gewoon een standaard exercitie te zijn maar, even terugverwijzend naar jouw opmerking ‘ …vaak gaten in de Chain of Custody …’
dat ook steeds vaker gaten in de hele IT chain betreft. Een gewoon verlies van kwaliteit dus, iets waar ik al jaren voor waarschuw.
Als er al iets een perfect en meetbaar middel is dat is het IT ICT wel, wat mij betreft. Tenminste, mits goed geregeld. ;O)