Transfer project resources
Move ownership with dependency validation, source audit history, and credential boundaries.
A project transfer changes resource ownership within an organization through a
reviewed dependency bundle. It is not an arbitrary edit of project_id.
Resolve a bundle
Open Project → Resources → Transfer, select the root resources, and choose a destination project. The requester must have transfer permission in both projects. A cross-organization move requires export and recovery rather than this workflow.
The preview includes droplet configuration, attached volumes, interfaces, placement-group references, and applicable recovery policies. A shared network or load balancer serving resources outside the bundle cannot silently change owner. Replace that dependency or include its complete transferable set.
Destination validation
The destination must permit the region, image source, storage policy, encryption domain, and requested capacity. Its quota is checked before ownership changes. A transfer cannot borrow the source project's region exception or budget policy.
Project secrets, API keys, and role bindings do not move with workload ownership. Select destination secret references explicitly. The preview marks any resulting integration that will be disabled until credentials are replaced.
Execution
Stop new lifecycle changes to the selected resources while the transfer holds its dependency locks. Running droplets can remain running only for a transfer mode that preserves every active network and storage reference. Otherwise the plan requires a stopped cutover.
The operation records the ownership transition and per-resource outcome. It retains a source-to-destination mapping when replacement resources are required. Do not use a partially completed bundle until the result confirms which project owns each dependency.
History and visibility
Both projects receive a transfer audit event. Existing source audit events remain under source access and retention; a destination operator does not gain access to unrelated source history. Resource configuration history follows the resource where the transfer mode preserves its ID.
Source team permissions stop applying to the transferred resource after ownership is applied. Existing guest accounts and application credentials remain inside the guest until explicitly rotated. Project access removal is not guest key removal.
Failed transfer and cleanup
Preflight rejection leaves ownership unchanged. A failure after external changes can leave retained destination artifacts that the result identifies. Resume or cleanup uses the original bundle rather than a new unreviewed target list.
Review backup selection, alert routing, cost-allocation labels, and blueprint ownership after completion. A saved selector in the source project can cease matching without a replacement destination policy being created automatically. Use Projects API and configuration history for ownership and revision inspection.