Business Central Partner wechseln: Ablauf Schritt für Schritt

Ein Business-Central-Partnerwechsel besteht aus drei getrennten Strängen: dem Wissen über euer System (Apps, Anpassungen, Quellcode), dem Lizenzvertrag (bei Business Central Online meist über einen CSP-Partner) und dem Admin-Zugriff (GDAP-Beziehung im Microsoft-Tenant). Wer diese drei Stränge einzeln und in der richtigen Reihenfolge abarbeitet, vermeidet Lücken beim Übergang. Ein typischer Fehler ist, den Vertrag zu kündigen, bevor Quellcode und Dokumentation gesichert sind.

Dieser Artikel beschreibt den Ablauf für Business Central Online. Bei On-Premises-Installationen kommen Server-Zugang, Lizenzdatei und Datenbank-Backups dazu, die ihr direkt mit dem bisherigen Partner bzw. eurer IT klärt. Hinweis: Das hier ist eine technische und organisatorische Orientierung, kein Rechtsrat. Vertragsfragen zu Nutzungs- und Quellcoderechten gehören zu einer Anwältin oder einem Anwalt.

Die drei Stränge im Überblick

Ein Partnerwechsel betrifft Wissen, Lizenzen und Zugriff, und jeder Strang hat eigene Beteiligte und eigene Fristen.

Die Reihenfolge, die sich in der Praxis bewährt: erst Bestandsaufnahme und Code sichern, dann neuen Partner anbinden, dann Lizenzen übertragen, zuletzt den alten Zugriff beenden und aufräumen.

Schritt 1: Bestandsaufnahme machen

Bevor ihr irgendetwas kündigt, braucht ihr eine vollständige Liste dessen, was in eurem Business Central läuft. Ohne diese Liste kann auch der neue Partner den Aufwand nicht seriös einschätzen.

Im Business Central Admin Center seht ihr pro Umgebung unter Apps verwalten (Manage Apps) alle installierten Apps. Microsoft unterscheidet dabei globale Apps (z. B. aus AppSource), Per-Tenant-Extensions und DEV-Extensions (Microsoft Learn: Apps im Admin Center verwalten). Für den Wechsel sind vor allem die PTEs wichtig: Das sind die Anpassungen, die speziell für euch entwickelt wurden.

Diese Bestandsaufnahme übernehme ich auf Wunsch unabhängig vom alten und neuen Partner, siehe Begleitung beim Partnerwechsel.

Haltet pro App mindestens fest:

1. Name, Herausgeber und Version
2. Typ: AppSource-App, PTE oder DEV-Extension
3. Wofür sie fachlich gebraucht wird und wer im Haus sie nutzt
4. Ob Quellcode und Dokumentation vorliegen
5. Ob es Abhängigkeiten zu anderen Apps gibt

Dazu kommen Schnittstellen zu Fremdsystemen (Shop, Versand, Banking, DMS), Job-Queue-Einträge und alles, was außerhalb von Business Central läuft, aber darauf zugreift. Gerade Schnittstellen sind oft schlecht dokumentiert. Mehr dazu im Ratgeber Business Central Schnittstellen: API und OData.

Schritt 2: Quellcode- und Nutzungsrechte klären

Ob ihr den Quellcode eurer PTEs bekommt, ist zuerst eine Vertragsfrage und erst danach eine technische. Klärt das, solange die Zusammenarbeit mit dem alten Partner noch läuft.

Technisch gilt: Eine kompilierte Extension (.app-Datei) ist nicht automatisch lesbarer Quellcode. Ob der Code aus einer installierten Extension heruntergeladen werden kann, steuert der Entwickler in der app.json über die Einstellung resourceExposurePolicy. Die Option allowDownloadingSource steht standardmäßig auf false. Nur wenn sie auf true gesetzt ist, lässt sich der Quellcode einer PTE zum Beispiel über die Download-Aktion auf der Seite Erweiterungsverwaltung in Business Central laden (Microsoft Learn: Ressourcenschutzrichtlinien).

Das heißt für euch: Prüft vor der Kündigung, ob der Download funktioniert. Wenn nicht, braucht ihr den Code vom alten Partner, idealerweise als vollständiges Repository mit Historie.

Fragen, die ihr vertraglich klären solltet:

1. Wem gehören die Nutzungsrechte an den individuell entwickelten Extensions?
2. Bekommt ihr den vollständigen Quellcode, und in welchem Format (Repository, Archiv)?
3. Darf ein anderer Partner den Code weiterentwickeln?
4. Welche Teile sind Standardprodukte des Partners, die er nur lizenziert und nicht herausgibt?
5. Bis wann und in welcher Form erfolgt die Übergabe?

