Blogg

Att uppgradera SharePoint till en nyare version

SharePoint 2016 är snart här men det finns fortfarande många installationer av SharePoint 2010 och till och med gamla MOSS 2007 har jag ramlat över nyligen. Lyckligtvis var anledningen till "överramlingen" att det skulle ske en uppgradering till en senare version :)

Artikelverktyg:

Att uppgradera SharePoint kräver i många fall en hel del planering och det kan vara många olika saker att ta hänsyn till. Detta beroende på vad det är för en installation, om det är många anpassningar gjorda och vad för uppgradering det rör sig om.

Varför uppgradera?

MOSS 2007 är eller borde vara sedan länge ett avslutat kapitel. Vad gäller SharePoint 2010 så har Microsoft sedan oktober 2015 slutat med support (mainstream support som t.ex. cumulative updates).

Andra anledningar till att uppgradera kan bero på vad man använder SharePoint till och vilka utmaningar man har i sin organisation eftersom SharePoint och Office 365 täcker väldigt många områden.

Att uppgradera till SharePoint 2013 kan innebära följande fördelar:

  • Ett renare och snabbare användargränssnitt
  • Bättre sök och filtrering i listor och dokumentbibliotek
  • Sök byggt på FAST med t.ex. Type-ahead, förhandsvisning i sökresultat
  • Effektivare lagring av dokument

Ett antal fördelar med att uppgradera till SharePoint 2016 och/eller Office 365 har Robert Skyttberg skrivit om tidigare i Att vara i molnet eller inte - det är frågan.. men kort sagt så har mycket kraft lagts på att kunna köra hybridlösningar där en del finns en del on-premise och en del i molnet. Eller så har man helt enkelt en plan att gå mer mot molnet och de möjligheter som finns i Office 365.

Från 2007/2010 till 2013

I de uppgraderingar jag varit inblandad i det senaste så har vi alltid gjort en "database attach" där vi flyttat hela databaser. Det är då inte möjligt att lyfta SharePoint över flera versioner på en gång så en uppgradering från 2007 till 2013 eller 2010 till 2016 innebär en eller flera interimuppgraderingar. Man måste gå i ordningen 2007, 2010, 2013, 2016 utan att hoppa över en version men man kan så klart använda en server tillfälligt för att lagra innehållsdatabaser, användarprofiler med mera på vägen dit.

Det kan vara svårt att förutse vad som händer med anpassade lösningar över två versioner. Där har vi inte lagt nån större tid på att säkerställa att interimuppgraderingen har fungerar klockrent utan endast att den slutgiltiga versionen har fungerat bra. Det är ingen större idé att till exempel ordna och snygga till användargränssnittet med css:er och javascript i SharePoint 2010 när man ändå är på väg till SharePoint 2013 eller 2016 där det har skett stora förändringar.

Det finns även tredjepartsverktyg för att migrera data men de är ofta dyra och det krävs dels att man förstår verktyget men även vad som kan gå fel i SharePoint när man använder dessa. De kan vara värda att undersöka om man ser andra behov av att flytta data mellan olika miljöer.

Ytterligare ett alternativ är att endast migrera innehåll (dokument, sidor, m.m.) där man då kan gå från 2007 till 2016 med en gång om man vill. Då gör man sig av med alla gamla anpassningar som man vid behov får bygga om på nytt. Vad gäller anpassningar i användargränssnitt och sök så är det ändå sällan de går att flytta med sig medans andra saker kan gå att behålla utan större problem.

"Bring out your dead"

Ofta när vi bygger lösningar så fokuserar vi väldigt mycket på att lägga till nya funktioner. Jobbar vi lättrörligt händer det ganska så ofta dessutom. Eftersom organisationer och världen runt omkring oss förändras så finns det behov av att ta bort funktionalitet också vilket man ibland glömmer bort. Det är inte lika roligt eller så tänker man att det kan vara bra att ha ifall ifall ifall utifall att.. något som aldrig inträffar men man vet ju inte.

Inför en uppgradering började vi rätt tidigt att göra oss av med gamla webbdelar, applikationssidor och annat som inte behövdes längre. Koden blir lättare att underhålla, risken för fel vid deployer minskade och livet kändes allmänt lättare. Tiden vi la på att verifiera och uppgradera anpassningar minskade också så klart, varför uppgradera något som inte används?

Smidiga små steg

