How do I hand over a SaaS business?

What does handover actually cover?

Handover is the movement of every asset, account and piece of operating knowledge from you to the new owner, with the product running the whole time. At $50,000 to $150,000 it is usually a few days of concentrated work followed by a few weeks of being reachable. The technical part is rarely the hard part. The part founders underestimate is everything they know but never wrote down.

Treat handover as a scheduled operation rather than a conversation. Agree the order, the dates and the point at which you are finished before completion day, and write it into the purchase agreement so nobody is improvising afterwards.

What happens on completion day?

On completion day the funds clear through escrow, the purchase agreement is signed, and the asset transfer begins in a fixed order. The transfer is upfront and clean, so the buyer's money is committed and held before you start moving anything, and it is released once the agreed assets have arrived. Nothing about a transfer at this size requires you to hand over control on a promise.

The practical version is a shared checklist with two columns of initials. Dull, and it is the reason transfers at this size complete without argument.

In what order should the assets move?

Move them in dependency order, so nothing breaks while something else is mid-flight:

1. Read-only handover of documentation, credentials inventory and the asset schedule, so the buyer knows what is coming.
2. Repositories: transfer ownership with commit history intact, then remove your personal access.
3. Hosting and infrastructure: create or transfer accounts under the buyer's billing, migrate secrets, rotate every credential.
4. Domain: unlock, release the authorisation code, complete the registrar transfer, confirm DNS is unchanged.
5. Third-party services: email sending, analytics, error tracking, any paid API, each moved or re-created under the buyer.
6. Payment processing: migrate subscriptions to the buyer's processor account and confirm the first successful charge.
7. Customer relationships: support inbox, CRM records, any contract requiring notice of assignment.
8. Final credential rotation and removal of your own access everywhere.

Domain before billing, billing before customer notification. Reversing that order is how a founder ends up explaining a failed payment run to somebody else's customers.

How do you move billing without breaking it?

Payment processor accounts are generally not transferable between owners, so subscriptions are migrated to the buyer's own account rather than handed over with the login. Stripe and the other major processors support a migration path for exactly this, moving customer and card records between accounts without asking every subscriber to re-enter their details. Start the request early, because it is the item with the longest lead time and the least flexibility.

Run one billing cycle under observation before you disengage. The first charge on the new account is the moment any mapping error surfaces, and you want to be reachable when it does.

What do you tell the customers?

Tell them plainly, once, shortly after completion, and make it about continuity rather than about you. Customers at this size care about two things: whether the product keeps working and who they email when it does not. A short note from the new owner, with your name on it as outgoing founder, answers both.

Timing matters more than wording. Announcing before completion invites cancellations into the middle of a transfer, and announcing weeks late lets customers discover it from a changed invoice descriptor instead.

How long should you stay available?

Thirty days of defined availability is the usual shape at this size, tapering rather than flat.

Write the commitment into the agreement in hours and days rather than as "reasonable assistance". Undefined availability is how a clean exit turns into an unpaid job for a quarter, and buyers generally prefer a specific number too.

What goes wrong in handover?

Most handover problems come from knowledge that was never written down and credentials nobody inventoried. A cron job on a personal server, a DNS record pointing at an account being closed, an API key issued under your own name to a service the buyer now cannot access. None of these are difficult. They are only expensive when they are discovered by a customer rather than by you.

The other recurring problem is a handover period agreed in vague terms by two people who each assumed the other meant something different. Define it precisely, honour it fully, and then finish.

What makes handover easy?

Handover is easy in direct proportion to how much operating documentation existed before the buyer appeared. A business with a written deployment process, a credentials inventory, a support playbook and a current asset schedule can be moved in days by two competent people. A business where all of that lives in the founder's head takes weeks and leaves both sides irritated.

That documentation also raises the price, which is the part worth noticing. A buyer looking at a business with $40,000 of trailing annual profit and a documented handover is being asked to price a smaller risk than the same business without one, and the conventional 2–4× range is exactly where that difference shows up.

Related: how-to-take-over-hosting-domains-and-payments, handover-period, stack-transfer