Es begab sich zu der Zeit als ich meinen Blog von meiner SharePoint 2007 Mysite auf meine neue SharePoint 2013 (in Office365 gehostete) MySite migrieren wollte.

Das Vorgehen

Also schnell ShareGate geladen und loslegen. Als erstes also die Kategorien migrieren, damit die BlogPosts auf meiner neuen MySite dann auch darauf korrekt verweisen können; check!

Dann sind die Beiträge dran. Das sind schon ein paar mehr (>600) aber jetzt auch nicht so die Masse. Auch hier ist das Migrieren zunächst kein Problem. Bis ich mir dann die BlogPosts einmal angesehen habe. Dabei ist mir aufgefallen, dass HTML-Text, der von einem Pre-Tag umschlossen ist und der dazu noch Zeilenumbrüche beinhaltet nicht korrekt übernommen wird. OK, also mit den Jungs von ShareGate eine Lösung gebaut (Anmerkung: das war ein Bug in der Version 4.0 von ShareGate, der mit der Version 4.1 behoben wurde).

Das Problem

Danach ist mir aber ein etwas größeres Problem aufgefallen. Es kommt immer mal wieder vor, dass ich auf meinem Blog auf anderen Beiträge verweise. Das ist zuerst noch kein Problem. ShareGate erkennt Links, die auf die alte Site zeigen und passt die URL entsprechend der neue Site an. Die Pfade müssen also nicht identisch sein, auch die Website kann einen anderen Namen haben. Die Links sind im Ziel dennoch richtig; naja, fast. Denn der Verweis auf einen anderen Blogbeitrag geschieht über die Item-ID. Auf meinem alten Blog verweise ich also in Artikel 57 auf Artikel 17. Durch die Migration ist aber Artikel 57 von meinem alten Blog in meinem neuen Blog die Nummer 23 und Artikel 17 ist 133. Das kann ShareGate nicht erkennen – zumal die IDs ja erst nach dem Anlegen des Artikel feststehen. Somit sind erst einmal alle Querverweise innerhalb meines Blogs kaputt.

1. Lösung

Praktischerweise kann man ja die zu migrierenden Daten mit Excel nachbearbeiten. Dazu kann man also die Daten aus der Quelle nach Excel exportieren, dort bearbeiten und dann aus Excel in ShareGate importieren und in das Ziel schreiben. Das klingt doch nach einer guten Idee. Damit müsste ich doch meine Beiträge in Excel nachbearbeiten können.

Also steht nun folgendes Vorgehen fest:

1. Migrieren der Beiträge aus dem alten Blog in den neuen Blog
2. Exportieren der Beiträge aus dem alten Blog nach Excel
3. Korrektur der Querverweise in Excel
4. Import der Excel-Daten in den neuen Blog und damit Anpassung der URLs

Ein genialer Plan! 🙂

Die Schritte 1. und 2. sind ja schnell gemacht. Für 3 hatte ich erst gedacht, dass ich Anhand des Titels des alten Beitrags die ID des neuen Beitrags im neuen Blog nachschlagen müsste. Aber dann ist mir eingefallen, dass ShareGate ja ein Migrationsprotokoll erstellt.

Dieses Protokoll kann man ebenfalls nach Excel exportieren. Und da stehen die ID aus dem Quell-System und die ID aus dem Zielsystem drin. Super!

Nun habe ich also eine Liste meinen Blogbeiträge und eine Liste mit den Migrationsinformationen.

Nun muss ich nur noch die Blogbeiträge durchgehen, nach Links auf anderen Blogbeiträge suchen und hier dann den Link auf die neue Item-ID anpassen (z.B. von /personal/eiben/Blog/Lists/Beitraege/ViewPost.aspx?ID=54 auf /personal/eiben_busitec_de/blog/Lists/Posts/ViewPost.aspx?ID=629). Jetzt ist das bei mehr als 600 Beiträgen doch schon etwas mehr Arbeit, und wenn die BlogPosts etwas länger sind und viel HTML enthalten auch in Excel nicht so übersichtlich, dass man das von Hand machen kann. Und Suchen und Ersetzten scheidet ja wohl auch aus, da ich ja nicht weiß auf welche Einträge verwiesen wird.

Aber wie gut, dass Excel VBA hat. Also mal eben ein kleines Makro geschrieben.

Dim cellCurrent As Range
Dim rangeCopyResult As Range
Dim objRegEx As Object, objMatches As Object
Dim rangeSourceId As Range, rangeDestinationId  As Range
Dim strReplValue As String, strResultId As String, strOldVal As String

Set rangeSourceId = Worksheets("results").Range("r2", "r1000")
Set rangeDestinationId = Worksheets("results").Range("aa2", "aa1000")

Set objRegEx = CreateObject("vbscript.regexp")
objRegEx.Pattern = "\/personal\/eiben\/Blog\/Lists\/Beitraege\/ViewPost.aspx\?ID=(\d+)"

Set cellCurrent = Application.ActiveCell

