Who Owns the Code and Data When the Project Ends

You find out who owns the code the day you try to leave. That is the wrong day to find out.

Most US buyers assume that because they paid for the software, they own it. That assumption is wrong often enough that it is now a standard due-diligence item for anyone evaluating a development partner, not a legal afterthought buried in a 40-page master services agreement. The gap between "we paid for this" and "we own this" is where vendor lock-in lives.

What does "ownership" actually mean in a software contract?

Ownership means you hold the intellectual property rights to the source code, the documentation and the data schema, and you can take all three to another vendor without permission, payment or delay.

That sounds obvious until you separate it into its parts. A vendor can hand you a working application, give you login access, and still legally own the code underneath it, because US copyright law treats custom-written software as the intellectual property of whoever wrote it, unless a contract explicitly transfers that right. Access is not ownership. A login does not give you the right to modify, redistribute or move the code. Only an assignment clause does.

This is the single most-cited gap in outsourcing disputes: the client believed payment implied transfer. It does not.

Who owns the code by default, if the contract is silent?

By default, the vendor owns it. Under US copyright law, work created by an independent contractor is not automatically "work made for hire" unless the contract says so in the specific language the statute requires, and even then, only for certain categories of work. Custom software frequently falls outside those categories unless the agreement contains an explicit present-tense assignment: "Vendor hereby assigns all right, title and interest in the Work Product to Client," not "Vendor will assign" or "Client shall own." Future tense and conditional language have been the basis of real disputes.

This is not unique to offshore vendors. US-based freelancers and agencies get this wrong too. But when the vendor is five or ten time zones away, the buyer cannot walk into their office to resolve it, and that is what makes the clause non-negotiable rather than a nice-to-have.

What about the data, not just the code?

Data ownership needs its own clause. Code and data are not the same asset, and a contract that covers one does not automatically cover the other.

If your operational data, customer records, production history, inventory movements, sits inside a database the vendor hosts and controls, you need three things spelt out separately from code ownership: the right to extract the full dataset in a usable format on request, the right to the schema (the structure the data is organised in, not just the raw rows), and a defined timeline for handover if the relationship ends. A vendor who owns the schema but not the data can still make an export technically painful, by not documenting field names, not explaining relationships between tables, or delivering an export in a format no other developer can use without weeks of reverse-engineering.

This is the quiet version of lock-in. Nobody refuses to hand over your data. They just make it unusable fast enough that you renew instead of migrate.

How do you verify ownership before you sign, not after you leave?

You verify it by reading the contract for five specific things, not by trusting the proposal deck or the sales call.

Contract element	What to look for	Why it matters
Assignment language	Present-tense "hereby assigns," not future-tense "will assign"	Future-tense clauses have been argued as unenforceable promises, not transfers
Work-for-hire clause	Explicit statement the work qualifies, plus a backup assignment clause	Not all custom software legally qualifies as work-for-hire under US copyright law
Repository access	Named person on your side has admin rights to the live repository during the build, not just at the end	Access during the project is how you confirm the code exists where you think it does
Data export clause	Format, timeline and schema documentation specified in writing	Without this, "you can have your data" can still mean an unusable file
Third-party licences	List of any open-source or paid components used, and whether your licence to use them survives the vendor relationship	Some components are licensed to the vendor, not transferable to you

Ask for all five in writing before the first invoice, not after the first delivery. A partner with nothing to hide will not treat this as an unusual request. For a broader view of what else to check before signing, see how to evaluate an India-based transformation partner.

What does exit actually look like when ownership is done right?

Exit should take days, not months, and it should not require the vendor's cooperation beyond what the contract already obliges them to do.

A clean exit follows a fixed sequence, agreed before the project starts, not negotiated under pressure when the relationship sours.

The test is simple: can a different development team, one that has never worked with your current vendor, pick up the repository and the database export and understand what they are looking at within a week? If the answer depends on a phone call to the old vendor, ownership was never real. It was access dressed up as ownership.

What are the red flags that signal lock-in before you sign?

The clearest signal is reluctance to put ownership terms in writing before work starts, not after a dispute begins.

Watch for a proposal that talks about features, timelines and cost, but never mentions IP assignment, repository access during the build, or data export format. Watch for a vendor who offers to "discuss ownership once we're further along." Watch for pricing that is unusually low relative to the scope, because margin sometimes comes from the renewal lock-in rather than the build itself. None of these are accusations. They are questions worth asking directly, in the first call, before any contract is drafted.

If you are also weighing how engagement structure affects this risk, what digital transformation actually costs by engagement model covers how fixed-scope, phased and dedicated-team arrangements carry different exposure. And if the partner is managed across time zones, the operational discipline described in managing a development team five or more hours away is usually a reliable proxy for whether they will be equally disciplined about documentation and handover.

We treat ownership as a day-one conversation, not an exit clause. We understand how your business actually works first, then we design the system, and that includes designing who holds the keys to it once it is built. For a wider view of how to structure the whole relationship, not just the IP clause, see our hub on choosing and working with a transformation partner, and our approach to custom software development if you are scoping a build from scratch.

What to do before you sign anything

Pull up the draft contract and search it for the word "assigns." If it is not there in present tense, covering both code and data, send it back with the five items from the table above marked as required, not optional. Then ask for repository access from week one of the build, not at delivery. If the vendor hesitates on either, you have your answer before you have paid a single invoice.