Authority transfer
Move seven control planes in a reversible order
Prefer native organization and project transfer where supported. When migration is required, prove the new path before revoking the old one.
Repository and history
Transfer the canonical source, branches and release evidence.
- Move
- Repository, issues, actions and package access
- Risk
- Source export omits history and automation
- Accept
- New owner builds a clean checkout
Hosting and builds
Recreate or transfer deployment configuration and limits.
- Move
- Project, environments, domains and build identity
- Risk
- Seller account remains production owner
- Accept
- New owner deploys and rolls back
Data and storage
Move authoritative records, files and recovery capability.
- Move
- Database, objects, jobs, retention and backups
- Risk
- Repository transfer leaves live data behind
- Accept
- Counts, integrity and restore checks
Providers and identity
Transfer email, payments, auth, analytics and APIs.
- Move
- Organizations, roles, billing and verified domains
- Risk
- Personal provider account cannot transfer
- Accept
- Owner completes a real sandbox journey
Secrets and access
Issue new credentials and revoke seller access safely.
- Move
- Secret metadata, workload identity and admin roles
- Risk
- Old credentials stay valid indefinitely
- Accept
- Rotation and denied old access
Domain and communication
Coordinate DNS, certificates and stakeholder messages.
- Move
- Registrar, DNS, support and status ownership
- Risk
- Cutover breaks an undocumented service
- Accept
- External checks and rollback window
Operating knowledge
Transfer the response procedures, not only configuration.
- Move
- Runbooks, alerts, incidents, quotas and known debt
- Risk
- New owner learns from the first outage
- Accept
- Observed owner-led operation session
Operating principle
Transfer capability, then remove dependency
A technically complete transfer leaves the recipient able to deploy, recover, support and change the product without seller intervention. That capability should be demonstrated in a controlled acceptance session.
Keep the old path only for the agreed rollback and support window. Then remove stale accounts, rotate credentials and preserve an auditable record of what moved and what remains.
- Use organization-owned accounts
- Test a clean deployment
- Reconcile live data
- Revoke old authority deliberately
Applied example
Transfer example: repository moved, auth did not
A buyer receives the Git repository and Vercel project. Production authentication still belongs to the seller’s personal provider tenant and cannot be administered by the buyer.
- The visible site keeps working
- A critical control plane did not transfer
- Future incidents and user recovery depend on the seller
- The handover acceptance was limited to deployment
Plain answers
Questions to resolve before shipping
Should we transfer accounts or recreate them?+
Prefer provider-supported organization or project transfer when it preserves evidence and ownership. Recreate only with a tested migration plan.
When should seller access be removed?+
After the recipient has accepted control and any agreed rollback or transition window ends; consequential credentials should then rotate.
Is a ZIP file a source-code handoff?+
It may contain code, but usually omits history, issues, automation, package access, release evidence and operational ownership.