SharePoint

Migreren naar SharePoint 2013

27 mei 2013

Deze blog focust niet op de technische uitdagingen van een migratie naar SharePoint 2013, maar meer het organisatorische deel. Vaak zie je dat migraties worden onderschat. Deels heeft dit er mee te maken dat een migratie wordt ingeschat als een technische exercitie. Het bron systeem waar vandaan wordt gemigreerd maakt in dezen zeker een verschil. Al sinds 2009 houd ik me intensief bezig met voornamelijk Open Text Livelink tm naar SharePoint migraties. Later zijn daar ook shared drives, oudere versie van SharePoint en andere systemen als bron bijgekomen. Ze hebben allen een verrassende valkuil: een focus op tooling, in plaats van een focus op de organisatie.

thinking

Migreren met een oudere SharePoint versie als bron

Als het bron systeem een oudere versie van SharePoint is (2010, 2007) dan maakt dit het organisatorisch iets gemakkelijker. Vaak wordt dan ook het woord “migreren” vervangen door “upgraden”.

De eerste vraag die langskomt als een nieuwe versie van SharePoint beschikbaar komt is: waarom zouden wij upgraden? Met andere woorden: wat levert het de organisatie op als we gaan upgraden? Wat is de vraag vanuit de organisatie? Welk soort migratie/upgrade je ook uitvoert, je krijgt te maken met de gehele organisatie. Het is daarom belangrijk om vanaf het begin alle betrokkenen goed te informeren en bij het project te betrekken. Om de juiste betrokkenheid te krijgen zal je het stuur aan ‘de business’ moeten geven, plaats hem en haar in de ‘driver seat’.

Het grote voordeel van migreren vanuit een andere SharePoint versie is dat gebruikers al redelijk op de hoogte zijn van SharePoint terminologie en (on)hebbelijkheden. Ook autorisatie en authenticatie blijft vrijwel hetzelfde. Toch loop je ook tegen zaken aan die anders zullen zijn. Denk hierbij aan de introductie van de Term Store en dergelijke nieuwe functionaliteiten. Vaak zie je ook dat een migratie/upgrade het moment is waarop gebruikers gaan nadenken over taxonomie en informatie architectuur. Met andere woorden: men pakt het momentum om schoon schip te maken.

Overigens, bij het upgraden van SharePoint is de enige door Microsoft zelf ondersteunde methode het upgraden naar een volgende versie. Als je versies wilt overslaan heb je andere tooling nodig. Ook als je bijvoorbeeld van 2010 naar 2013 wilt blijven er nog genoeg technische uitdagingen over: denk hierbij bijvoorbeeld aan maatwerk. Samenvattend: voor een SharePoint upgrade, onderschat de impact niet. Benader het als een project en zorg voor een goede project manager.

Migreren vanuit een ander systeem

Door de jaren heen heb ik te maken gehad met diverse migraties, hetzij van shared drives en Outlook public folders tot en met Open Text Livelink tm document management systemen met vele miljoenen documenten en andere informatie. Ze hebben een aantal overeenkomende zaken:

[listdot]

  • Het vinden van content owners kan lastig zijn
  • Er is niet altijd urgentie vanuit de organisatie (wat we nu hebben werkt toch prima?)
  • Vanwege de verschillen in systemen krijg je gegarandeerd discussies over bijvoorbeeld taxonomieën en permissies.
  • Maatwerk migreren kost tijd
  • De gebruiker moet significant tijd investeren

[/listdot]

Voor het migreren vanuit een ‘ander’ systeem is in de meeste gevallen tooling nodig. Echter, ik ben in een aantal gevallen ook betrokken geweest bij zogenaamde self service migraties. Deze komen neer op het aankondigen van het afsluiten van het oude systeem binnen een bepaalde tijd en eventueel het aanbieden van self service tooling. Hoe de migratie ook gedaan wordt, uiteindelijk blijkt tooling slechts 20-30% van het project te zijn.

