Buying an Online Business? Map the Hidden Dependencies Before You Make an Offer

An online business can look transferable because its website loads, revenue appears in a dashboard and the seller has supplied a neat asset list. Then the buyer discovers that the domain sits in a developer’s personal account, the code repository cannot move as expected, the payment history belongs to a non-transferable account and one founder is still performing the work that supposedly belongs to the software.

The real acquisition target is not a collection of screenshots. It is an operating system of ownership, access, people, suppliers, data and recurring decisions. Before you make an offer, map those dependencies and test which ones can survive a change of control.

Start with the promised outcome

Write one sentence describing what the business is meant to deliver without the current owner. For example: “Customers buy a monthly subscription, receive automated reports and obtain support within one working day.”

Now work backwards. What must remain available for that sentence to stay true on the first day after completion, after thirty days and after six months? This turns due diligence from a folder-reading exercise into a continuity test.

1. Map legal ownership—not just access

Logging into an asset does not prove that the seller owns it or has the right to transfer it. Build an ownership schedule covering:

company shares or the specific assets being sold;
domain names and registrar records;
source-code repositories and organisation accounts;
trademarks, designs, content, datasets and licences;
mobile-app and browser-extension publisher accounts;
social-media pages, advertising accounts and mailing lists;
customer and supplier contracts;
hardware, devices and security keys used to operate the business.

For every item, record the legal owner, current administrator, transfer method, transfer restriction, renewal date and evidence reviewed. A personal email address controlling a business asset is a dependency, even when the relationship is friendly.

Official ICANN guidance on moving a domain to another registrant explains that the current registrar normally requires confirmation through a secure process. That means “the domain is included” is not enough; the parties need a workable change-of-registrant process and access to the registered holder’s contact route.

2. Separate transferable assets from transferable accounts

Some services allow an organisation owner to add a successor. Some allow individual assets to move. Others require the buyer to open a new account and migrate the business into it. Treat these as different transaction types.

GitHub’s official documentation, for example, lists conditions for transferring a repository and notes that existing collaborators can remain after transfer. Its separate organisation guidance says ownership transfer involves adding a new owner, updating billing information and then removing the previous owner. The practical lesson is wider than GitHub: test the exact transfer path for every critical platform rather than assuming that a password handover changes ownership.

Direct transfer: the platform supports a formal change of owner.
Asset migration: data or code can move into a buyer-controlled account.
Contract novation or consent: another party must approve the change.
Replacement: the buyer must recreate the service and accept downtime or lost history.
Non-transferable: the value cannot legally or technically move and should not be priced as an acquired asset.

3. Trace revenue to the work that creates it

Revenue quality depends on more than the number shown in an analytics panel. Select several recent transactions and trace each one from customer acquisition to cash receipt and delivery.

Which channel introduced the customer?
What promise or price did the customer see?
Who or what delivered the product?
Which fees, refunds, taxes and support costs reduced the receipt?
Was the payment recurring, one-off or dependent on the founder’s relationship?
Can the buyer continue using the payment route under their own verified business identity?

Do not treat processor screenshots as a complete financial record. Reconcile a sample against bank deposits, invoices, refunds, subscription status and the underlying contract. Separate gross sales from revenue the buyer can reasonably expect to retain after transfer.

4. Find the founder-shaped work

A small digital business often contains invisible labour. The founder may manually approve customers, repair failed automations, negotiate renewals, create weekly content or answer support messages from a personal phone. If that work is not recorded, “automated” can mean “quietly subsidised by the seller”.

Ask the owner to keep a two-week activity log. For each task, record frequency, duration, required judgement, systems touched and what happens if the task is missed. Then classify it:

Documented and delegable;
automated but supervised;
dependent on a named employee or contractor;
dependent on the founder’s identity, reputation or personal relationship;
currently undocumented.

Buyer test: if the seller vanished for seven days before completion, which customer promises would fail? Those failures identify the dependencies that deserve the fastest investigation.

