Zusammenfassung

  • Der Wechsel eines Google-Cloud-Projekts in eine andere Organisation erhält die Verknüpfung mit dem bisherigen Rechnungskonto. Geerbte Zugriffsrechte ändern sich dagegen.
  • Aktive Bestellungen aus dem direkten Kauf bei Cloud Marketplace benötigen für den Kontowechsel die Zustimmung von Kunde und Softwareanbieter. Der Vorgang kann eine Woche oder länger dauern.
  • Ein Kauf beim selben Anbieter über das Zielkonto während der Übertragung macht diese undurchführbar. Der Einkauf gehört deshalb in den Übergabeplan.

Die sauberste Trennung steht oft im Organigramm. Bei Google Cloud lässt sich ein Projekt einer neuen Organisation zuordnen, während das bisherige Rechnungskonto weiter für seine Dienste aufkommt. Der Auszug ist administrativ vollzogen. Wirtschaftlich läuft noch ein Dauerauftrag aus dem alten Zuhause.

Google beschreibt diese Trennung ausdrücklich in seiner Dokumentation zur Projektmigration. Der Organisationswechsel aktualisiert die Metadaten des übergeordneten Elements. Projekt-ID, Projektnummer, Daten und Ressourcen bleiben erhalten, ebenso direkt am Projekt vergebene IAM-Rollen. Das bisherige Rechnungskonto bleibt verknüpft. Cloud-Billing-Konten können Projekte über Organisationsgrenzen hinweg finanzieren.

Bei einem Unternehmensverkauf ist das ein erheblicher Unterschied. Wer das Projekt im eigenen Organisationsbaum sieht, hat dessen neue administrative Position bestätigt. Ob der Käufer auch die laufende Finanzierung und die benötigten Softwarekäufe übernommen hat, muss anderswo entschieden werden. Ein grünes Häkchen im Migrationsplan kann diese Entscheidungen gut verdecken.

Die Rechnung ist eine Betriebsbedingung

Damit die Abrechnung eines Projekts aktiviert ist, muss das verknüpfte Konto aktiv und ordnungsgemäß geführt sein. Wird es geschlossen oder gesperrt, lassen sich die aktivierten Dienste nicht nutzen – auch solche, die die Bedingungen für kostenlose Nutzung erfüllen. So steht es im Leitfaden zum Wechsel der Projektabrechnung.

Das alte Konto ist damit mehr als ein nachlaufender Buchhaltungseintrag. Solange es finanziert, bleibt sein Zustand eine Voraussetzung für den Betrieb. Die neue Organisation kann das Projekt bereits verwalten und trotzdem von dieser Finanzierung abhängen. Wer bezahlt, erhält dadurch allerdings keine zusätzlichen IAM-Rechte; Zahlungsbeziehung und Zugriffsberechtigung sind unterschiedliche Verbindungen.

Auch bei den Rechten zieht nicht alles gemeinsam um. Von der alten Organisation geerbte IAM-Berechtigungen gehen verloren, Richtlinien der Zielorganisation greifen. Direkt vergebene Projektrollen bleiben. Der Fortbestand der Ressourcen beantwortet deshalb noch nicht, welche Zugriffswege und Abhängigkeiten einer Anwendung unter den neuen Regeln funktionieren.

Der Leitfaden zu Migrationsrollen trennt die Befugnis zum Verschieben von Projekten von den Voraussetzungen für den Wechsel des Rechnungskontos. Für Letzteren nennt er unter anderem Billing Account User auf dem Zielkonto und Project Billing Manager am Projekt. Die spezielle Abrechnungsdokumentation führt zusätzlich die erforderlichen Rechte zum Einsehen, Trennen und Verknüpfen auf. Ein Projekt verschieben zu dürfen heißt also nicht automatisch, das neue Konto belasten zu dürfen.

Wenn ein neuer Kauf den alten Vertrag blockiert

Noch deutlicher wird die verteilte Entscheidungsmacht bei Marketplace-Software. Die Abrechnungsanleitung verlangt, mit dem Projekt verbundene Marketplace-Käufe vor dem Wechsel seiner Abrechnung zu übertragen. Die Marketplace-Abrechnungsregeln setzen voraus, dass das Zielkonto die benötigten Ressourcen gekauft hat; fehlen Käufe, zeigt die Konsole Warnungen. Ein Projekt kann jeweils nur mit einem Rechnungskonto verbunden sein.

Für direkt bei Cloud Marketplace gekaufte Produkte enthält das Verfahren zur Übertragung aktiver Bestellungen mehrere Zustimmungsstufen. Der Kunde benötigt die Rolle Billing Account Administrator und wendet sich an den unabhängigen Softwareanbieter. Stimmt dieser zu, stellt er den Antrag bei Google. Google bearbeitet ihn und verschickt E-Mails zur Genehmigung. Erst wenn alle Beteiligten zustimmend geantwortet haben, wird die Übertragung abgeschlossen und bestätigt.

