App handover checklist: how to transfer an app and domain

Before anything moves: agree the asset list

Most handover disputes start with an unclear list. Before any money or access changes hands, write down exactly what is being transferred and what is not, and have both sides confirm it. Treat the list as the scope of the deal.

• The domain name, and the registrar account it sits in
• The code repository and its full history
• Hosting, deployment settings and environment names
• The database, its schema and the data in it
• Third party accounts and services, listed one by one
• Brand assets: logo, fonts, images, written content and social handles
• Customers, subscriptions and billing records
• Documentation and a support period
• Anything excluded, such as your personal accounts or unrelated projects

This guide is general information, not legal advice. For a larger sale, have a lawyer review the written agreement.

Escrow sequencing: who moves first

Vibe Classifieds never handles money, so the order of events is yours to set. An escrow service is the safest way to do it, because neither side has to trust the other first. A typical sequence looks like this:

1. Both sides sign the written terms and the asset list.
2. The buyer pays the agreed amount into escrow and the service confirms the funds are held.
3. The seller starts the handover: domain first, then code, hosting, database and accounts.
4. The buyer checks each item against the list and confirms in writing when everything works.
5. Escrow releases the funds to the seller.
6. The agreed support period begins.

Do not hand over the domain or code before the funds are secured, and do not ask the buyer to pay before escrow is in place. Pay any transfer fees as agreed. If a step goes wrong, stop and fix it before moving on.

Domain transfer steps

The details differ between registrars, so follow your own registrar's instructions. In general terms, there are two routes. If the buyer uses a different registrar, you transfer the domain out. If the buyer uses the same registrar as you, you can usually push it to their account.

• Check that the domain is eligible to move. Many registrars block transfers for a period after registration or after a change of contact details.
• Turn off any registrar lock and disable privacy features that stop the transfer.
• For a transfer between registrars, request the authorization code (sometimes called an EPP code) and give it to the buyer through a safe channel. The buyer starts the transfer with their registrar and approves it.
• For a push within the same registrar, start the push or account change from your account and have the buyer accept it.
• Confirm that the contact and administrative email on the domain will be controlled by the buyer, because transfer approvals go there.
• Do not let the domain expire during the process. Renew it first if it is close to expiry.
• Once the domain is in the buyer's account, confirm the name servers and DNS records are still correct and the app still loads.

Allow several days for a transfer between registrars to complete. Keep the app running on the existing DNS settings throughout, so customers see no downtime.

Repository and code handover

Give the buyer ownership of the repository, not a copy they have to trust you to keep updated. Transfer the repository to an account or organization they control, or add them as an owner and then remove yourself. Include the full history, branches and tags unless you have agreed otherwise.

• Check that no secret keys, passwords or tokens exist in the code or its history. If any do, rotate them and tell the buyer.
• Include the handover note: what the app does, how it is built, how it is deployed and what each setting is for.
• Document scheduled jobs, background tasks and anything that runs automatically.
• List the dependencies and their licences, and flag any that are personal to you.
• Transfer any build prompts, design files and content that belong to the app.
• Confirm the buyer can build and deploy the app from the repository on their own accounts.

Database and data handover

The database is often the most valuable and the most sensitive part of the sale. Move it deliberately. Where the platform allows, transfer ownership of the project to the buyer's account. Otherwise take a full backup, restore it into the buyer's environment, and confirm the app works against it before you switch anything over.

Treat user data with care. Check that your privacy policy allows transfer to a new owner, and that you only hand over the data the app genuinely needs. Delete your own copies and exports afterwards, and keep a note of what you deleted and when. Tell the buyer about any data obligations that come with it, such as retention or deletion requests you have promised to honour.

Hosting and third party accounts

Go through your asset list account by account. For each service, decide whether the account itself transfers, whether the buyer needs to create their own and migrate, or whether you cancel it.

• Hosting: move the project to the buyer's account or add them as an owner and then remove yourself.
• Email sending and receiving: re-verify the sending domain under the buyer's account and update the DNS records that prove it.
• Analytics and search tools: add the buyer as an owner, confirm access, then remove yourself.
• Model and API providers: the buyer should create their own account and keys, because usage and billing follow the account.
• Storage, monitoring and error tracking: transfer or recreate under the buyer's ownership.
• Social handles and app store or directory listings: transfer them if they are included in the sale.

Some accounts are personal and cannot be transferred. Say so early, so the buyer can set up their own before the cutover rather than after something breaks.

Customer and billing handover

Customers care about two things: that the app keeps working and that they are not charged wrongly. Plan the billing handover carefully, because it is the step most likely to cause a problem.

Check how your payment provider handles a change of ownership. Often the buyer must open a new account and customers have to be moved to it, which can mean asking them to re-enter payment details. Agree who sends that message, when, and what it says. Agree what happens to subscriptions that renew during the switch so nobody is charged twice or loses access. Hand over customer records, refund history and any open support requests.

Tell users about the new owner before the handover, in plain language. Update the terms, the privacy policy and the contact details on the site once the buyer takes over. The new owner becomes responsible for how customer data is used from that point.

Rotate every secret

Anything that could grant access should change owners or change value at the handover. The buyer should not rely on keys you created and still hold.

• API keys for every service the app calls
• Database passwords and connection settings
• Signing secrets for webhooks, sessions and tokens
• Admin passwords and invitation links
• Deploy tokens and repository access tokens
• Any shared password or recovery code you used while running the app

Have the buyer create the new values in their own accounts and update the app. Once the app works with the new secrets, delete the old ones from your side. Never send secrets by public message. Use the channel the buyer and escrow service agree, and share them once.

The first 30 days of support

A short support period is the cheapest insurance a buyer can ask for, and the best way for a seller to protect their reputation. Agree it in writing: how long, how you can be reached and what is in scope. Here is a simple shape:

Keep the scope clear. Support means helping the buyer understand and run what they bought. It does not mean building new features for free.

What not to hand over

A handover should cover the app and nothing else. Keep these out of the transfer:

• Your personal logins, passwords and recovery codes. Move assets into accounts the buyer controls.
• Accounts that also run other projects of yours
• Personal data that the app does not need
• Payment and bank details
• Code, content or accounts that you do not own or have no right to transfer
• Anything not on the signed asset list

If you shared a personal account with the app, separate it first. Create a dedicated account for the app, move it across, and only then hand it over.

The final checklist

Run through this before you declare the handover done, and keep a copy for both sides.

• Asset list signed by both sides
• Funds held in escrow before any transfer began
• Domain in the buyer's account, renewal date confirmed, DNS correct, app loading
• Repository owned by the buyer, with history, and builds from scratch
• Hosting and database under the buyer's ownership and working
• Third party accounts moved, recreated or cancelled as agreed
• Customers informed, billing moved and no one charged twice
• Every secret rotated and old values deleted
• Handover note delivered
• Buyer confirmation in writing, then escrow released
• Support period started with a clear end date
• Listing removed from the board

A calm, well ordered handover is also the best advertisement for the next app you sell. If you have not listed yet, start with the selling guide, and see the FAQ for quick answers on transfers.

Frequently asked questions