Het 1-op-1 migreren vanuit een ander systeem is meestal een minder goed idee. Als je bijvoorbeeld gaat migreren vanaf een shared drive naar SharePoint en je neemt de shared drive 1-op-1 over kom je minimaal een aantal technische limieten tegen. Daarnaast win je niets, en heeft een migratie dus eigenlijk niet zo veel zin.

Migratie ‘readiness’

Het beginnen met een migratie blijkt vaak lastig: men ziet vaak op tegen de berg aan de horizon. Uiteindelijk is het een kwestie van inventariseren wat er is, analyseren wat de probleem gebieden zijn en uiteindelijk: beginnen! Zeker zullen de leeuwen en beren op de weg langskomen, maar zonder te starten kun je ze niet overwinnen. Denk goed na over hoe je nu werkt met metadata, hoe de taxonomie eruit ziet, welke structuur en hiërarchie er is en welke mensen nodig zijn om dit tot een succes te maken. Welk maatwerk is er in huis, en is hiervan de bron code aanwezig, of ben je aangewezen op een externe partij? Na alle afwegingen kun je de beslissing nemen of de organisatie klaar is om te migreren. Hierbij is het aan te bevelen een interne project manager aan te stellen die de organisatie en haar mensen goed kent. Als je een migratie uitbesteed aan een externe partij let er dan goed op dat je goede afspraken maakt over wie welk onderdeel oppakt. Doet de externe partij bijvoorbeeld ook alle interne communicatie of houd je dat liever in eigen beheer? Maak ook duidelijke afspraken met betrekking tot de planning. Let bij het kiezen van de leverancier of hij kennis heeft van zowel het bron als het doel systeem. Dit is essentieel, ook om met de gebruikers te kunnen communiceren over de verschillen.

Van wie is de content

In veel migratie projecten is het lastig te bepalen van wie content nu eigenlijk is. Dat klinkt vreemd, maar als je miljoenen documenten en andere informatie in ogenschouw neemt wat soms door de jaren heen is opgebouwd, is het minder vreemd. In het algemeen is het aan te bevelen om duidelijk af te spreken van wie de content is. Zeker in geografisch gespreide organisaties kan het tijd kosten om uit te vinden van wie content is. Je zult de content owner toch nodig hebben om te bepalen wat er met zijn of haar content moet gebeuren. Het ‘zomaar’ overzetten is meestal geen optie, zeker niet als je migreert vanuit een ander systeem. De meest gestelde vraag is: kunnen we permissies ook migreren? Het antwoord is ‘ja, maar’. Meestal wijken permissie modellen zodanig af dat je direct een chaos creëert in SharePoint. Om te voorkomen dat je ongewenst documenten publiceert die niet mogen worden gepubliceerd heb je dus echt de content owner nodig. In het geval dat de content owner inmiddels de organisatie heeft verlaten laat je het management een nieuwe content owner ‘aanwijzen’.

Organisatorische impact

De impact op de organisatie zit voornamelijk in de tijdsbesteding van de diverse afdelingen en bedrijfsonderdelen. In overleg zullen zij moeten nadenken over bijvoorbeeld nieuwe permissie modellen, mapping van content, nieuwe metadata, navigatie etc. Daarnaast krijgt de organisatie natuurlijk een nieuwe systeem, dan wel een nieuwe versie van SharePoint. Al met al heeft een migratie een behoorlijke impact op de organisatie.

Tooling

Is tooling dan onbelangrijk geworden? Zeker niet, maar het is niet het enige wat er toe doet. Afhankelijk van het soort migratie (of upgrade) is tooling al dan niet noodzakelijk. In een volgende blog wil ik zeker nog eens op tooling en gebruik ervan in migratie projecten, in gaan.

Tot slot

Heb je vragen, opmerkingen, commentaar, kritiek of wil je gewoon eens van gedachten wisselen maak dan gebruik van onderstaande reactie mogelijkheid of gebruik twitter.com/thelivingstoneg

You Might Also Like

1 reactie

Plaats een reactie