While (cellCurrent.Value <> "")
    If objRegEx.test(cellCurrent.Value) Then
        Set objMatches = objRegEx.Execute(cellCurrent.Value)
        strOldVal = objMatches(0).submatches(0)
        strResultId = Application.WorksheetFunction.Lookup(CInt(strOldVal), rangeSourceId, rangeDestinationId)
        If (strResultId <> "") Then
            strReplValue = objRegEx.Replace(cellCurrent.Value, "/personal/eiben/Blog/Lists/Beitraege/ViewPost.aspx?ID=" + strResultId)
            cellCurrent.Value = strReplValue
            strResultId = ""
            strReplValue = ""
        End If
    End If
    Selection.Offset(1, 0).Select
    Set cellCurrent = Application.ActiveCell
Wend

Zunächst suche ich also per RegEx (Zeile 11 bzw. Zeile 16/17) nach einem Link und extrahiere die Item-ID auf die ich verweise. Dann schlage ich mit der Excel-Funktion Lookup im Migrationsprotokoll die neue Item-ID nach (Zeile 19) und kann den Link entsprechend ersetzt. Das ganze wiederhole ich solange bis ich auf eine leere Zeile treffe (Zeile 15).

So, das war also Schritt 3. Nun nur noch meine angepassten Daten aus Excel über ShareGate in meinen neuen Blog importieren. Beim Import erkennt ShareGate, dass es bereits einen Artikel mit Titel “VPN-Route per PowerShell setzen” gibt und fragt mich was ich machen will – als Auswahl stehen Ersetzen oder Überspringen. Ersetzen ist ja genau was ich will, dann ich will die Beiträge im Ziel ja mit den angepassten Links aktualisieren.

Perfekt. Alle Artikel sind aktualisiert. Wenn ich nun meinen Beitrag mit der ID 23 aufrufe, dann sollte der ja auf Beitrag 133 verweisen – so wie ich die Links im Excel korrigiert habe. Nur leider gibt es keinen Artikel mit der ID 23 – nicht mehr. Dieser hat nun die ID 706. Dafür verweist der wie erwartet auf Beitrag 133 – den es aber auch nicht mehr gibt. Das ist nun 709.

Was ist passiert? Beim Importieren der Daten mit ShareGate heißt „Ersetzen“ in diesem Zusammenhang: erstelle ein neues Element und lösche das alte. Damit werden natürlich auch neue ID vergeben. Meine tolle Idee funktioniert somit also nicht mehr 🙁

2. Lösung

In der Zwischenzeit hatte ShareGate eine neue Version veröffentlicht, die auch neue Features mit sich bringt. So stellte die Version 4.3 erstmals inkrementelle Updates vor. Hier wird wirklich ein Update gemacht. Das Ursprungselement wird also nicht durch ein neues Element ersetzt, sondern es wird aktualisiert. Das klingt ja super – damit müsste ich ja dann meine Excel-Daten als „inkrementelles Update“ einspielen.

Stellt sich also schnell heraus, dass inkrementelle Updates ein Problem mit dem Import von Excel-Daten haben. Wenn ich Daten aus Excel importiere, dann kommt es zu einem Fehler. Also mal wieder eine kleine Remote-Session mit den Support-Jungs von ShareGate und das Problem ist schnell erkannt und eine Beta ist unterwegs (Anmerkung: ist inzwischen in der Version 4.4 ebenfalls behoben).

Mit der Beta geht es dann – aber eine neue Herausforderung zeigt sich. Der Name „inkrementelles Update“ sagt es ja schon … es werde nur die Elemente aktualisiert, die in der Quelle neuer sind als im Ziel. Da ich aber das Letzte Bearbeitungsdatum nicht geändert habe (und eigentlich nicht ändern will), haben sich die Daten aus der Sicht von ShareGate nicht geändert. Somit ist auch nix mit Update.

3. Lösung

Jetzt ist das Ziel doch schon so nahe … irgendwie. Und da kommt der entscheidende Hinweis vom ShareGate-Support: Bulk-Metadata-Edit! Ich kann die Metadaten von SharePoint-List ja auch mit ShareGate bearbeiten. Dazu werden die Daten in Excel heruntergeladen, können dort bearbeitet werden und dann wieder in ShareGate importiert werden. Dabei werden die Daten aber nicht als „Quelle“ für eine Migration angesehen, sondern die Daten im Zielsystem werden entsprechend der Daten in dem Excel aktualisiert.

OK, dazu hätte ich also den Umweg über das Incrementel-Update und der Bugfix der Version 4.3.x nicht sein müssen.

Nun also – Daten für den Bulk-Edit in Excel exportieren, mein Makro da drüber laufen lassen und dann wieder in ShareGate einlesen. Und siehe da – nun behält mein Beitrag in meinem neuen Blog auch die ID 23 und verweist wie erwartet auf den (existierenden) Beitrag 133.

Endlich am Ziel.

PS

Was natürlich weiterhin kaputt ist, sind Links auf anderen Blogs o.ä. die ebenfalls migriert wurden. Hier hat ShareGate keine Ahnung davon wo die wohl hin migriert wurden. Das ist also weiterhin ein Problem.