Kann ich den Partner mitten im Projekt wechseln?

Ja, und manchmal ist es die einzig richtige Entscheidung. Ein Partnerwechsel im laufenden Projekt ist kein Neustart bei null: Ein erfahrenes Team übernimmt dort, wo das Projekt steht, sichert zuerst das Vorhandene, Daten, Konfiguration und Wissen, und stellt dann die Steuerung neu auf. Entscheidend ist ein senior-geführter Übergang.

Wann ist ein Wechsel sinnvoll?

Ein Wechsel ist sinnvoll, wenn zwei Dinge zusammentreffen: Termine und Budget laufen aus dem Ruder, und das bestehende Setup adressiert die Ursachen nicht. Der zweite Teil ist der entscheidende. Verzug allein rechtfertigt keinen Wechsel, denn jeder Wechsel kostet Einarbeitung und Zeit. Erst wenn erkennbar ist, dass dieselben Fehler weiterlaufen, kippt die Rechnung.

Drei Signale, die wir in der Praxis regelmäßig sehen: Der Statusbericht weicht spürbar von dem ab, was die Fachbereiche erleben. Entscheidungen bleiben über mehrere Gremienrunden liegen, ohne dass jemand sie an sich zieht. Und die Besetzung wechselt, ohne dass Wissen übergeben wird. Wo alle drei zusammenkommen, ist die Frage nicht mehr ob, sondern wie geordnet.

Was Sie vorher tun sollten: eine nüchterne Standortbestimmung, typischerweise zwei bis vier Wochen. Sie zeigt, ob es ein Partnerproblem, ein Governance-Problem oder ein Datenproblem ist. Diese drei brauchen völlig verschiedene Antworten, und nur bei einem davon hilft ein neuer Partner.

Wie läuft ein sauberer Übergang ab?

Ein sauberer Übergang beginnt mit dem Sichern des Bestands, nicht mit Weiterbauen. Konkret heißt das: Zugriff auf alle Umgebungen, den Quellcode der Erweiterungen, die Konfigurationspakete und die Dokumentation, solange der bisherige Partner noch im Boot ist. In Business Central sind Umgebungen und Berechtigungen über das Admin Center geregelt, und dieser Zugriff sollte vertraglich geklärt sein, bevor die Zusammenarbeit endet.

Quelle: Microsoft Learn: Managing production and sandbox environments in the admin center

Danach folgt die Aufnahme des Ist-Stands: Welche Prozesse laufen produktiv, welche Anpassungen gibt es, welche offenen Punkte sind dokumentiert und welche nur bekannt. Diese Bestandsaufnahme ist der Punkt, an dem sich ein geordneter Übergang von einem Bruch unterscheidet. Wir setzen dafür in der Regel zwei bis drei Wochen an.

Erst dann wird Verantwortung übernommen, schrittweise: zuerst die Steuerung, dann die Lieferung, zuletzt die Weiterentwicklung. Ein Übergang, der alles gleichzeitig übernimmt, produziert genau die Lücken, die man vermeiden wollte.

Wo liegt das eigentliche Risiko?

Das eigentliche Risiko liegt nicht im Wechsel, sondern in einem Wechsel auf ein Team ohne Senior-Verantwortung. Wer ein Projekt in Schieflage übernimmt, muss Entscheidungen treffen können, die vorher liegen geblieben sind. Ein Team, das nur Kapazität liefert, verschiebt das Problem um einige Monate und verbraucht dabei das Vertrauen, das ein zweiter Anlauf noch gebraucht hätte.

Das zweite Risiko ist der Wissensverlust. Wenn der bisherige Partner ohne strukturierte Übergabe geht, wandern die Gründe für frühere Entscheidungen mit ihm. Genau diese Gründe braucht man später: Warum wurde dieser Prozess so gebaut, welche Anforderung stand dahinter, was wurde bewusst weggelassen. Ohne diese Antworten baut das neue Team Vermutungen ein.

Business Central bleibt in beiden Fällen das Zielsystem. Was sich ändert, ist die Steuerung, und die bleibt auf Ihrer Seite. Ein Partnerwechsel, der die Steuerung wieder an einen Dienstleister abgibt, wiederholt den Ausgangsfehler.