Beispiel: Ein Partner hat eine eigene Branchenlösung als Basis-App und darauf eure Anpassungen gebaut. Dann bekommt ihr eventuell nur den Code der Anpassungen, nicht den der Basis-App. Der neue Partner muss dann wissen, ob die Basis-App weiter lizenziert werden kann.

Schritt 3: Lizenzen und CSP-Wechsel

Business Central Online wird in der Regel über einen Partner im Cloud Solution Provider (CSP) Programm abgerechnet. Wechselt ihr den Partner, müssen die Abonnements entweder auf den neuen Partner übertragen oder neu abgeschlossen werden.

Die Mechanik laut Microsoft (Stand: Oktober 2026):

1. Ihr baut eine Handelspartnerbeziehung zum neuen Partner auf. Der neue Partner erzeugt dafür im Partner Center eine Anfrage mit einem Link, den ein Administrator bei euch im Microsoft 365 Admin Center annimmt (Microsoft Learn: Handelspartnerbeziehung anfordern).
2. Ihr unterzeichnet die Microsoft-Kundenvereinbarung mit dem neuen Partner und informiert den bisherigen Partner über den Wechsel.
3. Der neue Partner stellt im Partner Center eine Übertragungsanfrage an den bisherigen Partner. Der Kunde startet die Übertragung nicht selbst.
4. Der bisherige Partner muss zustimmen. Microsoft überschreibt keine CSP-Übertragung ohne seine Genehmigung und vermittelt nicht bei Streitigkeiten. Antwortet der bisherige Partner nicht, läuft die Anfrage nach 30 Tagen ab (Microsoft Learn: Übertragung zwischen CSP-Partnern).

Daraus folgt: Der Lizenzwechsel funktioniert nur sauber, wenn der bisherige Partner mitspielt. Plant deshalb Kündigungsfristen und Laufzeiten eurer Abonnements so, dass ihr nicht unter Zeitdruck steht. Lizenzen für AppSource-Apps von Drittanbietern können eigene Verträge mit dem jeweiligen Anbieter haben. Prüft für jede App, über wen sie abgerechnet wird. Wenn ihr dabei Unterstützung braucht, hilft die Lizenzberatung für Business Central.

Schritt 4: Admin-Zugriff über GDAP neu ordnen

Partner greifen auf euren Business-Central-Tenant als delegierte Administratoren über GDAP (Granular Delegated Admin Privileges) zu. Diese Beziehung ist unabhängig von der Lizenzbeziehung und muss separat aufgebaut und beendet werden.

So funktioniert es laut Microsoft:

1. Der neue Partner erzeugt im Partner Center eine GDAP-Anfrage. Ein interner Globaler Administrator bei euch nimmt sie über den Link an (Microsoft Learn: Delegierter Administratorzugriff auf Business Central Online).
2. Als Rolle mit den geringsten nötigen Rechten empfiehlt Microsoft für Business Central den Dynamics 365 Business Central-Administrator. Ein Globaler Administrator ist für die BC-Verwaltung nicht nötig.
3. Mit GDAP lässt sich der Zugriff zeitlich begrenzen (Microsoft Learn: Einführung in GDAP). Für Übergangsphasen könnt ihr bewusst kurze Beziehungen ohne automatische Verlängerung annehmen.
4. Im Business Central Admin Center legt ihr pro Umgebung über die Einstellung Partnerzugriff (Partner access) fest, ob delegierte Administratoren überhaupt zugreifen dürfen und aus welchen Partner-Tenants (Microsoft Learn: Zugriff auf Umgebungen verwalten).
5. Die Rollen des alten Partners entfernt euer Globaler Administrator im Microsoft 365 Admin Center unter Einstellungen, Partnerbeziehungen: Partner auswählen, Rollen entfernen (Microsoft Learn: Delegierte Administratorrechte).

Wichtig dabei: Entfernt ihr die delegierten Rechte, kann der alte Partner laut Microsoft weiterhin das Abonnement im Partner Center verwalten, solange die Lizenzbeziehung besteht. Er kann sich dann aber nicht mehr an euren Umgebungen anmelden. Beide Beziehungen laufen also getrennt.

Eine Übergangsphase, in der beide Partner Zugriff haben, ist technisch möglich. Microsoft beschreibt ausdrücklich, dass Kunden mit mehreren Partnern gleichzeitig GDAP-Beziehungen haben können. Für die Übergabe ist das oft sinnvoll, sollte aber ein festes Enddatum haben.

Schritt 5: Aufräumen im Admin Center

Nach dem Wechsel bleiben Einstellungen des alten Partners im Business Central Admin Center bestehen, bis ihr sie entfernt. Microsoft listet dafür eine eigene Checkliste (Microsoft Learn: Einstellungen bereinigen):

