Move Resources Between Projects

[bmertens-datum]

Proposal: Move resources between projects

There’s currently no clean way to move a resource from one project to another. If something ends up in the wrong project—or a customer wants to reorganize—users have to recreate the resource manually. This adds friction and increases the chance of configuration mistakes.

This discussion outlines a simpler move operation.

---

Who can move a resource?

• Project admins (source and destination)
• Organization admins and owners

All moves should be audited.

---

What should be movable?

Initial candidates:

• Config objects (policies, secrets, variables)
• Networking objects (domains, proxies, routing rules)

Additional resource types may be included as we define clear rules.

---

Proposed workflow

1. Select a resource → Move to Project
2. Choose the destination project
3. System validates:
   • Quotas in the target project
   • Required features enabled
   • Dependency and relationship checks
4. User confirms
5. Resource is moved

---

RBAC and billing behavior

• Resource adopts the destination project’s RBAC and inherited org policies.
• If a resource references identities not available in the target project, we need a clear strategy (strip, warn, or block).
• Future usage/billing counts toward the destination project; historical usage does not change.

---

Failure handling

• If validation fails, block the move with actionable errors.
• If the move fails mid-process, roll back to the original project.

---

Open questions

• Which resource types should be supported first?
• Which resources cannot be moved due to dependencies, identity bindings, system-level constraints, or other limitations?
• Should we support bulk moves?
• Should the UI provide a preview of what will change before moving?

---

Feedback welcome

Looking for input on scope, risks, and any resource types that need special handling.