En trinvis migrering er mange kopier og ét skift

En migrering af et fildrev eller en gammel SharePoint-farm på flere terabyte kan ikke klares over en weekend. Svaret er at gøre den trinvis. Det ord dækker over to ting, og de bliver ofte blandet sammen: at kopiere det samme område flere gange, så kun ændringerne kommer med den sidste gang, og at lade det gamle og det nye system køre side om side, mens brugerne flytter over. Det første er det, der gør en stor migrering mulig. Det andet er det, der ødelægger den.

Kopi, kopi, skift#

Microsofts egne værktøjer er bygget til de gentagne kopier. SharePoint Migration Tool (SPMT) og Migration Manager kan køre den samme opgave igen, og så kopieres kun det, der er nyt eller ændret siden sidst (SPMT, Migration Manager). ShareGate har det samme under navnet Copy if newer (incremental).

Forløbet bliver:

1. Den første kopi tages i god tid. Den tager dage eller uger, og ingen mærker det, fordi alle stadig arbejder i kilden.
2. Gentagne kørsler tager det, der er kommet til. De bliver kortere for hver gang.
3. Skiftet. Kilden lukkes for skrivning, den sidste kørsel tager resten, og brugerne sendes over.

Det eneste, brugerne mærker, er den sidste kørsel. Microsoft skriver det samme i vejledningen til fildrev: migreringen sker i baggrunden, og bagefter kommer ét skift, hvor fildrevet slås fra, og brugerne sendes til SharePoint og OneDrive (Microsoft).

Hvad en ny kørsel ikke tager med#

En ny kørsel er ikke en synkronisering. Den kopierer det nye og det ændrede. Resten efterlader den:

• Slettede filer bliver liggende. En fil, der slettes i kilden efter den første kopi, forbliver i SharePoint. Migration Manager skriver det direkte: “Already migrated files remain in the target location.” ShareGate siger det samme om sin inkrementelle kopi.
• Omdøbt er nyt. SPMT genkender filer fra et fildrev på stien. En mappe, der omdøbes i kilden mellem to kørsler, kommer over en gang til under det nye navn, og den gamle forsvinder ikke.
• Ændringer i målet. Retter nogen i en fil i SharePoint, før skiftet er sket, overskriver Migration Manager den ikke. Omdøber eller flytter nogen den, bliver den kopieret over igen. SPMT sletter målfilen og lægger kildens fil over, når kilden er nyere (Microsoft).
• Datoerne. Migration Manager har to slags kørsler. Delta sync tager det, der er ændret siden sidste kørsel. Full incremental sammenligner alt, og den fanger filer, der er lagt i kilden med en gammel ændringsdato, fx kopieret ind fra et andet drev.

Jo længere tid der går mellem den første kopi og skiftet, jo mere af den slags samler sig. Det taler for at holde perioden kort, og for at lade den sidste kontrol sammenligne kilden med målet og ikke bare læse migreringsrapporten. Hvad kontrollen skal kunne vise, står i At bevise, at intet blev ændret under en migrering.

To steder at skrive er to sandheder#

Den anden betydning af “trinvis” er den farlige: at begge systemer er i brug på samme tid, og at brugerne selv flytter over, når de er klar. Om mandagen gemmer en bruger i det gamle fildrev, om tirsdagen retter en kollega samme dokument i SharePoint. Nu er der to udgaver, og ingen af dem er den rigtige. Den næste kørsel løser det ikke. Enten overskriver den kollegaens rettelse, eller også lader den rettelsen stå og efterlader mandagens.

Microsoft anbefaler ét skift for alle brugere, netop for at ingen retter i kopier af det samme (Microsoft). Jeg har ikke fundet en vejledning fra Microsoft, der anbefaler det modsatte, at holde begge systemer skrivbare og synkronisere imellem dem.

At køre side om side er fint, så længe kun det ene kan skrives i. Det gamle fildrev kan godt blive stående en periode, skrivebeskyttet, så folk kan tjekke, at det hele kom med.

Tilbage er den gamle kilde#

En plan for at rulle tilbage lyder som noget, der skal scriptes. Ved en migrering af dokumenter er den noget simplere: kilden står urørt og skrivebeskyttet, indtil migreringen er godkendt. Så er vejen tilbage at åbne kilden for skrivning igen.

Men den vej lukker sig i det øjeblik, brugerne begynder at arbejde i det nye. Alt, hvad de har gemt i SharePoint efter skiftet, er ikke i kilden. Derfor skal to ting besluttes, før skiftet: hvad der skal til, før migreringen rulles tilbage, og hvor længe det kan nås. Efter den frist er vejen frem den eneste.

Bølger#

Den trinvise migrering kan også deles i bølger, område for område, med et lille område først som prøve. Det virker, når områderne er adskilt. Det, der binder dem sammen, afgør rækkefølgen: links fra det ene område til det andet, flows, der læser på tværs, og grupper, der har adgang flere steder. Hvert område skal have sit eget skift, og i hvert område gælder det samme: mange kopier, ét skift og ét sted at skrive ad gangen.