Het migreren van Microsoft Sharepoint 2007 naar de nieuwere versie van de samenwerkingssoftware is een grote uitdaging. Dat zeggen ervaringsdeskundigen. Doordat bedrijven veel extra functionaliteiten aan hun Sharepoint-omgeving hebben toegevoegd, wordt de migratie van 2007 naar de nieuwste versie bemoeilijkt.
‘Als je migreert vanuit een kale Sharepoint-omgeving is de migratie binnen een paar uur klaar', zegt technisch directeur Danny Burlage van dienstverlener Wortell. ‘Maar de afgelopen jaren is er niet altijd nagedacht over de structuur van de omgeving en er is veel maatwerk toegevoegd. Voor bedrijven met een dergelijke omgeving is het verstandiger om opnieuw te beginnen.'
Het gaat dan om de toevoeging van extra componenten. ‘Eigenlijk is Sharepoint niet meer dan een document management tool', zegt adviseur Erik Hartman van Hartman Communicatie. ‘Maar bedrijven gebruiken het voor records management of als web management tool. Daarom hebben zij allemaal extra modules aan de software toegevoegd.'
Management consultant Michiel Hazen van Ordina denkt dat bedrijven vooral de eerste twee jaar na de introductie van Sharepoint 2007 veel extra functionaliteiten hebben toegevoegd. ‘In 2008 en 2009 hebben de ervaren dienstverleners ingezien dat ze het product als uitgangspunt moesten nemen. Toen is er beter nagedacht over het toevoegen van de functionaliteiten.'
Extra modules
Een van de problemen waar bedrijven tegenaan lopen is dat de extra modules zijn gemaakt in 32-bit. Sharepoint 2010 ondersteunt echter alleen maar 64-bit modules, zegt Burlage van Wortell. ‘Deze maatwerkfunctionaliteiten moeten daarom opnieuw worden geprogrammeerd.'
Hazen denkt dat het merendeel van de bedrijven kiest voor een schone installatie van Sharepoint 2010 en daar later de content opnieuw inzetten. Dat is ook de ervaring van Burlage. 'Van de veertien bèta-projecten die wij uitvoeren, zijn acht projecten een compleet nieuwe installatie.'
ICT-er, er komen verschillende versies van SharePoint 2010. SharePOint Server 2010 is vergelijkbaar met het huidige MOSS. SharePoint Foundation 2010 is het huidige WSS.
Over je andere opmerking: Het zijn nuances.
Met IBM Domino / IBM Quickr heb je dit gezeur niet. Scheelt je overigens ook in het aantal servers dat je nodig hebt en de licentie kosten.
Een aantal punten.
Naar mijn idee biedt SharePoint 2007 OOTB te weinig functionaliteit, vandaar dat je al snel aan custom development toe komt. Volgens mij heeft MS SharePoint 2007 ook altijd gepositioneerd als platform en niet als product an sich.
De opmerking van Hartman dat SharePoint eigenlijk alleen document management is, is veel te kortzichtig. Iedereen zal zich de ‘pie’ met de 6 taartpunten herinneren waar Portal, Search, CM, Business forms en BI naast Collaboration geplaatst zijn. (Zo niet dan kun je hem hier nog eens bekijken: http://www.infoworld.com/infoworld/img/33TCmoss1_lg.jpg) Bedrijven die SharePoint alleen als veredelde fileshare tool gebruikt hebben, hebben veel laten liggen (maar zijn nu overigens wel goed uit met deze migratie)
Als laatste, hebben we niets geleerd van de SP2003 naar SP2007 migraties? Eigenlijk wel onbegrijpelijk dat deze nieuwe upgrade weer een drama moet/gaat worden. Een nieuwe omgeving naast de oude plaatsen is leuk voor kleine bedrijven, heb je je global organisatie op SharePoint 2007 draaien en tienduizenden gebruikers of meer, dan is deze ‘oplossing’ niet te betalen. Hopelijk zijn er bedrijven die migratietools/ondersteuning gaan bieden, of komt MS zelf met hulpmiddelen?
Omdat een aantal reacties mij zo “kort door de bocht” vonden, hier een nuance. Ik ben niet geheel (correct) geciteerd.
Ik heb niet beweerd dat MS Sharepoint een document management tool is. Want in mijn ogen is het in de basis – naast een framework – niet meer dan een document collaboration omgeving. Het is in de basis zeker geen document management systeem (DMS). Ik realiseer mij dat ik nu in de ogen van deze reageerders nóg korter door de bocht ga. Nou ja, hier komt dan de nuance.
Vervolgens heb ik uitgelegd dat allerlei externe partijen in ‘het gat’ zijn gedoken van verwachtingen die in de markt leefden over wat er allemaal met MS Sharepoint zou kunnen. Denk aan Web Content Management – al zie ik de ontwikkeling te langzaam gaan in vergelijking met wat ‘pure’ CMS-en kunnen – en zelfs records management. Ik heb zelfs al gelezen dat men DITA met Sharepoint wil ondersteunen.
Nu zie ik in Sharepoint heel veel van die functionaliteiten van ’third parties’ terugkomen in 2010. Denk bijvoorbeeld aan de veel krachtiger manier waarop de 2010-versie met metadata en taxonomieën omgaat.
Desondanks gaat het mij te ver om MS Sharepoint als een tool voor Web Content Management, Document Management of wat voor andere manier van informatiemanagement dan ook te zien. Het is een toolkit met document collaboration functionaliteit. Ja, je kunt op zo’n framework van alles bouwen, zoals met bijvoorbeeld Plone.
Maar je komt al snel met dit soort frameworks in de problemen als er een nieuwe release komt en je zit als gebruiker met maatwerk van ’third parties’. Voor zover ik het kan zien, zijn alle reageerders het op dit punt met mij eens zijn. En dat was nu juist de essentie van het artikel.
Over waar MS Sharepoint allemaal voor geschikt is, wordt veel discussie gevoerd. Eigenlijk doe ik daar liever niet aan mee omdat het een vrij uitzichtloze discussie is. Het ligt er ook maar net aan wat de behoeften zijn.
Punt is dat de migratie van 2007 naar 2010 nogal een uitdaging is. Wie meer heeft laten ontwikkelen op MS Sharepoint 2007 dan wat er in de basis mee kan, heeft een probleem.
Ik lees dat enkele reageerders hun klanten met droge ogen vertellen dat ze die op Sharepoint gebouwde extra functionaliteiten verder maar moeten vergeten. Ik kan me gewoon niet voorstellen dat hun klanten dit zonder morren accepteren. Was die extra functionaliteit dan zo weinig belangrijk dat het zomaar kan worden los gelaten? Wilde men sowieso al uitwijken naar een alternatief? Of is het geduld en het budget van die klanten oneindig? Het laatste lijkt mij zeker niet het geval …
De uitspraak dat SharePoint 2010 alleen 64 bits modules ondersteunt en dat oplossing opnieuw GEPROGRAMMEERD moeten worden is NIET juist. In de meeste gevallen zullen de oplossingen gewoon werken in SharePoint 2010, onafhankelijk van de 32 / 64 bits architectuur.
Mijn technische uitleg hiervoor:
Om gebruik te maken van de API van SharePoint maakt de ontwikkelaar een referentie naar een SharePoint 2007 dll. Deze dll is enkel een referentie en bevat onder andere de namespace en versienummer van de dll, niet de CPU architectuur. Tijdens het laden van de maatwerk oplossing gaat het .Net Framework opzoek naar een dll die voldoet aan de namespace en versienummer. In het configuratiebestand van een SharePoint 2010 website (web.config) wordt standaard configureerd dat het .Net Framework voor een SharePoint dll van versienummer 12 (SharePoint 2007) de nieuwe versie 14(SharePoint 2010) moet gebruiken. Omdat de bestaande API’s hiervan nauwelijks zijn gewijzgd, zal in de meeste gevallen de maatwerk oplossing van SharePoint 2007 gewoon werken met de nieuwe dll’s van SharePoint 2010 (versienummer 14).
Uitzonderingen hierop zijn de oplossingen die specifiek gecompileerd zijn voor een cpu architectuur. Voor die projecten geldt dat deze opnieuw gecompileerd moeten worden (dus niet opnieuw geprogrammeerd).
Je kunt je natuurlijk wel afvragen of je al je maatwerk oplossingen 1 op 1 wilt migreren. Mogelijk is er voor jouw maatwerk oplossing voor SharePoint 2007 een out-of-the-box oplossing beschikbaar in SharePoint 2010.
Kunnen we de citaten van Erik Hartman een bredere context plaatsen? Mijn ervaring is dat bij ieder pakket en platform er allerlei toepassingen worden bedacht. Hoe dichter deze tegen de grenzen van de applicatie aan drukken, hoe spannender en leuker het project? “Ze” overschrijden daarbij vaak de grenzen van het pakket, deels door onbekendheid met het product, deels door (jong) enthousiasme en deels door wensen van de klant. Stelregel is dat een pakket 80% van de requirements dekt en “ze” iets moeten met de overige 20%. Dit is geen nieuw fenomeen en SharePoint is hierin niet anders. De nieuwe versie SharePoint 2010 brengt weer een hoop nieuwe mogelijkheden. Zal de 80% daardoor groeien naar 90%? Mijn ervaring is dat de eisen worden verhoogd en “onhebbelijkheden” uit de vorige versie moeten worden verholpen (verhoging van requirements) waardoor de grens van 80% blijft staan.
De heer Hartman heeft natuurlijk gelijk dat je de klant altijd moet vragen wat de toegevoegde waarde is van (custom) aanpassingen. Het is alleen erg flauw en populistisch om te stellen dat custom aanpassingen die bij de upgrade los worden gelaten, niet van meerwaarde zijn en er dus nooit een rationele aanleiding is geweest om deze te maken. Vaak zien we dat de nieuwe versie van een product veel nieuwe mogelijkheden brengt. De custom aanpassingen van de oude versie kunnen daarom (deels) worden vervat in standaard oplossingen van het nieuwe product. Een voorbeeld is een hierarchische thesausus (custom in MOSS, standaard in SP 2010). Blijft echter wel staan dat er veel aanpassingen zijn waarvan je vraagtekens kunt zetten bij nut en noodzaak.
Kortom het pleidooi om bij de standaard te blijven is een goede en customizations zijn alleen zinvol als deze van meerwaarde zijn voor de klant.
Een onderdeel waar ik het totaal niet eens ben met de heer Hartman is het toepassingsgebied van SharePoint. Hierbij sta ik niet alleen en zie ik research instituten zoals Gartner die inzien dat SharePoint 2010 op divers gebied een serieuse speler is. WCM is uit deze stack wellicht een van de minst sterke onderdelen, maar zeker een zeer bruikbaar onderdeel. SharePoint (MOSS en 2010) is uniek doordat het verschillende combineert en integreert (zoals records management, document management, collaboration, workflows, BI & rapportages, search, etc). Je kunt daardoor vrij brede toepassingen maken die meedere deelgebieden vereisen. Als men op een specifiek onderdeel een vergelijking maakt met de best-of-breed, dan zal SharePoint zich vaak in goed gezelschap begeven. Nemen we het geheel tesamen, dan blijven er weining consurrenten over.
Ikzelf vind een discussie interessant over de vraag “Welke toepassingsgebieden ondersteunt SharePoint zonder (veelvuldig) over de eigen pakketgrenzen heen te moeten en de 80-20 regel waar te maken”. Deze vraag helpt ons om te bewaken dat we SharePoint in blijven zetten op de onderdelen waarin het sterk is (de 80%) en voorkomen dat we de applicatie “misbruiken (te veel eindigen in de 20%). Kortom: SharePoint laten doen waarin het goed is en dit ook helder aan klanten en gebruikers kunnen verwoorden.
Ik ben eigenlijk benieuwd naar welke type componenten problemen opleveren. Is het dat configuraties niet juist gemigreerd kunnen worden of dat gebouwde webparts opnieuw gecompileerd moeten worden? Zijn het de veranderingen in sitetemplate constructies die issues opleveren of de BDC’s?
Migraties zijn altijd een ramp, tenzij je er goed en gedegen voorwerk aan besteedt. Op dat laatste punt wordt vaak bezuinigd. 🙂