A digital business handover is not complete when a folder of passwords changes hands. The useful question is whether the buyer can carry out the work without depending on the seller's personal accounts or memory.

This checklist is designed for buyers and founders preparing an operational handover. It is general educational guidance, not legal, tax or investment advice. Contract terms and platform rules still determine what can actually be transferred.

1. Map the work before mapping the tools

Start with five ordinary jobs: collect a payment, fulfil an order or deliver the service, answer a support request, publish a change, and restore the service after a failure.

For each job, record the system used, the responsible person, the access required and the evidence that it works. Include the awkward dependencies: a developer's personal email, an agency-owned advertising account, a domain renewed on someone's card, or a spreadsheet that only one employee understands.

A list of software subscriptions is not an operating manual. Connect each tool to a business process and identify what stops if that tool or person becomes unavailable.

2. Separate access from ownership

Being able to log in does not prove an account can be transferred. Some services permit a change of administrator; others require consent, a new account or a different contract.

Use a handover register with these columns:

• Asset or service
• Current owner or contracting party
• Intended owner after completion
• Transfer method permitted by the provider
• Required consent or verification
• Person responsible and due date
• Evidence of completion
• Fallback if the transfer is delayed

Mark unknowns as unknown. Do not replace missing evidence with a seller's assurance that it will probably be fine. Ask the relevant adviser or provider to resolve contractual uncertainty before relying on the asset.

3. Test a normal day, not just the login screen

A successful login is a starting point. It does not demonstrate that an integration, deployment or customer workflow will still function.

Agree a small, controlled test plan. For an online service, it might include a test customer receiving the expected onboarding message, a support ticket reaching the correct team, and an authorised administrator finding the latest backup.

Choose tests that do not expose real customer information unnecessarily, send unsolicited messages, charge customers or disrupt production. Use a test environment where available. Record the expected result, actual result, date and person who observed it.

A useful result reads: “The test support request reached the buyer-controlled inbox and received a reply.” “Email access provided” is much weaker evidence.

4. Plan security changes as a sequence

Do not remove the seller's access before the buyer has verified a working administrative route. Equally, do not leave shared credentials circulating indefinitely after completion.

Agree who will establish buyer-controlled administration, confirm recovery methods, review permissions and retire obsolete access. Use a password manager or another approved secure transfer mechanism, not the handover spreadsheet itself, for passwords and recovery secrets.

Keep the register limited to status and evidence. For example: “Administrator access tested; recovery ownership checked; previous access removed.” Never paste secret keys into screenshots or routine progress reports.

Some changes can break integrations. Before rotating a credential, identify what uses it and establish an authorised rollback or replacement plan.

5. Make exceptions visible

A delayed account transfer does not disappear because the rest of the checklist is green. Keep an exception log with the issue, operational consequence, interim control, owner and review date.

Distinguish three states:

• Verified: the agreed test passed and evidence is recorded.
• Pending: the action is scheduled or submitted, but not confirmed.
• Blocked: a permission, technical dependency or third-party decision prevents completion.

An application sent to a platform is pending, not verified. A backup file exists, but an agreed restoration test has not occurred: the recovery capability remains unverified.

6. Finish with a walkthrough

Ask the buyer's operational owner to walk through the five ordinary jobs without relying on undocumented seller instructions. Record remaining questions and update the manual while the knowledge is still available.

The aim is not an impressive-looking checklist. It is a business that can be operated safely by the people who will actually run it.

About the author: Joash Boyton is Founder & Managing Director of Acquiry, based in Melbourne and working globally, with a focus on digital business acquisitions, buy-side origination and SaaS due diligence. https://www.acquiry.com/joash-boyton/

Disclosure: This educational guide was prepared with AI assistance for the Acquiry profile and publishing campaign. It does not describe a specific transaction or claim that these checks guarantee a successful acquisition.