Software that works is not the same as software the target actually owns, or can leave cleanly if it has to. Both questions sit underneath the demo, and neither one is answered by watching the system run.
Key takeaways
A demo answers whether the system functions. It says nothing about whether the target legally owns what it's showing, or what happens the day it needs to leave a vendor relationship it no longer wants. Both are diligence questions in their own right, and both are easy to skip past because the software itself looks fine in the room.
Ownership of custom code is not automatic just because the target paid for it. Canadian copyright defaults to the creator: “the person who actually creates a work owns the copyright in it, unless they created it as an employee,” which means “an independent contractor developer is not your employee, which means that without an explicit written assignment clause, the developer may own the copyright.” A properly drafted development agreement needs “a clear, present-tense assignment of all intellectual property in the deliverables” to the business, not just a payment record. For a buyer, the practical check is simple to state and easy to skip: find the development agreement for anything the target treats as proprietary, and confirm the assignment clause is actually there, in writing, rather than assumed from the fact that an invoice was paid.
Where the business runs on a vendor's platform rather than its own code, the sharper question is data, not software. Canadian law doesn't hand data the same clear ownership rules copyright gets: “Canadian law doesn't generally treat raw data the way it treats physical property or even intellectual property like a copyright,” so “when a SaaS agreement is silent on data ownership, the practical answer to 'who owns this' can be genuinely unclear, and unclear terms tend to favour whichever party wrote the contract — usually the vendor.” A useful contract addresses scope (what counts as customer data, including outputs and derivatives), whether the vendor can use that data to train other products or benchmark across customers, and a specific deletion commitment once the relationship ends — not a vague assurance handled as a sales conversation rather than contract language.
Vendor relationships are negotiated hardest at the start and reviewed least at the point that matters most for a buyer: the exit. “Businesses spend a lot of time negotiating how a software relationship begins and almost no time thinking about how it ends — until they're trying to leave a platform and discover the contract gives them very little to work with,” and “older contracts, or agreements signed without legal review, sometimes say nothing about data export on exit.” A promise is not a specification: “a clause that promises data 'will be made available' isn't the same as one that specifies a usable export format,” and where a dispute over any of this ends up needing a lawyer, Ontario's general limitation period for most contract claims is two years from when the problem was discovered — a real clock that starts running whether or not the target noticed the gap when it signed.
This is not a purely legal question — it is priced. Deavo's technology sector page states the buyer's real evaluation order directly: “buyers weigh net revenue retention and churn before SDE ever comes up — and they verify the IP chain,” with “IP assignment & code escrow” and “customer contract assignability” named among the sector's live questions. An unclear IP chain or an unfavourable vendor exit clause isn't just a legal-file finding — it is exactly the kind of gap that shows up later as undocumented, owner-held knowledge if nobody outside the original vendor relationship actually understands how the system works or what would be needed to replace it.
What the technology diligence file should actually contain
Every custom-development agreement for proprietary software, checked for a present-tense IP assignment clause, not assumed from payment history.
Data-ownership language in every material SaaS contract, and what happens to that data on export or after termination.
The actual termination and data-export mechanics in each vendor contract — format, timeline, and who has to request it.
Whether more than one person inside the business actually understands how each system works, or whether that knowledge sits with one departing employee or the vendor alone.
A target's order-management system was built by a single freelance developer six years ago, paid in a series of invoices with no master development agreement ever signed. The system is central to daily operations and the developer still does occasional paid maintenance. On review, there is no written IP assignment anywhere in the file — under the default rule, the developer, not the target, may hold the copyright in the code actually running the business. The buyer's response is not to walk away from an otherwise-sound deal; it is to make a signed, present-tense IP assignment from the developer a closing condition, negotiated and paid for as part of the transaction rather than discovered as a gap after the deal has already closed and the developer's cooperation is no longer guaranteed. Where the same system also holds customer records, the ownership question runs directly into how that customer data can be handled during diligence itself, since a platform with unclear data terms is a harder system to grant a buyer's diligence team access to in the first place.
No. Under Canadian copyright law, the person who creates a work owns it by default unless they created it as an employee. An independent contractor keeps that default ownership unless a written, present-tense assignment clause transfers it — payment alone doesn't do that.
Not reliably. Canadian law doesn't treat raw data the way it treats physical or intellectual property, so silence in the contract leaves the question genuinely unclear — and unclear terms tend to favour whoever drafted the agreement, which is usually the vendor.
A missing or vague data-export clause. Many contracts, especially older ones signed without legal review, say nothing about export format or timeline — a promise that data will be 'made available' is not the same as a specified, usable format a buyer can actually migrate.
Nobody publishes Canadian transaction data, so every valuation in this country quotes an American benchmark. We are building the Canadian one — multiples, asking-to-sale spreads and days on market, by sector and by city. Leave an email and you will see it first.
No pitch, no listings. One email when the first report lands.
