The SaaS Handoff Checklist: How to Actually Transfer a Business After You Sell

Agreeing on a price is the easy part. The part that actually determines whether a micro SaaS sale goes smoothly — or turns into a mess of emails and half-working access a week later — is the handoff: who gives up what, in what order, and how you both know it's actually done. Most disputes in small SaaS sales don't come from disagreeing on value. They come from a rushed or badly sequenced handoff. Here's a checklist for doing it properly.

1. Domain and DNS

The domain is usually the single highest-value, hardest-to-reverse thing in the sale. If it's on a registrar that supports transfer (most do), plan for the transfer itself to take anywhere from a few hours to a few days depending on the registrar and any transfer lock. If a full registrar transfer isn't practical right away, the seller can add the buyer as an account collaborator or hand over DNS management first, then complete the full ownership transfer once payment clears. Either way, agree on which approach you're using before payment, not after.

2. Hosting and infrastructure

• Server or hosting platform access (Vercel, AWS, DigitalOcean, Railway, etc.) — either add the buyer as a collaborator, or transfer the project/account outright
• Database access and a recent backup, handed over separately from live access in case something breaks mid-transfer
• Environment variables and secrets (API keys, database credentials) — rotate any that shouldn't carry over from the seller's other projects
• SSL/domain configuration, if it's not automatically handled by the hosting platform

3. Payment processor

This is usually the messiest part, and worth planning for early rather than leaving until the end. Stripe, Razorpay, and similar processors generally don't let you just "hand over" an account — the buyer usually needs to either set up their own account and the seller migrates subscriptions across, or go through the processor's own account-ownership-change process, which can take several business days and its own verification. Whichever route you use, agree on who's responsible for handling any customer payment failures or support during the transition window.

4. Source code and repository access

Full repository access (not just a zip export) matters, since a zip loses commit history that can be genuinely useful for understanding why something was built a certain way. If the code is on GitHub or similar, transfer repository ownership or add the buyer with admin access, then remove the seller's access once the buyer has confirmed everything pulls and builds correctly on their end.

5. Customer data and communications

Handle this carefully — depending on where your customers are and what your privacy policy says, you may not be able to just hand over a customer list without notice. At minimum, check your own privacy policy's terms before transferring customer data, and consider whether existing customers should be notified that the product has changed hands. A short, honest email from the seller introducing the new owner tends to land better than customers finding out some other way.

6. Third-party accounts and integrations

• Analytics (Google Analytics, Plausible, etc.)
• Transactional and marketing email (Resend, Postmark, Mailchimp, etc.)
• Customer support tool or shared inbox, if one exists
• Any social accounts tied to the product (Twitter/X, Instagram, LinkedIn page) that were part of the deal
• Error monitoring or logging tools (Sentry and similar)

7. Documentation and knowledge transfer

Even a short README covering how to deploy, where the environment variables live, and any manual processes that aren't obvious from the code saves the buyer real time — and a lot of frustration — in the first few weeks. A 30-60 minute handoff call to walk through the product and answer questions live tends to surface things that never make it into written docs.

A handoff order that avoids disputes

• Agreement in writing: price, what's included, and the handoff timeline
• Deposit paid (if using one) — buyer gets read-only or staging access to verify the code and product actually work as described
• Buyer confirms everything checks out
• Balance paid in full
• Full access transferred: domain, hosting, repository ownership, payment processor migration started
• Handoff call to cover anything undocumented
• Seller's access removed once the buyer confirms everything is working independently

Neither side should hand over everything before payment, and neither side should expect full access to work perfectly the instant payment clears — a short, defined transition window where both sides can still reach each other is normal, not a sign something's wrong.

Selling soon? See what similar micro SaaS products are listed for →