1. Supportkontakt pro Umgebung prüfen und auf den neuen Partner ändern
2. Benachrichtigungsempfänger prüfen, damit Update-Hinweise nicht beim alten Partner landen
3. Application Insights-Schlüssel entfernen, falls der alte Partner seine Telemetrie eingerichtet hat
4. Autorisierte Microsoft Entra-Apps des alten Partners entfernen und deren Zustimmung im Entra-Tenant widerrufen

Prüft zusätzlich in jeder Umgebung die Benutzerliste. Delegierte Administratoren werden beim ersten Anmelden automatisch als Benutzer mit pseudonymem Namen angelegt. Diese Benutzer könnt ihr deaktivieren.

Übergabe-Checkliste

Diese Tabelle könnt ihr als Vorlage für das Übergabegespräch zwischen altem und neuem Partner nutzen.

Wenn ihr vor dem Wechsel eine Datensicherung außerhalb des Tenants wollt: Business Central Online kann Datenbanken als BACPAC-Datei in einen eigenen Azure-Speicher exportieren. Voraussetzung ist ein bezahltes Abonnement und eine entsprechende Berechtigung (Microsoft Learn: Datenbanken exportieren).

Typische Fallstricke

Viele Fallstricke beim Partnerwechsel sind organisatorisch, nicht technisch.

• Zu früh gekündigt: Der Vertrag ist beendet, bevor Quellcode und Dokumentation übergeben sind. Danach habt ihr kaum noch Hebel.
• Nur die .app-Datei bekommen: Ohne Quellcode kann der neue Partner die Extension nicht anpassen. Beim nächsten Breaking Change in einem Major-Update wird das zum Problem. Dazu der Ratgeber Extension nach Update nicht kompatibel.
• Lizenz und Zugriff verwechselt: GDAP entfernt heißt nicht, dass die Lizenzen umgezogen sind, und umgekehrt.
• Globaler Administrator für den Partner: Für Business Central reicht in der Regel die BC-Administrator-Rolle. Weniger Rechte heißt weniger Risiko.
• Vergessene Integrationen: Dienstkonten oder Entra-Apps des alten Partners laufen weiter, und keiner weiß, was sie tun.
• Keine Übergangsphase: Der neue Partner startet ohne Ansprechpartner für Rückfragen und muss das System komplett selbst erschließen.

Wenn ein Wechsel aus einem gescheiterten Projekt heraus passiert, kommt oft noch ein instabiles System dazu. Dann lohnt sich zuerst eine Stabilisierung, siehe BC-Projektrettung.

Häufige Fragen

Können wir den Partner wechseln, ohne dass der alte Partner zustimmt?

Beim Admin-Zugriff ja: Euer Globaler Administrator kann GDAP-Rollen des alten Partners selbst entfernen und einem neuen Partner Zugriff geben. Bei den CSP-Lizenzen nein: Eine Übertragung der Abonnements braucht laut Microsoft die Zustimmung des bisherigen Partners, sonst läuft die Anfrage nach 30 Tagen ab. Dann bleibt nur, Laufzeiten abzuwarten und neu abzuschließen.

Kannst du den Quellcode unserer Extensions aus dem System holen?

Nur wenn der Entwickler das in der Extension erlaubt hat (Einstellung „allowDownloadingSource“ auf „true“). Das kann ich in eurer Umgebung schnell prüfen, sobald ich Zugriff habe. Ist der Download gesperrt, braucht ihr den Code vom bisherigen Partner, und ob er ihn herausgeben muss, regelt euer Vertrag.

Brauchen wir während des Wechsels zwei Partner gleichzeitig?

Nicht zwingend, aber eine kurze Überlappung ist oft sinnvoll. Mehrere GDAP-Beziehungen parallel sind technisch vorgesehen, und über die Einstellung Partnerzugriff im Admin Center steuert ihr pro Umgebung, welcher Partner rein darf.

Kannst du den Wechsel begleiten, ohne selbst unser neuer Partner zu werden?

Ja. Ich mache Bestandsaufnahme, Code-Bewertung und Übergabedokumentation als unabhängiger Entwickler und bin während der Einarbeitung Ansprechpartner für technische Rückfragen. Lizenzen verkaufe ich nicht, die laufen über euren CSP-Partner.

Wann ich helfen kann

Ich unterstütze euch, wenn ihr vor einem Partnerwechsel wissen wollt, was in eurem System steckt: Apps und PTEs inventarisieren, Quellcode und Upgrade-Fähigkeit bewerten, Schnittstellen dokumentieren und die Übergabe an den neuen Partner vorbereiten. Mehr dazu auf der Seite unabhängige Begleitung beim BC-Partnerwechsel. Wenn ihr zwischen zwei Partnern akut Hilfe braucht, gibt es Support ohne Vertrag: zum Festpreis oder nach Aufwand ab 120 €/h, mit erster Diagnose innerhalb von 48 Stunden.

Erstgespräch buchen