Dafür kann laut Google eine Woche oder mehr vergehen. Eine garantierte Höchstdauer von sieben Tagen ergibt sich daraus nicht. Außerdem muss die Übertragung im jeweiligen Fall durchführbar sein. Zusätzliche Administratorrechte ersetzen keine fehlende Zustimmung des Anbieters.

Eine weitere Regel verdient einen Platz direkt neben der Bestellfreigabe: Kauft das Zielkonto während der laufenden Übertragung ein Produkt desselben Anbieters, wird die Übertragung undurchführbar. Es geht um denselben Anbieter, nicht nur um denselben Artikel.

Gerade der Wunsch nach schneller Selbstständigkeit kann hier die Übergabe behindern. Der Einkauf will die neue Firma mit eigenen Bestellungen versorgen, während die Übergabemannschaft bestehende Bestellungen zu ihr bringen will. Beide Aufgaben klingen vernünftig. Ihre Reihenfolge entscheidet, ob der zweite Weg noch offensteht. Das ist kein Problem, das die IT-Abteilung durch eine längere Nachtschicht lösen kann.

Zurückbleibende Projekte verlieren mitunter den Rabatt

Nach dem Wechsel des Rechnungskontos verschwinden alte Kosten nicht schlagartig. Vor dem Wechsel entstandene Gebühren werden dem bisherigen Konto belastet, auch wenn sie noch nicht gemeldet worden sind. Die Meldung kann je nach Dienst bis zu zwei Tage dauern. Es handelt sich um verspätet gemeldete alte Nutzung, nicht um zwei weitere Tage neuer Nutzung auf Rechnung des Verkäufers.

Daneben bestehen Kosten, die auf Kontoebene anfallen und keinem einzelnen Projekt zugeordnet sind, etwa Support. Die abgearbeitete Projektliste ist daher kein Nachweis eines kostenfreien Restkontos.

Der Leitfaden nennt auch Folgen für gemeinsam genutzte Preisvorteile. Ressourcenbasierte Compute-Engine-Zusicherungen im Projekt, dessen Abrechnung wechselt, entfalten ihre Rabatte im Zielkonto. Projekte des alten Kontos profitieren dann nicht mehr von diesen Zusicherungen. Wie weit die Rabatte im Zielkonto geteilt werden, bestimmt dessen Konfiguration. So kann ein Bereich, der überhaupt nicht verkauft wird, einen bisher einkalkulierten Vorteil verlieren.

Bei Cloud Armor Enterprise Annual hängt die Einstufung ebenfalls am Konto: Fehlt dem Zielkonto das entsprechende Jahresabonnement, fällt das bisher teilnehmende Projekt auf Standard zurück. Unveränderte Ressourcen können somit unter anderen kaufmännischen Bedingungen weiterbestehen.

Die alte Finanzierung kann Absicht sein

Google hat diese wirtschaftliche Seite in einem Beitrag zur Abspaltung von Unternehmen vom 2. Mai 2023 behandelt. An den ausdrücklich hypothetischen Firmen RemainCo und NewCo erläutert der Text, weshalb das ursprüngliche Rechnungskonto weiter finanzieren kann: Ein bestehender Vertrag mit Abnahmeverpflichtungen soll erfüllt werden. Aktionsguthaben und Supportpakete erstrecken sich ebenfalls nicht automatisch auf die neue Firma oder deren Konto.

Eine fortgesetzte Zahlung aus dem alten Konto kann also eine gewollte Brücke sein. Sie ist wirtschaftlich etwas anderes als eine vergessene Zuständigkeit, obwohl die Verknüpfung im System gleich aussieht. Entscheidend sind die Vereinbarung über Kosten und Verantwortung sowie ein ausführbarer Ausstieg.

Für die Beurteilung einer konkreten Übergabe fehlen die jeweiligen IAM-Rechte, Kontoverknüpfungen, Käufe und Genehmigungen; die öffentlichen Regeln enthalten keine solchen Kundenakten.

Die Regeln zeigen aber, wer den Abschluss mittragen muss. Der Projektverantwortliche bestätigt die administrative Übergabe. Der neue Zahler akzeptiert die Finanzierung. Der Anbieter stimmt der Bestellübertragung zu. Erst im Zusammenspiel wird daraus eine belastbare Übernahme. Die neue Position im Organisationsbaum allein bescheinigt vor allem eines: Jemand hat das Projekt an die richtige Stelle geschoben.