In drie delen beschrijf ik de grootste uitdaging die ik ben tegengekomen bij het migreren binnen SharePoint. Na mijn ervaringen met migratietrajecten en een uitleg over die grootste uitdaging, nu het laatste deel met de oplossing!
Oplossing: inchecken in plaats van publiceren
Het vorige deel sloot af met optie 4 (vervangen op pagina-niveau), die wel werkte maar nogal uitgebreid en omslachtig was. En toen kwamen we op een vijfde oplossing waarbij er geen pagina’s of subsites worden gewijzigd en waardoor er dus ook geen links hoeven worden aangepast!
De oplossing: het wijzigen van de huidige pagina’s. Dit klinkt logisch maar heeft uiteraard impact tijdens de migratie. Vandaar dat een pagina eerst in de nieuwe template wordt gezet, de content wordt overgezet en vervolgens wordt de pagina ingecheckt in plaats van gepubliceerd. Zodra alle pagina’s in die subsite zijn gemigreerd, wordt de masterpage van de subsite aangepast en alle pagina’s tegelijkertijd gepubliceerd. Dankzij deze oplossing worden alle productpagina’s dan met één druk op de knop omgezet naar de nieuwe stijl, hoeven er daarna geen links worden aangepast en merkt de websitebezoeker niets van de contentmigratie tijdens dit proces.
Nadelen vijfde oplossing
Klinkt ideaal, toch bracht ook deze werkwijze nadelen met zich mee:
- Wijzigingen zijn niet direct zichtbaar omdat de previewfunctie niet optimaal werkt. Hierdoor zie je dus pas het uiteindelijke resultaat (met eventuele fouten) als de pagina is gepubliceerd (en tegelijk met de websitebezoeker).
- Moeilijker wijzigingen doorvoeren zolang het migreren nog gaande is. Dit speelt vooral bij grote producten met veel pagina’s, waarbij het dus langer duurt voordat alle pagina’s zijn omgezet. In die tussentijd is het lastiger om de pagina’s ook inhoudelijk aan te passen. Dit probleem speelde wel minder want het komt nauwelijks voor dat in die relatief korte tijd iets inhoudelijks wijzigt.
- Een risico want als er iets fout gaat, is de oude content vervangen en dus verloren gegaan. Via versiegeschiedenis kan je de pagina wel weer terugzetten om oude content terug te halen, maar dit is uiteraard onwenselijk.
Oplossing nadelen
Al deze drie nadelen kunnen we verhelpen door wel te kiezen voor deze oplossing, maar die nieuwe pagina’s eerst in een tijdelijke subsite neer te zetten. Ook dit levert extra werk op, maar minder dan het nawerk en bovendien blijven alle pagina’s altijd bereikbaar voor de websitebezoeker. Hiermee sluit je dus de meeste risico’s uit want hierdoor is het ook exact mogelijk om tussentijds het resultaat te zien.
Bij grote producten (of belangrijke producten, met veel pagina’s of funnels in extra subsites) kies ik deze werkwijze met een tijdelijke subsite, bij kleinere producten van enkele pagina’s werkt het rechtstreeks wijzigen in de huidige subsite ook prima. Gaandeweg krijg je hier natuurlijk ook meer ervaring en vertrouwen in.
SharePoint 2013
In deel 1 van dit drieluik gaf ik al aan dat ik meerdere migratietrajecten heb meegemaakt. Een migratie naar SharePoint 2013 staat ook op de planning. Op het congres SharePoint heb ik al het een en ander gehoord over de mogelijkheden daarvan. Kom maar op met die migratie!
166 
51 
238 
395 
335 berichten