Buying a Software Business in Canada

Buying a software business in Canada means acquiring more than a code repository and a subscription dashboard. The buyer needs enforceable rights to the product, customers likely to renew, and the practical ability to keep the service running after the founder leaves. A profitable-looking business can lose value quickly if a contractor owns essential code, a major customer can terminate on closing, or prepaid subscriptions carry expensive unfinished work.

Start with three connected reviews: legal ownership and contracts, financial quality of revenue, and independent technical diligence. Each should inform the purchase agreement and transition plan. The Ontario business purchase checklist provides a broader transaction framework; software diligence adds questions about dependencies, data, deployment and continuing service obligations. This guide provides general information; obtain transaction-specific legal, accounting and technical advice before committing.

For the broader purchase process and other sectors, visit the business acquisition hub and industry guide directory.

Build a contributor history covering founders, employees, agencies, freelancers and acquired projects. Match repository activity to employment agreements, development contracts and signed assignments. Include mobile applications, documentation, user interfaces, artwork and customer-specific modifications. A seller's access to code does not establish ownership.

Under section 13 of the Copyright Act, the author generally starts as copyright owner, subject to the Act. There is an employment exception for work made in the course of employment, absent an agreement to the contrary. Paying an independent contractor does not automatically produce the same result. Copyright assignments require signed writing. Do not rely on an invoice marked paid or assume a Canadian version of an American 'work for hire' clause settles ownership.

Review moral rights separately. They cannot be assigned, although they may be waived, and a copyright assignment alone does not waive them under section 14.1. Identify any missing waivers and the uses they need to cover.

Resolve material gaps before closing, ideally through documents signed by the actual rights holder. A seller indemnity may provide a recovery route but does not deliver missing rights. See the guides to Canadian copyright ownership and IP ownership and assignments for related background.

Ask for a software bill of materials or equivalent inventory of direct and indirect dependencies, with versions, licences and deployment locations. Have a specialist compare it with the actual repositories and released products. A policy saying developers avoid restrictive licences is less useful than evidence of what ships.

Open source is common and can be valuable. Its obligations depend on the particular licence, modifications and how the component is used or distributed. Copyleft review should determine whether source disclosure or other obligations are triggered by the product's actual delivery model, including relevant network-use terms. Do not assume every open-source component requires disclosure of the whole application, or that a hosted service eliminates every obligation.

Inventory commercial libraries, fonts, datasets, model licences and third-party APIs as well. Confirm commercial use rights, usage limits, pricing tiers, termination terms and whether a new owner needs approval or a replacement account. An inexpensive product may depend on an API whose next pricing tier changes its margins.

For AI-assisted development, request the tools and account terms used, contribution policies and available provenance records. Evaluate suspicious code and licence conflicts; an assurance that an AI tool wrote it is not evidence of unrestricted ownership.

Annual recurring revenue, or ARR, is a management metric whose definition must be tested. Obtain a customer-level schedule showing plan, contracted price, renewal date, discounts, cancellation rights, currency and payment history. Reconcile it to executed agreements, billing-platform exports, bank receipts and the general ledger. Review historical snapshots to detect changes shortly before the sale.

Separate recurring subscriptions from implementation charges, professional services, usage spikes, trials and one-time licence sales. Bookings represent commitments recorded under the seller's method; they do not necessarily equal cash received, accounting revenue or durable recurring revenue. Ask how overdue invoices, customers with termination notices and contracts still awaiting signature are treated.

Review churn and expansion by customer cohort rather than relying only on an aggregate growth percentage. Determine whether growth comes from new customers, price increases, extra users or unusually large one-off activity. Read support tickets and renewal correspondence for major accounts.

Test gross margins after realistic cloud hosting, API, customer support and security costs. Include the cost of replacing founder labour. Concentration matters even where customers reliably pay: losing one account may remove the cash needed to maintain a product built largely for that customer's requirements.

For a business combining software subscriptions with support services or online retail, compare the managed IT service provider buying guide and the ecommerce acquisition guide. Their revenue and platform-access reviews help distinguish those operating models.

An asset purchase can identify the code, domain names, trademarks, contracts and other assets being bought, together with specified assumed obligations. It also requires attention to transfers and consents. In a share purchase, the company continues owning its assets and remains responsible for its existing obligations, while the buyer acquires the company. Historical liabilities therefore need careful investigation.

Neither structure bypasses contract wording. Review assignment and change-of-control clauses in customer agreements, cloud contracts, app marketplace terms and material supplier arrangements. A share deal can still trigger a customer consent requirement. Conversely, some asset transfers may be permitted under a negotiated provision. Prepare a consent schedule stating who must approve, by when, and what happens if approval is refused.

Identify customer source-code escrow arrangements, exclusivity promises and restrictions on competing products. Check office leases, equipment leases and related-party licences where they matter to operations. Include essential consents and ownership remediation in what to include in a purchase letter of intent, before exclusivity limits the buyer's options. The asset versus share sale comparison tool can help frame the initial discussion.

Determine which privacy laws apply to the business, its customers and its information. A software provider may hold personal information on customers' behalf as well as for its own purposes. Read data-processing commitments, hosting-location promises and restrictions on subprocessors before moving anything. Start diligence with anonymized or aggregated material where possible.

