[gelöst] Fragen zu DataUpgrade bei Migration BC 21 -> BC 25

[ThomasFerstl]

Heyho,

ich beschäftige mich aktuell mit einem Migrationsprojekt von BC 21.1 auf BC 25.8 und folge dazu dem Leitfaden von Microsoft. Aktuell bin ich noch dabei, den gesamten Migrationsprozess zu durchdenken und z.B. Skripte vorzubereiten.

Ich bräuchte jedoch einmal eine kurze Denkhilfe. Im aktuellen Schritt wurde die Datenbank bereits auf Stand BC 25 konvertiert und der Tenant synchronisiert, die neuen Versionen der Extensions sind gepublished und synchronisiert. Jetzt geht es an das Data Upgrade. Laut Leitfaden muss das Data Upgrade für die einzelnen Extensions in der Reihenfolge der Abhängigkeiten durchgeführt werden. Das ist logisch und wird für die Anwendungsbasis auch im Detail beschrieben, also Upgrade der System Application, danach Install der neuen Business Foundation, und danach Upgrade für Base Application und letztendlich die Application.

ABER: Es gibt ja noch einen ganzen Rattenschwanz alleine an weiteren Microsoft Apps, die untereinander jeweils Abhängigkeiten haben können. Jetzt war die Idee, dass ich die ganzen Apps erst per Install-NavApp installiere und danach das Data Upgrade vornehme, um mir Probleme mit einer falschen Reihenfolge zu ersparen. Nur habe ich dieses Konstrukt so noch nicht in der Praxis gesehen. Da wird bei einem Upgrade der App lediglich das Data Upgrade durchgeführt. Install wird nur verwendet, wenn die Extension vorher noch nicht installiert war.

Funktioniert mein Gedankengang überhaupt, oder halse ich mir damit zusätzliche Probleme auf? Zerschieße ich die Migration vielleicht sogar? Wie seid ihr bei Migrationen vorgegangen, wenn die Abhängigkeiten der Extensions untereinander nicht eindeutig bekannt sind?

Zuletzt geändert von ThomasFerstl am 22. Juli 2025 17:46, insgesamt 1-mal geändert.

Grundsätzliche Vorgehensweise bei neuen Apps:
Publish-NAVApp -ServerInstance $ServerInstance -Path $Path
Sync-NavApp -ServerInstance $ServerInstance -Name $ExtensionName -Version $Version -Tenant default
Install-NAVApp -ServerInstance $ServerInstance -Name $ExtensionName -Tenant Default

Vorgehensweise bei bereits vorhandenen Apps:
//UnInstall-NAVApp -ServerInstance $ServerInstance -Name $OldExtensionName -Version $OldVersion
//UnPublish-NAVApp -ServerInstance $ServerInstance -Name $OldExtensionName -Version $OldVersion
Publish-NAVApp -ServerInstance $ServerInstance -Path $Path
Sync-NavApp -ServerInstance $ServerInstance -Name $ExtensionName -Version $Version -Tenant default
Start-NAVAppDataUpgrade -ServerInstance $ServerInstance -Name $ExtensionName -Tenant Default

Ich gehe so auch für die einzelnen Apps vor dass ich die drei Schritte (Publish, Sync, Install bzw. DataUpgrade) jeweils pro App hintereinander durchführe.

Was die Reihenfolge bei den Microsoft Apps und deren Abhängigkeiten angeht so sollte sich die Abhängigkeit am Namen erkennen lassen. Bei den E-Dokumenten z. B. musst du erst E-Document Core und dann die anderen installieren/upgraden.

Bei den Email Apps gibt es Abhängigkeiten, in dieser Reihenfolge sollte es funktionieren:
Email - Outlook REST API
Email - Current User Connector
Email - Microsoft 365 Connector
Email - SMTP API
Email - SMTP Connector

Ansonsten gehe ich bei den Apps i. d. R. alphabetisch vor und korrigiere meinen Ansatz wenn's knallt.

