Service-account custody changes safely when the buyer identifies the controlling identity, establishes replacement access, verifies it, and then directs removal of obsolete access.
Map control before changing access
For every provider, record the account identifier, organization or project, billing owner, technical owner, recovery email or process, authentication method, privileged roles, automation identities, linked repositories, and operational dependency. Record secret names and storage locations without copying values into the transfer document. Unknown control should be visible, not filled with an assumption.
Some providers transfer resources; others require a new owner, billing update, or support request. GitHub recommends multiple organization owners for continuity. AWS documents an account-ownership sequence involving billing details, root email, new credentials, and multifactor authentication. Follow each provider's current procedure rather than treating a shared login as a transfer mechanism.
Establish and test replacement custody
Create or promote buyer-controlled identities with the minimum role needed for the handoff. Verify login, recovery, billing visibility, deployment permission, log access, and the ability to manage downstream automation. Where a service supports workload identities or applications, prefer them over a departing person's long-lived token and document which workflows use each identity.
Rotate credentials when the buyer authorizes it, then test the affected build, deployment, webhook, or scheduled job. A rotation is incomplete if an unknown consumer still depends on the old value. Keep a temporary rollback condition only where the provider and buyer permit it, with a named expiration and an explicit decision about the old credential.
Remove old paths after acceptance
The incoming owner confirms that required operations work and that recovery no longer depends on the departing custodian. The buyer then directs removal, demotion, or reassignment of personal accounts, tokens, deploy keys, billing methods, and support contacts. Preserve an evidence receipt with timestamps and role names, never secret values or recovery codes.
Release Custody Record organizes this work through Reality Contact, LLC but does not take unilateral control of buyer accounts. Provider behavior, billing history, contractual restrictions, and recovery rules vary. The buyer and its legal, security, finance, and platform owners decide whether an account can be transferred, must be replaced, or should remain temporarily shared.
Where the service stops
Reality Contact, LLC documents and facilitates a software ownership transfer but does not give legal advice, determine intellectual-property title, warrant the software, certify security or compliance, hold production credentials after the engagement, perform unilateral access revocation, or guarantee a release will be incident-free. The buyer names the authorized incoming owner, secures cooperation from current custodians, approves account and repository changes, performs the shadow release, accepts or rejects exceptions, and directs the relevant providers to revoke or reassign prior access. This operational handoff service does not replace legal, intellectual-property, security, compliance, employment, finance, provider, or incident-response review. The buyer controls every repository, account, credential, release, acceptance, and access decision; private materials wait for secure intake and written deletion terms.
Sources: GitHub organization ownership continuity guidance; AWS account ownership transfer best practices.