Post acquisition checklist for transferring a SaaS to a new owner

The wire cleared. The escrow released. Now you actually have to move the thing.

This is the part most buyers and sellers underestimate. The handover of a half built SaaS is genuinely a small engineering project, not a five minute account swap. I have walked through this with enough Failedups deals now that I keep a checklist open during every closing call. Here it is.

1. Domain transfer at the registrar

Start here, because everything else points at it.

The seller pulls an EPP auth code from the registrar and hands it to the buyer. The buyer initiates an inbound transfer at their registrar of choice using that code. ICANN forces a 5 to 7 day window where the domain is in flux. During those days, do not change nameservers, do not edit DNS, do not do anything clever.

While the transfer is pending, set up a temporary email forwarder on a backup domain so support@ and hello@ keep working. Catch all forwarders on a parked domain are perfect for this. The seller should also make sure the registrar contact email is one they still have access to, because the confirmation email lands there.

Worth noting: domains registered in the last 60 days cannot be transferred. If the seller bought the domain right before listing, you are waiting it out.

2. DNS provider migration

If the project uses Cloudflare (most do), the buyer creates a new zone in their own Cloudflare account first. Export the BIND file from the seller’s zone, import it into the buyer’s, and verify every record matches before flipping nameservers.

The flip itself is two steps. Update the registrar’s nameserver records to point at the buyer’s Cloudflare. Wait for propagation. Then the seller can delete the old zone. Do not delete it before propagation finishes or you risk a brief MX outage that drops verification emails from every other provider you are about to migrate.

Pay attention to DNSSEC. If the seller had it enabled, it must be disabled at the registrar before the transfer or the domain will go dark. Re-enable on the buyer’s side after.

3. GitHub repository

Two paths, depending on the deal.

If the agreement is a clean handover with no continued involvement, GitHub’s repo transfer feature works fine. Settings, transfer ownership, type the new owner’s username. Issues, PRs, stars, and CI history move with it. Webhooks and deploy keys do not, so the buyer has to recreate those.

If the seller wants to keep the original visible (a portfolio piece, a learning artifact), the cleaner path is fork plus archive. Buyer forks to their org, seller archives the original with a README note pointing to the new home. This also dodges the awkward case where the seller is a solo dev and the repo lives under their personal account that they do not want to give a stranger any reason to interact with.

Either way, audit the commit history for committed secrets before transferring. Old .env files in early commits are surprisingly common, and you do not want the buyer’s first task to be rotating credentials they did not know existed.

4. Vercel or Netlify

Project transfer between teams is supported on both, but the buyer will still need to relink the GitHub repo from the new owner’s account, recopy environment variables (export to a .env file from the seller’s dashboard, import on the buyer’s side), and reattach the custom domain after the DNS transfer settles.

The order matters. Add the domain to the buyer’s project before removing it from the seller’s, otherwise certificate issuance has to start from scratch and you get a 10 minute window of TLS errors.

Preview deployment URLs change after transfer. If any of those URLs were referenced anywhere (a Notion doc, a customer onboarding email, a blog post), update them before the seller’s account vanishes.

5. Supabase

This is the one that catches people. Supabase does not currently expose a project ownership transfer in the dashboard. You have two realistic options.

Option A, same organization: invite the buyer as an owner of the seller’s org, then have the seller leave. The project stays put. Billing transfers cleanly. This is the path of least resistance if the seller is comfortable with the buyer briefly seeing other projects in the org. (For solo devs with one project per org, this is fine.)

Option B, full migration: backup and restore into a new project. Use pg_dump against the connection string, spin up a fresh project under the buyer’s org, restore with pg_restore. Storage buckets need a separate migration. Edge functions redeploy from the repo. Auth users come over with the dump but JWT secrets do not, so every active session is invalidated and customers will be logged out on the next request. Plan customer comms around that.

Whichever path you take, regenerate the service role key after handover. The seller had access to it. It should not work tomorrow.

6. Stripe

You cannot move customers between Stripe accounts. There is no export and import. PCI scope makes it impossible. So the realistic options are:

Keep the seller’s account, route revenue. The seller signs an agreement to forward payouts for X months. Cheapest in engineering effort, highest in trust required. Works for short tail handovers.
Stripe Connect migration. The buyer sets up a Connect platform, the seller’s account becomes a connected account, and over time customers reauthorize through the buyer’s flow. Cleaner long term, real engineering work to set up.
Hard cutover. New Stripe account, every customer gets an email, every customer re-enters payment details, you accept the churn. For products with low retention or high willingness to pay, this is sometimes the right call.

Pick before closing. The price of the deal often hinges on which path you agree to. Buyers should price option 3 with a 20 to 40 percent customer loss baked in.

7. Transactional email

Resend, Postmark, and SendGrid all use DNS verified sending domains. After the DNS transfer, those records need to be re-added under the buyer’s account, the domain reverified, and the API keys rotated. SPF, DKIM, and DMARC entries are easy to miss because they live as TXT records that look like noise.

Do not skip DMARC. A misconfigured policy means password reset emails land in spam at exactly the moment your new customers are trying to log in.

8. Cleanup pass

Strip the seller’s verification TXT records from DNS once everything is reverified. Rotate every third party API key the seller had access to: OpenAI, Anthropic, Twilio, Stripe webhook secrets, Sentry DSN, PostHog write key, anything else in the env file. Invite the buyer to error and analytics dashboards, then remove the seller.

9. Tell your customers

A short email. New owner, what stays the same, who to contact if anything breaks. Send it the day everything is verified working, not the day of the wire. Customers do not care about your closing date. They care about whether their thing still works on Tuesday.

If you are about to close a deal, the time to read this is before the wire goes out, not after. And if you are still browsing, the active listings are a good place to start.