Hallo enh,

Was die Reihenfolge bei den Microsoft Apps und deren Abhängigkeiten angeht so sollte sich die Abhängigkeit am Namen erkennen lassen. Bei den E-Dokumenten z. B. musst du erst E-Document Core und dann die anderen installieren/upgraden.

Bei den Email Apps gibt es Abhängigkeiten, in dieser Reihenfolge sollte es funktionieren:
Email - Outlook REST API
Email - Current User Connector
Email - Microsoft 365 Connector
Email - SMTP API
Email - SMTP Connector

Ansonsten gehe ich bei den Apps i. d. R. alphabetisch vor und korrigiere meinen Ansatz wenn's knallt.

Das hatte ich fast befürchtet, aber vielen Dank, dass du das nochmal klargestellt hast. Dann war meine Idee, die Abhängigkeiten durch Install-NAVApp und danach erst Start-NAVAppDataUpgrade zu umgehen also ein Griff ins Klo. Ich hatte nur irgendwie erwartet, dass es für sowas einen eleganteren Weg geben müsste, als im Zweifel die richtige Reihenfolge per durchprobieren herauszufinden.

Ich vermisse auch einen schöneren Weg alle Microsoft Extensions zu installieren. In SaaS macht Microsoft das ja so aber on premises muss man die "DVD" der neuen Version manuell durchschauen und sich manuell ein Skript bauen (bzw. entscheiden welche Extension wichtig ist und welche nicht). Vielleicht gibt es dafür auch intelligente Tools die ich nicht kenne.

ähm,

macht euch das Leben bitte nicht so schwer!

https://www.waldo.be/2019/08/28/app-dependency-tree-import-your-apps-in-the-right-order-with-powershell/

https://community.dynamics.com/blogs/post/?postid=f539e810-3991-4adb-a982-ae418551dd07

ihr werdet doch bitte nicht jede App einzeln da reinballern, sondern schön in einen Ordner legen und via Script durchrattern.

wenn ihr den Dependency-Tree habt, könnt ihr schön hübsch publishen/syncen/installen/whatever. so installieren wir immer unsere eigenen Apps (OnPrem) -> bei ehemals 28 Stück hat man ganz schnell die Zeit in die Scripte investiert. selbst wenn es nur 2 Apps wären -> hochgerechnet auf die Anzahl an Kunden oder von mir aus Containern, die man mal mit Updates versehen will ist der Zeitinvest von mir aus 1T für das hübsch machen der Scripte echt zu vernachlässigen -> ihr bekommt das sicher schneller hin als ich, da die Powershell echt was gegen mich hat :D

on premises muss man die "DVD" der neuen Version manuell durchschauen und sich manuell ein Skript bauen (bzw. entscheiden welche Extension wichtig ist und welche nicht). Vielleicht gibt es dafür auch intelligente Tools die ich nicht kenne.

hierfür ziehe ich mir wirklich einfach alle Apps von MS und bereinige die im Nachgang, die ich nicht brauche

Code:

Get-ChildItem -Path "E:\D365_BC_25_CU09\applications*" -Include *.app -Recurse | Copy-Item -Destination E:\tmp\BC25_Apps\
-> aufräumen (Language, Library, Tests,Contoso,Performance,Demo)


==> wenn die Apps kopiert wurden, kille ich alle, die nicht der gewünschten Sprache entsprechen. und dann den Rest, den ich nicht will (Library, Test, Contoso, Performance, Demo).

Intelligent ist das vielleicht nicht gerade, erfüllt aber seinen Zweck (für mich)

Hallo sweikelt,
danke für deine Tips, das muss ich mir mal anschauen. Ich habe noch nicht viele Migrationen gemacht, wenn es für die Skripterstellung Tools gibt dann kann das nur gut sein.

Hallo Stephan,
hallo enh,

danke für eure Beiträge. Ich habe die Migration testweise durchgeführt und mir einen Fahrplan dafür erstellt.

FG
Thomas