Hallo Sandro,
es geht theoretisch auch über ein Script - aber dann musst Du dir die GID des Quelldatensatzes merken und auf dem Zieldatensatz mit adaptGid und force=true die alte GID erzwingen.
ABER dann hast Du dieselbe GID für zwei Datensätze in der Registry stehen - es kann sein, dass das nicht geht. Und selbst wenn es geht, besteht das hohe Risiko für Folgeprobleme.
Wenn das funktionieren sollte, dann ist es auf jeden Fall ratsam, nachdem alles umgezogen wurde und funktioniert, die GIDs in den alten Tabellen mit zufälligen GIDs zu überschreiben - das müsste mit adaptGid(Schema schema, List<Entity> elements, boolean force) funktionieren (wieder force = true)
--> also Ja auf die abschließende Frage von Dir 
Wenn das nicht funktioniert, wird es komplizierter. Dann müsstest Du erst die alte GID überschreiben und dann die Neue anpassen. Das wäre aber ein sehr risikoreiches Vorgehen. Bitte dabei unbedingt für Backups sorgen.
Ich würde, wenn es irgendwie geht, dafür sorgen, dass die Schemata aus den Landesprojekten niemals im globalen Projekt sichtbar werden. Also die Datensätze mit Datenbankmitteln transportieren. Zumindest, wenn das Vorgehen mit dem temporär doppelten GIDs nicht funktioniert. Und die Wahrscheinlichkeit dafür sehe ich als hoch an...
Das ist jetzt eine der Stellen, die ich mit meinem " Ich kann nicht ausschließen, dass ich etwas übersehen habe" meinte - das die Tabellen aus den Landesprojekten auch im globalen Projekt zur Verfügung stehen, hatte ich nicht auf dem Schirm.
Und eine weitere "Unschönheit" gibt es noch: FirstSpirit nutzt ja eine temporale Datenhaltung für die Datensätze. Das bedeutet, dass jede Änderung an einem Datensatz dazu führt, dass ein neuer Datensatz angelegt wird und die bisherige Version als "veraltet" gekennzeichnet wird. Das sollte auch passieren, wenn die GID über adaptGid(force=true) angepasst wird.
ABER alle alten Datensatz-Versionen haben noch die alte GID. Wenn man eine alte Version eines Datensatzes wieder herstellt, wird es wahrscheinlich zu einer GID mismatch Exception kommen [evtl. auch erst, wenn die alte Version das erste Mal gelesen wird, nachdem Sie nicht mehr im Cache ist]. Um die damit möglicherweise auftretenden, zukünftigen Probleme zu verhindern, könnt Ihr noch überlegen, die alten Datensatzversionen direkt in der Datenbank zu löschen. Diese sind daran zu erkennen, dass der Wert der Spalte FS_VALID_TO kleiner ist als 9223372036854775807. Wenn man diese Datensätze in der Datenbank löschen würde, würde man auch Freigabeversionen mit erwischen, die die falsche GID haben. Danach müssten dann alle Datensätze einmal über FirstSpirit freigegeben werden. Hier muss aber natürlich fachlich entschieden werden, ob das überhaupt möglich ist [ich tippe aber darauf, dass die Antwort Ja ist, da Du ja nur die aktuelle Version in deinem Skript migrierst].
Ein wichtiger, allgemeiner Hinweis (insbesondere an alle, die hier mitlesen):
Wenn man adaptGid mit force=true aufruft, macht man "normalerweise" alle Referenzen auf die entsprechenden Datensätze kaputt, da man die von FirstSpirit vergebenen GIDs manuell überschreibt. Bei der Migration der Datensätze willst Du aber genau dies erreichen (vorhandene Referenzen auf die entsprechende GID umbiegen), und bei dem Ansatz zur Vermeidung von Folgeproblemen geht es um Datensätze, die danach nicht mehr benötigt werden (wenn ich alles richtig verstanden habe). Für Datensätze, die man weiterhin nutzen will, ist adaptGid mit force=true hingegen eine ganz dumme Idee. [Nur als Hinweis, damit hoffentlich niemand auf die Idee kommt, dass standardmäßig zu setzen!]
Viele Grüße
Holger