Managed hosting door True

Migratie Sharepoint 2007 naar 2010 is lastig

 

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.'

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3241228). © Jaarbeurs IT Media.

?


Lees verder


Lees ook


 

Reacties

Tsja een paar jaar support gedaan op dit product.
Het product was prima, problematisch waren altijd die web developers die niet begrepen waar sharepoint voor gemaakt is. En dat gaf toen (en nu dus nog steeds) problemen. Out of the box is het een prima product maar velen begrijpen niet hoe dat te benutten, omdat ze niet altijd sharepoint begrijpen, hoe je er mee om moet gaan.

Laat sharepoint sharepoint zijn, en plaats je web apps op ISS heren "programeurs..." laat dat een lesje zijn..

Hoe zit het met Exchange 2010 en Sharepoint 2010, zijn deze producten nauw verweven met elkaar?
En is het verplicht om Sharepoint 2010 bij Office 2010?


Een Out of the Box product kan je in het algemeen maar beter niet aanpassen, zeker als je niet precies weet hoe het werkt. Nico, je hebt gelijk, maar Microsoft zelf is in haar reclame ook vaag over de functie van Sharepoint en over nog een paar relevante zaken. En dan kan het mis gaan als er een (te) snelle beslissing genomen wordt.

Bedrijven zullen in de meest gevallen een schone installatie SharePoint bouwen om vervolgens en database attach upgrade te kunnen uitvoeren, om de bestaande content uit de SharePoint 2007 omgeving te gebruiken in de nieuwe SharePoint 2010.

newby, de antwoorden zijn nee en nee. Je zit wel vast aan een 64 bit omgeving zoals Windows Server 2008 (R2) 64 bit , SQL Server 2005 of 2008 64-bit en uiteraard aan 64 bits hardware.

Zie: http://blogs.msdn.com/sharepoint/archive/2009/05/07/announcing-sharepoint-server-2010-preliminary-system-requirements.aspx

Even een korte reactie op de opmerking van Hartman in het bovenstaande artikel waarin hij aangeeft dat SharePoint een Document Management Tool is en voor andere doeleinden gebruikt wordt (Web Content Management en Record Management) en daarom allerlei andere modulen nodig zijn.

Deze stelling klopt namelijk van geen kant. SharePoint is veel meer dan een Document Management tool. In de basis van SharePoint zitten veel meer mogelijkheden die concreet in de praktijk gebruikt worden. Of dit nu is op Intranet omgevingen of ter ondersteuning van samenwerking tussen verschillende personen maakt niet uit.

Hartman stelt dat door het 'oneigenlijk' gebruik van SharePoint aanvullingen nodig zijn. Op zich kan ik hier wel inkomen. De voorbeelden die hij aandraagt echter totaal niet. De kracht van SharePoint is juist dat de standaard functionaliteiten in specifieke situaties kunnen worden uitgebreid met maatwerkcomponenten. Indien dit met mate wordt ingezet ligt juist daar de kracht van SharePoint.

Danny Burlage
Wortell

Dus voor Exchange 2010 en Office 2010 heb je geen licenties nodig voor Sharepoint 2010?

Ik ben het roerend eens met Danny: de opmerking van Hartman is behoorlijk kort door de bocht.

De praktische benadering die je in Sharepoint ziet, leidt er juist toe dat Sharepoint een hele mooie business enabler kan zijn.

Dat je alsnog (zoals eigenlijk met elk uitgebreid systeem) moet nadenken over de inrichting en architectuur is niet gek denk ik.

En "maatwerkcomponenten" ontstaan slechts wanneer je bij het design van je componenten geen rekening houdt met mogelijke scenario's waarin je componenten zullen gaan draaien. Componenten kunnen in Sharepoint 2010 op allerlei manieren worden gemaakt zodat ze zich ook in andere implementaties goed kunnen gedragen.

Beste Newbie,

Dat klopt inderdaad. Indien je Exchange 2010 en Office 2010 gebruikt hoef je geen gebruik te maken van SharePoint 2010, je hebt dus ook geen licenties nodig. Indien je Office 2010 en/of Exchange 2010 wil integreren met SharePoint 2010 is dat natuurlijk wel het geval.

Danny Burlage
Wortell

newby, technisch gezien heb je Exchange 2010 en Office 2010 hier niet voor nodig. Je kan ook OpenOffice gebruiken. MS licenties heb je alleen nodig bij gebruik van Exchange 2010 en Office 2010. Ik weet niet of er een MOSS versie van Sharepoint 2010 komt. Die zou dan onder meer WYSIWYG editing door Office 2010 kunnen bieden en Outlook kalender en SharePoint kalender synchronisatie.

Danny Burlage, volgens mij zeggen jij en Erik Hartman hetzelfde. Sharepoint is als een bijl die je ook als hamer, of aanbeeld kan gebruiken of als een presse papier.

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. :-)

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.