A list of assets is only the beginning. The handover record should show who controls each asset, what changed and whether the product still works afterwards.

Use this list as a working record shared by buyer and seller. Mark an item complete only when the buyer has verified it. This is transfer-day execution. Buyers who have not yet inspected the system should first complete the pre-purchase technical review.

Business identity and recovery

  • Business email accounts and shared inboxes
  • Recovery email and phone numbers
  • Password manager or secure credential-delivery process
  • Support addresses and customer-contact forms
  • Vendor billing details and renewal dates

Domains and DNS

  • Registrar ownership
  • Registrant and recovery details
  • Nameserver control
  • Production, application and API records
  • Email records including SPF, DKIM and DMARC
  • Auto-renewal and payment method

Record the DNS state before making changes. A domain transfer and a nameserver change are different operations; combining them without a plan creates avoidable downtime. A registrant change may also trigger a transfer lock in some circumstances, so check the current ICANN change-of-registrant guidance before choosing the order.

Source code and delivery

  • Repository ownership and administrator access
  • Branch protections and required checks
  • Deploy keys, GitHub Apps and automation tokens
  • CI/CD workflows
  • Production and preview projects
  • Deployment permissions and logs
  • Build settings and environment-variable names

The buyer should complete a deployment from a buyer-controlled account before the handover is declared complete. Follow the provider’s actual transfer procedure—for example, GitHub’s repository transfer steps and Vercel’s project transfer documentation—rather than treating an invitation as proof of ownership.

Data and customer access

  • Database organisation and project ownership
  • Storage buckets and retention settings
  • Authentication provider
  • Backup schedule and restoration method
  • Data exports required by the agreement
  • Privacy, deletion and support processes

Never pass database passwords through an ordinary checklist. Transfer through the provider where possible, then rotate credentials.

Revenue and communication

  • Payment processor account and webhooks
  • Subscription plans and product identifiers
  • Transactional email provider
  • Customer-support tools
  • Analytics and error monitoring
  • Status pages and alert destinations

Scheduled and external work

  • Cron jobs and background workers
  • Queues and retry policies
  • Third-party APIs
  • AI model providers and spending limits
  • Webhooks sent and received
  • Mobile or browser-extension release accounts

Final verification

After transfer, test production loading, sign-up, login, password reset, a database write, transactional email, a test payment webhook and a deployment. Confirm that alerts reach the buyer.

Then remove seller access, rotate sensitive credentials and capture unresolved exceptions in writing. A handover can be complete with a documented exception; it cannot be complete when nobody knows the exception exists.

Use the SaaS Transfer Control Register to assign owners, distinguish seller claims from buyer tests and keep unresolved blockers visible. After closing, run the separate buyer-control verification; it tests the transferred system rather than repeating this execution list.