Кратко

  • При переносе проекта Google Cloud в другую организацию связь с прежним платежным аккаунтом сохраняется, а унаследованные права доступа меняются.
  • Перенос активного заказа, купленного напрямую в Cloud Marketplace, требует согласия клиента и поставщика ПО; процедура может занять неделю и больше.
  • Покупка продукта того же поставщика через целевой аккаунт во время переноса делает перенос невозможным. Согласовать нужно не только доступ, но и очередность закупок.

У бухгалтерии бывает своя версия корпоративной независимости. Проект уже числится в новой организации Google Cloud, а расходы по-прежнему приходят на старый платежный аккаунт. В отчете о разделении бизнеса стоит галочка. В платежных отношениях разделение еще не произошло.

Так устроен сам перенос. Согласно документации Google Cloud, он меняет метаданные родительского ресурса проекта. Идентификатор, номер, данные и ресурсы сохраняются, как и роли IAM, выданные непосредственно на уровне проекта. Платежный аккаунт остается прежним. Cloud Billing позволяет финансировать проекты разных организаций через один аккаунт.

Поэтому акт технической передачи может оказаться гораздо уже экономического результата, которого ждут стороны сделки. Администратор переместил проект. Покупатель бизнеса еще не обязательно принял его расходы. Поставщик программы может пока не согласиться передать заказ. Все три решения относятся к одной работающей системе, но принимают их разные люди.

Право переместить не дает права потратить

Права доступа тоже не переезжают единым пакетом. Проект теряет права IAM, унаследованные от исходной организации, и оказывается под политиками новой. Прямо назначенные роли сохраняются. Наличие тех же ресурсов после переноса само по себе не отвечает на вопрос, сохранятся ли необходимые приложению пути доступа и зависимости при новых правилах.

В руководстве по ролям для миграции полномочия на перенос проекта отделены от полномочий на смену платежного аккаунта. Для второй задачи среди прочего указаны Billing Account User на целевом аккаунте и Project Billing Manager на проекте. Специализированное руководство по биллингу дополнительно раскрывает права на просмотр, отключение старой связи и создание новой. Администратор, способный изменить место проекта в иерархии, не получает автоматически права обязать другой аккаунт оплачивать его работу.

Связь с плательщиком имеет прямое эксплуатационное значение. Правила настройки биллинга проекта требуют, чтобы связанный аккаунт был активным и находился в надлежащем состоянии. Если он закрыт или приостановлен, включенные сервисы использовать нельзя, даже когда они отвечают условиям бесплатного использования.

Старая компания может таким образом продолжать обеспечивать финансовое условие работы проекта, который административно уже передан. Сам факт оплаты не дает ей прав IAM на управление. Существенна именно возможность разделить эти роли: одна сторона управляет ресурсом, другая поддерживает его финансирование.

Письмо поставщику становится частью передачи

Покупки программ добавляют еще один уровень согласования. Руководство по биллингу требует сначала перенести покупки Marketplace, связанные с проектом, а затем менять его платежный аккаунт. Документация Marketplace требует наличия необходимых приобретенных ресурсов на целевом аккаунте и описывает предупреждения консоли о недостающих покупках. Одновременно проект связан только с одним платежным аккаунтом.

Для продуктов, приобретенных напрямую в Cloud Marketplace, порядок переноса активных заказов начинается с обращения клиента к независимому поставщику ПО. Запрашивающему нужна роль Billing Account Administrator. Если поставщик согласен, он направляет запрос Google. Google обрабатывает его и рассылает письма для утверждения; все участвующие стороны должны ответить согласием. После завершения переноса приходит подтверждение.

Google предупреждает, что процесс может занять неделю и больше. Неделя здесь не обещанный предельный срок. Перенос должен также оставаться выполнимым при конкретных условиях. Ни один дополнительный набор прав администратора не заменит ответ поставщика.

Особенно занятно ограничение на действия принимающей стороны. Если во время переноса целевой аккаунт покупает продукт того же поставщика, перенос становится невозможным. Речь идет о поставщике, а не только о повторной покупке точно такого же продукта.

Желание поскорее снабдить новую компанию собственными закупками способно перекрыть ей путь к уже существующему заказу. Отдел закупок работает на самостоятельность, команда передачи работает на сохранение приобретенных прав, и обе могут честно отчитаться об активности. Совместного результата при этом не будет, если очередность действий разрушает условия переноса. Здесь полезнее согласованный календарь, чем призыв к технической команде ускориться.

Расходы запаздывают, скидки уходят

При смене платежного аккаунта начисления за использование до изменения остаются на прежнем аккаунте. Это касается и расходов, которые еще не поступили в отчетность. В зависимости от сервиса передача сведений может занять до двух дней. Задерживается отражение старого использования; два дополнительных дня нового использования на прежнего плательщика из этого правила не следуют.

На уровне аккаунта существуют и затраты, не закрепленные за отдельным проектом, например Support. Перечень успешно переданных проектов не показывает автоматически все оставшиеся финансовые обязательства.

А преимущества могут переместиться вместе с обязательствами. Для ресурсных обязательств Compute Engine, находящихся в проекте со сменившимся платежным аккаунтом, скидки применяются в целевом аккаунте. Проекты старого аккаунта перестают пользоваться этими обязательствами. Дальнейшее распределение скидок зависит от настроек совместного использования в новом аккаунте. Бизнес, который остался у продавца, может лишиться части скидки, хотя его собственные проекты никто не переносил.

Есть и конкретный пример изменения плана обслуживания. Если в целевом аккаунте отсутствует годовая подписка Cloud Armor Enterprise Annual, проект, участвовавший в ней, возвращается к Standard. Ресурсы сохранились, коммерческие условия вокруг них поменялись.

Иногда прежний плательщик нужен по договоренности

Google рассмотрела эту возможность в материале о разделении компаний от 2 мая 2023 года. На примере вымышленных RemainCo и NewCo компания объясняет, почему исходный аккаунт может продолжать финансирование ради исполнения существующего договора с обязательствами по потреблению. Промокредиты и пакеты поддержки также не распространяются автоматически на новую компанию или новый аккаунт.

Сохранение плательщика бывает осознанным переходным решением. Его экономический смысл отличается от забытой после переезда связи, хотя система может отображать одинаковую конфигурацию. Разница в согласованных обязанностях: кто несет расходы, как стороны рассчитываются и какое событие завершает переход.

Для оценки конкретной передачи нужны ее настройки IAM, связи биллинга, покупки и записи согласований; публичные документы не содержат такого клиентского досье.

Зато состав участников приемки виден уже из правил. Администратор отвечает за перемещение и доступ, финансовая сторона принимает расходы, поставщик согласует то, что требует его согласия. Только совместно эти решения обеспечивают передачу работающего бизнеса на принятых условиях. Новый адрес проекта хорошо смотрится на схеме. У счета за его работу память дольше, чем у презентации о завершенной сделке.