En större lösning med många anpassningar och mycket innehåll tar så klart tid att uppgradera. Måste man då stänga ner hela sin verksamhet under en lång period, sluta supporta den nuvarande miljön och lämna användarna i sticket? Så klart inte. Även om vi nu för tiden bygger lösningar som även fungerar i molnet så kan vi fortfarande deploya kod på det gamla sättet för SharePoint on-premise. Så de korrigeringar vi behöver göra för nästa version kan vi till exempel lägga i en egen gren i vår versionshantering och kontinuerligt hämta buggfixar och nya saker samtidigt som vi fortfarande underhåller och förbättrar den gamla versionen.

  • Vi underhåller och städar så klart bort funktionalitet kontinuerligt som en del av vårt dagliga arbete så det är ingenting som är någon skillnad.
  • Vi kan prioritera olika webbplatssamlingar om det finns flera och lämna de som sällan används eller inte är lika viktiga till senare.
  • Vi kan börja med att använda vissa delar som till exempel sök i den nya versionen och flytta innehåll senare. Eller tvärtom.
  • Använder man classic authentication i SharePoint 2010 så kan man uppgradera till claims based authentication i förväg.
  • Fortsätta att deploya gammal server side kod men ny funktionalitet och förändringar byggs för att passa in i molnet.

Det finns många olika sätt att dela upp sin uppgradering i olika steg så att vi har koll på var vi står, hur mycket som är kvar och så att vi känner att vi kontinuerligt rör oss framåt.

En big bang?

Det är ändå så att vissa delar i SharePoint ändras rätt drastiskt vilket kräver ett lite större grepp. 

  • Sök - Har man byggt mycket på sök och ska uppgradera från MOSS 2007 eller SharePoint 2010 så har man förmodligen en del jobb att göra. 
  • Användargränssnitt - Är det stora ändringar i användargränssnittet så kan det vara väldigt lite att ta med sig och mycket måste förmodligen göras om. Gillar man SharePoint som det är kan man ju naturligtvis lämna det så ;)
  • Arbetsflöden - De som är byggda för SharePoint 2010 fungerar fortfarande i SharePoint 2013 (och 2016?!) utan några förändringar men bör på sikt byggas om.
  • InfoPath - Finns fortfarande support (till och med 2016?) men kommer på sikt försvinna. Alternativ saknas så här får man göra egna lösningar invänta och se vad Microsoft planerar.
  • SharePoint Designer - Power users som använder designern får hitta andra sätt att jobba på (av många anledningar ;)
  • Gammal kod - Gammal kod som körs på servern kan i många fall användas med mindre justeringar. Har man inte tillgång till källkoden kan det naturligtvis vara ett problem. Vi kan skapa nya solution-paket och använda oss av feature masking i en del fall. Då kör vi över den gamla koden (inklusive listmallar, schema.xml-filer, features med mera om de finns).

Vägen framåt

Vi vet att det ständigt kommer nya versioner (även om det är små kontinuerliga uppdateringar i Office 365) så det bör inte komma som någon större överraskning utan finnas med i livscykeln för vår SharePoint-installation. Det är en fördel att följa vad som sker i Office 365 även om man kör SharePoint on-premise eftersom det är där nyheter och förändringar kommer först. Då är man bättre förberedd på förändringar som kan komma till sin egen miljö.

Har man byggt många lösningar i MOSS 2007/SharePoint 2010 så är de i många fall byggda med kod som körs på servern. De lösningarna kan man till stor del ha kvar ett tag men man bör fasa ut dem till förmån för det nyare "molnbaserade" sättet att bygga på. Då är man dessutom bättre förberedd om man vill helt eller delvis gå upp i molnet.

Exempel på tidplan för uppgradering

En stor lösning kan ta lång kalendertid att genomföra, nedan är en bild på ett tänkt exempel för att uppgradera SharePoint 2010 till 2013 under ett år. Tidsspannet kan så klart vara allt från en eller ett par veckor och framåt.

Beslut om uppgradering tas 5 maj 2015. Vi fortsätter att underhålla SharePoint 2010 med buggfixar men även med ny funktionalitet fram tills 20 maj 2016 då vi låser den gamla miljön och genomför uppgraderingen. Även här kan det ta allt från ett par timmar till några dagar att kopiera nytt innehåll och deploya kod till den nya miljön.

Vi flyttar data från 2010 till testmiljön för 2013 ett par gånger (1 aug och 20 dec) för att få riktig data när vi utvärderar våra anpassade lösningar. Vi deployar dessutom den kod vi har korrigerat och anpassat för SharePoint 2013 kontinuerligt.

I början av 2016 börjar vi testa olika webbplatssamlingar där ett antal användare får tillgång till den nya miljön. Är det skilda webbplatssamlingar så kan vi prioritera dem efter behov.

I maj 2016 så har vi anpassat äldre kod, byggt några nya lösningar för sökbaserad funktionalitet, gjort vissa anpassningar i användargränssnittet samt testat av detta. När vi gör uppgraderingen till SharePoint 2013 så låser vi den gamla miljön, flyttar allt innehåll och deployar kod. Sedan är det bara att peka om DNS:en så användarna hamnar på den nya servern, allt är frid och fröjd och man kan gå på semester :)

Ok, det kan vara bra att planera in några dagars stand-by tid för oförutsedda händelser efter lanseringen ifall ifall utifall att.. ;)

Vill du veta mer om hur du uppgraderar din SharePoint-lösning?

Välkommen att kontakta oss via formuläret så återkommer vi inom kort. 

0 kommentarer

Skriv kommentar