Neu Datenbank Merge

[dkzg]

Einige von euch kennen es sicher bereits.
Man wächst. Man braucht einen weiteren Mandanten, will aber keinen neuen SQL Server installieren. Nach einiger Zeit wird der neue Mandant zum Hauptmandanten und gegebenenfalls in eine eigene Firma ausgelagert.

Nun ist es so, dass Mandant_X ohne die ursprüngliche easybusiness nicht lauffähig ist.
IN der easybusiness liegt beispielsweise die Benutzer- und Rechteverwaltung, die in Mandant_X fehlt.

Datenschutz würde es hier verbieten, die easybusiness einfach so zu übertragen / zu kopieren.

Hat jemand von euch schon einmal die entsprechenden Verwaltungsdaten übertragen und Mandant_X in easybusiness umgewandelt?

In einem Demosystem habe ich das bereits einmal geschafft, suche aber nach Austausch, um sicherzugehen, nichts zu übersehen, bevor ich an die Produktiv-DB gehe.

 

[recent.digital]

Wir haben einen Mandantenabgleich entwickelt, der könnte ggf. in das Szenario passen. Falls Interesse besteht gerne einfach mal privat anschreiben und einen Termin mit einem unseren Techniker vereinbaren und einfach mal über das vorhaben sprechen.

So oder So: Viel Erfolg

 

[IT-Schober]

@dkzg ich würde das nicht als klassischen „Merge“ behandeln, sondern eher als Mandanten-Extraktion mit neuer Basis-eazybusiness.
Der kritische Punkt ist nicht nur Benutzer/Rechte. Je nach Wawi-Version hängen da auch Mandantenverwaltung, Dienste/Worker-Kontext, Vorlagen, Workflows, Nummernkreise, ggf. Benutzerzuordnungen und diverse interne IDs dran. Wenn man da nur einzelne Tabellen rüberkopiert, läuft es im ersten Moment oft, aber später knallt es dann an eher unschönen Stellen.
Ich würde das Vorgehen immer in einer 1:1-Testumgebung machen: gleiche Wawi-Version, alle beteiligten Datenbanken sichern, Zielsystem frisch aufsetzen, dann Mandant_X dort sauber als Hauptmandant lauffähig bekommen und danach wirklich alle Kernprozesse testen: Login/Rechte, Abgleich, Worker, Druck/Mail, Workflows, Ameise, Zahlungen/Versand, Nummernkreise.
Wichtig ist auch der Datenschutzpunkt: wenn aus der alten easybusiness nur technische Verwaltungsdaten übernommen werden sollen, muss man sehr genau trennen, ob irgendwo Benutzerhistorien, Log-/Auditdaten oder alte Mandantenbezüge mitwandern. Da würde ich lieber einmal zu viel selektieren als die komplette Basis-DB mitzunehmen.
Direkt produktiv würde ich da nichts anfassen. Erst ein reproduzierbares Skript/Protokoll aus dem Demosystem bauen, dann gegen eine aktuelle Kopie laufen lassen und Diff/Checks machen. Sonst sucht man nachher bei Folgefehlern ewig, ob es an Daten, Version oder Dienstkontext liegt.
Welche Wawi-Version ist das bei dir genau und reden wir von einem klassischen zweiten Mandanten auf derselben SQL-Instanz oder wurde da schon mal historisch migriert/umbenannt?
VG Lukas

 

[dkzg]

@dkzg ich würde das nicht als klassischen „Merge“ behandeln, sondern eher als Mandanten-Extraktion mit neuer Basis-eazybusiness.
Der kritische Punkt ist nicht nur Benutzer/Rechte. Je nach Wawi-Version hängen da auch Mandantenverwaltung, Dienste/Worker-Kontext, Vorlagen, Workflows, Nummernkreise, ggf. Benutzerzuordnungen und diverse interne IDs dran. Wenn man da nur einzelne Tabellen rüberkopiert, läuft es im ersten Moment oft, aber später knallt es dann an eher unschönen Stellen.
Ich würde das Vorgehen immer in einer 1:1-Testumgebung machen: gleiche Wawi-Version, alle beteiligten Datenbanken sichern, Zielsystem frisch aufsetzen, dann Mandant_X dort sauber als Hauptmandant lauffähig bekommen und danach wirklich alle Kernprozesse testen: Login/Rechte, Abgleich, Worker, Druck/Mail, Workflows, Ameise, Zahlungen/Versand, Nummernkreise.
Wichtig ist auch der Datenschutzpunkt: wenn aus der alten easybusiness nur technische Verwaltungsdaten übernommen werden sollen, muss man sehr genau trennen, ob irgendwo Benutzerhistorien, Log-/Auditdaten oder alte Mandantenbezüge mitwandern. Da würde ich lieber einmal zu viel selektieren als die komplette Basis-DB mitzunehmen.
Direkt produktiv würde ich da nichts anfassen. Erst ein reproduzierbares Skript/Protokoll aus dem Demosystem bauen, dann gegen eine aktuelle Kopie laufen lassen und Diff/Checks machen. Sonst sucht man nachher bei Folgefehlern ewig, ob es an Daten, Version oder Dienstkontext liegt.
Welche Wawi-Version ist das bei dir genau und reden wir von einem klassischen zweiten Mandanten auf derselben SQL-Instanz oder wurde da schon mal historisch migriert/umbenannt?
VG Lukas

Ich hab das mit meinem Testmandanten gemacht. Dabei habe ich jedoch nicht vom Mandanten in eazybusiness kopiert, sondern nur die Steuertabellen aus eazybusiness. Dann wurde der Mandant umbenannt und in den Steuertabellen wurde alles vom Mandanten auf eazybusiness geändert.
Das ist mittlerweile 4 Wochen her und jede aktuelle Transaktion lassen wir da in Kopie mitlaufen. Und ja, es waren nicht nur 3-4 Tabellen, sondern über ein Dutzend, Dutzende Stellen, wo das ersetzt werden musste. Könnte man nun theoretisch so scripten, dass es automatisch geht, ist bei den ganzen Datenbankänderungen mit jeder Version hier Handarbeit wohl sicherer.
Zum Neujahr werde ich das wohl angehen und den Produktivmandanten umstellen.

 

[bobyson90]

Der Ansatz über die Steuertabellen ist definitiv sauberer, als blind ganze Datenbanken zu klonen. Ein Punkt, der bei solchen Umbenennungen auf SQL-Ebene gerne übersehen wird, sind hartcodierte Datenbanknamen in alten Stored Procedures, Views oder Triggern sowie die Lizenzzuordnung im JTL-Kundencenter. Vor dem Produktiv-Switch zum Jahreswechsel sollte man außerdem prüfen, ob die internen kMandant-IDs in den Hintergrunddiensten wie dem Worker oder externen JTL-Shipping-Anbindungen überall sauber auf die neue Basis zeigen, sonst laufen Abgleiche nach der Umstellung im Hintergrund ins Leere.