5. Build the supplier and infrastructure map

List every external service required to attract customers, deliver the product, communicate, bill, store data and recover from failure. Include hosting, databases, email, domains, artificial-intelligence providers, payment processors, analytics, fulfilment partners, contractors and backup services.

The UK National Cyber Security Centre’s supply-chain mapping guidance recommends understanding dependencies so risks can be managed. Apply that logic to an acquisition by recording, for each supplier:

the service supplied and the data it can access;
account owner, billing owner and renewal date;
contract term, cancellation rights and transfer restrictions;
monthly cost and usage sensitivity;
single points of failure and available alternatives;
export, backup and restoration procedures;
the time required to replace the service.

A cheap tool can still be a major dependency if the business cannot operate without its history, integration or proprietary workflow.

6. Treat customer data as responsibility, not inventory

A customer database may contribute commercial value, but it also carries legal and security duties. Determine what personal data exists, why it was collected, where it is stored, who can access it and whether the proposed transfer changes the controller or purpose.

The UK Information Commissioner’s Office specifically advises organisations to consider data-sharing due diligence when a merger, acquisition or structural change transfers data to a different organisation. Its guidance warns that changes in the data controller require care. Buyers operating elsewhere should identify the rules that apply to their jurisdiction and transaction.

Use the ICO’s acquisition and data-sharing due-diligence guidance as a starting point, then obtain qualified legal advice for the actual deal. Do not copy live personal data into an informal review folder merely because it may be sold later.

7. Convert the map into a risk score

Give every critical dependency a simple status:

Green: ownership is evidenced, transfer is tested and a fallback exists.
Amber: transfer appears possible but depends on consent, migration work, a key person or an untested step.
Red: ownership is disputed, transfer is prohibited, credentials are unavailable or the business cannot operate without the seller.

Add two numbers: the probable cost to resolve the dependency and the time the business could tolerate its failure. A low-cost problem with zero tolerance may deserve more attention than an expensive tool that can be replaced gradually.

Make the offer conditional on continuity

The dependency map should change the transaction, not merely decorate the due-diligence file. Depending on professional advice and the deal structure, unresolved items may lead to:

a lower valuation for non-transferable or founder-dependent value;
a completion condition requiring a successful transfer test;
a defined handover period with named deliverables;
retention or staged payment linked to continuity milestones;
seller warranties about ownership and disclosed liabilities;
a migration budget and agreed responsibility for failure;
a decision to walk away.

For a seller-side view, read MaryChuks.com’s guide to building a buyer-ready SaaS evidence room. Buyers can use the same structure in reverse: every important claim should connect to evidence, an owner and a transfer step.

Use a protected route for the investigation

High-value digital-business deals should not depend on passwords sent through chat or confidential files scattered across personal email. The live MOC Marketplace buyer gateway currently describes protected handover rooms, electronic confidentiality controls, evidence records and a resolution process for digital-business transactions. Buyers should still conduct their own commercial, technical and legal review.

The 48-hour dependency-map exercise

Write the business outcome that must continue after acquisition.
List every asset, person, account, supplier and dataset required to deliver it.
Identify the legal owner and current administrator of each item.
Classify its transfer route: direct transfer, migration, consent, replacement or non-transferable.
Trace three recent sales from acquisition through payment and fulfilment.
Ask the seller to explain one ordinary operating day and one recent failure.
Mark every dependency green, amber or red.
Estimate resolution cost, migration time and failure tolerance.
Convert unresolved risks into offer conditions—or stop the deal.

Buy the system you can actually inherit

A business is transferable only when its ownership, access, people, suppliers and data can be reorganised around the buyer. Revenue history matters, but continuity determines whether that history can become the buyer’s future.

Map the dependencies before you negotiate from excitement. The best acquisition is not simply the one with the most impressive dashboard; it is the one whose value can survive the handover.

Evaluate before you offer: build the dependency map, test the transfer path and then explore digital-business opportunities through MOC Marketplace.