Business Central Cloud Migration – ein Erfahrungsbericht Teil 2

Nach dem Beitrag Businss Central Cloud Migration- ein Erfahrungsbericht Teil 1 geht es nun hier weiter.

Die Entscheidung für die Migration ist nun gefallen, aber bevor wir mit der eigentlichen Migration starten konnten, war einiges an Vorarbeit zu leisten.

Eine Beschreibung der Migrationsschritte findet ihr direkt auf Microsoft docs.

Registrieren einer Business Central Cloud Testversion

Zuerst mussten wir feststellen, ob unsere Anpassungen auch in der Cloud noch funktionieren. Dafür erstellten wir uns eine Testversion in der Cloud, um zu schauen ob die Erweiterungen weiterhin installierbar sind.

Für eine Testversion von Business Central kann man sich unter diesem Link registrieren: Eine Business Central Testversion registrieren

Eine ausführliche Anleitung für die Registrierung findet ihr auch kostenfrei auf Learn4D365: Anleitung zum Registrieren einer Testversion

Upgrade der Business Central Apps

Nun ging es daran unsere Apps upzugraden. Wie wahrscheinlich bei vielen hat sich im Laufe der Jahre einiges angesammelt und so entschieden wir uns gleich unsere diversen Apps in eine zukünftige App zusammenzufassen.

Es ging also ans Programmieren und Testen in der Cloud Version. Wir haben in diesem Schritt aber lediglich geschaut, ob die neue App kompilierbar ist und keine Tests mit unseren Daten gemacht.

Direkte Business Central Cloud Migration möglich?

Je nachdem von welcher Ausgangsversion man kommt, kann es hier auch notwendig sein ein oder mehrere Zwischenupgrades zu machen. Für uns intern war das nicht notwendig.

Ich habe hier für Euch überblicksmäßig dargestellt welche Zwischenschritte man eventuell benötigt:

Testmigration von Business Central in die Cloud

Nun begannen wir damit die Migration das erste Mal zu testen. Es empfiehlt sich dabei den Cloud-Client direkt am lokalen Server zu öffnen, da man damit Verbindungsprobleme aufgrund von Firewalls oder ähnlichem verhindern kann.

Eine Ausführliche Anleitung findet ihr hier:

Hier hat es sich für mich empfohlene einen Datenbankbenutzer am lokalen SQL Server anzulegen. Ansonsten hat dieser Schritt einfach und gut funktioniert.

Der nächste Schritt ist nun das tatsächliche Migrieren der Daten vom lokalen Server in die Cloud. Diese Aktion findet man auf der Seite „Verwalten der Cloud-Migration“. Auf der Microsoft docs Seite ist hier beschrieben, dass man die Migration auch in einem bestimmten Zeitfenster planen kann. Nachdem ich den dahinterliegenden Code analysiert habe, kam ich jedoch darauf, dass diese Aktion nur das Nutzen der „Cloud Insights“ zur Verfügung steht und nicht für eine Migration. Hier bleibt also nur die Aktion „Migration jetzt durchführen“.

Praxistipp: Messen Sie die Zeit, die diese Testmigration in Anspruch nimmt. Die Echtmigration wird in etwa genauso lange dauern und währenddessen kann kein Benutzer arbeiten. Eine gute Planung ist hier also notwendig.

Danach wählt man die Aktion „Datenupgrade jetzt ausführen“. Auch hier sollte man die Zeit messen für die Echtdatenmigration. Als letztes klickt man die Kachel „Nicht initialisierte Unternehmen“ an und initialisiert diese.

Hat man diese Schritte erfolgreich durchgeführt, kann man beginnen das neue System mit den Echtdaten zu testen. Währenddessen können alle Benutzer ungehindert in der lokalen Datenbank weiterarbeiten.

Probleme bei der Migration der Business Central Daten

Natürlich kann es bei Migration auch zu Problemen kommen. Was einem klar sein muss, ist, das alles, was mit Systemdaten zu tun hat nicht migriert wird.

Darunter fallen zum Beispiel:

  • Benutzer
  • Benutzerrechte
  • Personalisierungen
  • Gespeicherte Ansichten

Es kann aber auch vorkommen, das Daten von Erweiterungen bzw. Apps nicht migriert werden. Diese Erfahrung mussten auch wir machen. Woran liegt das aber? Wenn man einen Blick auf die Kachel „Tabellen mit Warnungen“ wirft sieht man, dass sich hinter dem Tabellennamen einen GUID befindet.

Tabellenmigrationsstatus

Diese GUID entspricht der App ID der Apps in der Cloud Version. Findet man für diese Tabelle (oder Felder) keine App mit der gleichen ID in der lokalen Version können die Daten nicht migriert werden, auch wenn Tabellennummer und Feldnummer gleich sind.

Echtmigration von Business Central in die Cloud

Hat man den Test erfolgreich abgeschlossen geht es weiter in Richtung Echtmigration.

Praxistipp: Vor der Echtmigration sollte man versuchen die Datenbank aufzuräumen bzw. zu verkleinern. Dieses kann sowohl direkt am SQL Server als auch in Business Central notwendig sein.

Bevor man die Migration durchführt, muss man alle Verbindungen zu externen Diensten stoppen und dafür sorgen, dass die Benutzer nicht weiter in der lokalen Datenbank arbeiten.

Wichtig: Denken Sie auch daran die Aufgabenwartenschlagen in Business Central zu stoppen!

Ist man dann so weit führt man die gleichen Schritte wie bei der Testmigration aus, nur hier migriert man die Daten nicht in eine Sandbox sondern in Ihre Produktionsumgebung.

Auch dieser Schritt hat bei uns ohne größere Probleme geklappt.

Nun bleibt es noch spannend wie es nach der Migration aussieht. Mehr dazu demnächst in Teil 3.

LG Michaela

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht.

*

code