Where PIPEDA applies, its business-transaction provision permits certain disclosures without consent only if conditions are met. These include necessity and an agreement restricting use, requiring safeguards and requiring return or destruction if the deal fails. Completed transactions have further conditions addressing permitted purposes, safeguards, withdrawal of consent, necessity for carrying on the business and notification within a reasonable time. The exception does not apply where the transaction's primary purpose or result is acquiring or disposing of personal information. Buying a customer database is therefore not automatically covered.

Security diligence should request incident records, penetration-test findings, remediation evidence, backup restoration results and insurance claims. Compare customer security questionnaires with actual controls. The Canadian Centre for Cyber Security's software supply-chain guidance identifies risks involving dependencies, developer accounts and signing keys. Use those areas to scope technical review. A clean external scan alone cannot establish that historic incidents, privileged access or development systems are under control.

A prepaid annual subscription brings cash before all the service has been delivered. Establish who keeps that cash and who funds the remaining hosting, support and contractual commitments. Agree how deferred revenue affects the purchase price or closing adjustment; do not assume the accounting balance equals either the buyer's delivery cost or the negotiated adjustment.

List prepaid support hours, implementation backlogs, promised integrations, lifetime licences, refund rights and service credits. Assess whether customer-specific work is included in subscription pricing or separately chargeable. Unwritten roadmap promises should be investigated through proposals, sales correspondence and support records.

Coordinate the working-capital definition, assumed liabilities and debt-like items so the same obligation is not counted twice. Address known exposures through targeted remedies such as completion conditions, price changes, holdbacks or specific indemnities, depending on the issue. Any retention-based earnout should define eligible revenue, renewals, refunds, customer migration and the buyer's operating discretion clearly enough to reduce later disputes.

Identify who can deploy releases, diagnose outages, approve architecture changes and answer major customers' questions. Review employment and contractor arrangements, accrued obligations, incentive promises and departure risks. A product with one indispensable engineer may need a longer transition and a realistic recruitment budget.

Do not treat every person invoicing through a company as conclusively independent. Worker status and employment consequences require review based on the actual relationship and applicable law. In an asset deal, document offers, service recognition and responsibility for employment obligations; purchasing selected assets does not itself answer every continuity question.

Discuss retention arrangements early enough for key people to make informed commitments. Define the founder's transition hours, availability, deliverables and compensation. General promises to 'help as needed' rarely provide the operational certainty a buyer needs during a serious outage.

Require a practical handover schedule covering repositories, branch protections, build pipelines, package registries, cloud environments, domains, DNS, certificates, signing keys and monitoring. Include billing ownership and recovery methods. Personal email addresses and a founder's phone should not remain the only route to administrative control.

Before closing, have an authorized technical reviewer demonstrate that the documented process can build the production release from identified source and deploy it to a controlled test environment. Test a backup restoration and record outstanding dependencies. Establish whether infrastructure configuration, database migrations and emergency procedures are documented. Repository delivery alone is insufficient if the service cannot be rebuilt.

Agree how accounts and secrets will transition under each provider's terms. Some accounts require approved transfer processes or new buyer accounts. Plan controlled rotation of credentials and keys with attention to customer integrations, uptime and audit trails. Avoid a mass password change that breaks production.

The closing checklist should allocate responsibility for each step and identify the evidence of completion. Expand the interactive due diligence checklist with these technical deliverables and a time-limited support plan.

Suppose a buyer agrees a price based on reported subscription revenue. During diligence, a large customer explains that renewal depends on a promised reporting module. An external developer built that module, but the seller can produce only invoices and an unsigned development proposal. The developer also controls its deployment account.

The buyer now has connected revenue, ownership and continuity issues. Appropriate next steps might include obtaining signed rights documents, confirming the customer's remaining requirements, costing completion and testing deployment under company-controlled access. The parties could make satisfactory remediation and any necessary customer consent conditions of closing, then adjust the economics if the renewal remains uncertain.

This is a hypothetical illustration, not a reported transaction. Its point is practical: the subscription spreadsheet, contractor file and technical handover should be reviewed together.

Does buying the company guarantee ownership of its source code?

No. A share purchase changes the company's owners; it does not repair a missing assignment from a contractor or founder. Confirm the company owns or has adequate licences for the code and other materials it needs, and resolve material gaps before closing.

Should prepaid subscriptions reduce the purchase price?

They require an express agreement. The buyer may inherit future delivery costs while the seller retains cash already received. The negotiated treatment should reflect the business, customer obligations and closing accounts, with consistent definitions that prevent double counting. There is no single adjustment that fits every software acquisition.

Can the seller simply hand over every customer record?

No automatic entitlement follows from signing a purchase agreement. Applicable privacy law, customer contracts, the transaction structure and the information's purpose all matter. Use a documented disclosure plan, limit diligence access and confirm the lawful basis and required steps for any transfer.

A useful software acquisition review ends with decisions: which rights must be obtained, which customers or providers must consent, which obligations affect price, and what the buyer must be able to operate on closing day. Assign owners and deadlines to each unresolved item.

Lamba Law provides legal help with buying a business, including transaction structure, contract review and purchase documentation. Coordinate that legal work with financial and technical diligence so the signed agreement reflects the product and obligations being acquired.