You own your Shopify store only if you hold the store owner account, the domain registrar login, the theme repository, the analytics property, and the billing method behind your apps. An intellectual property clause in the build contract gives you none of the five.
The contract says the code is yours. The question that actually settles it is simpler: if the agency stopped answering email tomorrow, what could you still log into?
You own the contract rights, and you control only the accounts whose credentials sit in your name. Those are two different things, and the distance between them is where brands lose weeks they had not budgeted for. A standard build agreement assigns the intellectual property in the deliverables to the client on final payment. That clause is worth having. It is also, on the morning you decide to change developers, close to useless on its own, because nothing in it produces a login.
The pattern repeats at the same point in a brand’s life. A store gets built while the founder is busy doing everything else. The developer sets up what needs setting up, using their own accounts because that is fastest, and the work ships. Two or three years later the brand has grown past what that team does well, and the exit turns out never to have been designed. The store is worth more than it was, which is precisely why the handover is now harder.
The list of what has to come back does not change with the size of the shop you hired. A Shopify Plus partner in Toronto, a web development agency manchester founders use for platform and API work, and a solo Liquid contractor working evenings all hand over the same five things, or they do not. The difference between a clean transition and a bad one is almost never the quality of the original build. It is whether anyone wrote the handover down while everyone still liked each other.
Treat this as an operating question rather than a legal one. Lawyers write the clause. Access is an infrastructure decision, and it is yours to make at the moment the statement of work is signed, not at the moment the relationship ends.
Five accounts decide whether changing agencies takes a week or a quarter: the Shopify store owner account, the domain registrar, the theme repository, the analytics property, and the billing method behind your apps. Every other credential in the build is recoverable in an afternoon. These five are the ones that gate everything else, because each one controls a system a new developer cannot work around.
App billing is the one operators consistently underrate, because it looks like a finance problem rather than an ownership problem. It is both. A store that is three years old typically carries 25 to 40 active apps, a figure that comes out of our own Shopify tech stack audit on app bloat and operational drift, and some meaningful share of those were installed under an agency’s Partner account or paid on an agency card. When the relationship ends, the subscriptions that were never in your name are the ones that quietly lapse, usually on a Friday.
Run the list as a named inventory, not as a feeling. For each of the five, write down the email address on the account and the person who can reset the password today. Where those two answers name someone outside your company, you have found the work.
Shopify separates agency access from store ownership by design, and the mechanism is the collaborator account. A Shopify Partner requests access to your store, you approve the request from your admin, and you decide which sections of the store that partner can see. Collaborator accounts do not count against your staff limit, which removes the usual excuse for handing a developer full staff credentials on a plan with a tight seat count.
Two details in Shopify’s own documentation matter more than they look. First, removing a collaborator deletes the account from the store entirely, so revoking access is a single action you can take yourself without asking anyone. Second, collaborator access expires automatically after 90 days with no login activity, and a partner can hold only 10 pending access requests at a time. Access decays on its own if it is not used, which is the behavior you want from a dormant vendor relationship.
Stores that a partner built for you work slightly differently, and the difference is worth knowing before the invoice is paid. Shopify’s guidance for partners sets out the transfer of ownership from a development store to the client: the partner opens Settings, then Users and permissions, selects Transfer ownership, and the new owner has to accept. Until you accept, the partner can cancel the transfer. Once you accept and start paying for a plan, the partner keeps a collaborator account on the store rather than ownership of it.
That is the correct end state, and it is the one to confirm in writing rather than assume. The question to ask before the final payment leaves your account is plain: whose name is on the store owner record right now, and when does it become mine.
Your theme’s source code belongs in a repository your company owns, with the agency invited into it as a contributor, rather than in the agency’s own GitHub organization with you added as a guest. The distinction sounds procedural. It is the difference between onboarding a new developer in an afternoon and reconstructing three years of work from whatever is currently published on the live store.
Shopify supports this directly. The platform’s guidance on version control for themes recommends separating source code from compiled code using branches, and connecting the main branch to the store so the published theme stays current as work merges in. That arrangement needs exactly one repository and two branches. Nothing about it requires the repository to sit on the agency’s side of the wall.
There is a test for whether your code is genuinely recoverable, and it takes five minutes. Ask your developer to send you the repository URL and confirm that someone at your company, not at the agency, holds the owner role on it. If the answer involves exporting a zip file, downloading a theme from the admin, or a promise to send everything over at the end, the code is not in your control yet. A published theme on Shopify is compiled output. The commit history, the build tooling, and the branch that explains why a section works the way it does are the asset.
For brands in the $500K to $2M band running a customized theme rather than a headless build, this one change carries more practical leverage than any other item on the list, because it is cheap to do on day one and expensive to reconstruct on day 900.
The domain and the analytics property are the two assets most often left in someone else’s name, and both carry a delay you cannot shorten at the moment you need them. Neither is technically difficult to fix. Both are easy to forget, because they sit outside Shopify and nobody logs into them between launches.
Start with the domain, because it has a timer attached. Under ICANN’s rules on changing a domain registrant, registrars must apply a lock that prevents transferring the domain to another registrar for 60 days after a change to the registrant’s information, and a registrant can opt out of that lock beforehand or move the domain first. The practical consequence: correcting who owns the domain during an agency exit, in a hurry, can be the action that freezes it. Do it deliberately, on a calm week, before anything is urgent.
Analytics is less dramatic and more commonly broken. In Google Analytics 4, adding or removing users requires the Administrator role at the account or property level, and the system will not let the last remaining administrator delete themselves. If the only administrator on your property works at your agency, you do not own your measurement history in any way that matters. You are a guest in a record of your own business.
The fix in both cases is the same shape. Put a company controlled account at the top of each system, then invite the agency in underneath it. A vendor who objects to that arrangement has told you something useful at no cost.
Write the handover into the statement of work before the build starts, and scale what you ask for to your stage rather than copying an enterprise checklist into a $12K project. The ask that is proportionate at $10M in revenue will get you politely declined at $50K months, and the ask that is proportionate at $50K months leaves real exposure on the table at $10M.
Under roughly $500K a year, keep it to three lines: the store owner account is in a company email address from day one, the domain is registered in your own registrar account, and the agency works through a collaborator account rather than a staff account. That is achievable with any competent freelancer and costs nothing to negotiate. If you are still choosing who to hire, our guide to what fast growing DTC brands actually need from a Shopify development partner covers the evaluation side of this decision, and a current shortlist of Shopify development agencies is a reasonable place to start a search.
Between $500K and $2M, add the repository clause and the analytics clause. Source code lives in your organization. Your company holds an administrator role on the analytics property and on the ad accounts. Ask for documentation as a named deliverable with its own line in the schedule, because documentation that is not a deliverable is a favor, and favors do not survive a soured relationship. This is the band where premature complexity does the most damage, so resist the urge to add custom apps and bespoke integrations before the ownership basics are settled.
Above $2M, and particularly if a replatform is in view, treat handover as a scheduled event rather than a clause. Name a handover date in the project plan, require a written access register listing every account and its owner, and run the transfer while the incumbent agency is still engaged and paid. Brands preparing a larger move can fold this into the wider sequencing in our Shopify Plus migration checklist, which covers the data and SEO side of the same transition.
Set aside 90 minutes, open the five systems in five browser tabs, and write down the email address on each account. That is the whole exercise. Most operators discover two or three surprises, and the surprises are almost never in Shopify itself, because the Shopify admin is the one system founders log into every day.
Work in this order. Shopify Settings, then Users and permissions, and read the store owner line rather than the staff list. Your registrar, checking the registrant contact rather than just the login. Your repository host, checking who holds the owner role on the organization. Your analytics property, checking the administrator list. Then your app subscriptions, sorted by how they are billed. Anything billed outside Shopify, on a card that is not yours, goes on the list.
Do not try to fix everything in the same sitting. Fix the domain first, because it is the one with a 60 day timer. Fix the analytics administrator second, because it takes two minutes. The repository move and the app billing consolidation are project work and belong on a roadmap, not in an afternoon. If you want a broader sweep at the same time, the year end store audit pairs well with this one, and running them together turns two separate chores into a single quarterly habit.
None of this is a statement about the agency you hired. Good developers set these things up correctly without being asked, and the ones who do not are usually moving fast rather than acting badly. The point is that the arrangement should survive a change of mind on either side. A relationship you can leave cleanly is a relationship you are more likely to stay in.
Ownership of the code is set by the contract, and control of the code is set by who holds the repository. Most build agreements assign the intellectual property in the deliverables to the client, usually on final payment, which gives you the legal right to use, modify, and move the work. That clause does not give you access. If the source code lives in the agency’s GitHub organization and your company holds no role on it, you have a claim you would have to enforce rather than an asset you can hand to a new developer. Ask for the repository URL, confirm your company holds the owner role, and treat the contract clause as backup rather than as the mechanism.
Remove the collaborator account from Settings, then Users and permissions in your Shopify admin, and the account is deleted from the store entirely. You do not need the agency’s cooperation to do it, and you do not need to change your own password first. If the developer is on a staff account rather than a collaborator account, remove that staff account the same way. Shopify also expires collaborator access automatically after 90 days with no login activity, so dormant vendor access decays on its own. Before you revoke anything, make sure the domain, repository, analytics, and app billing are already in your control, because access is the easiest of the five to take back and the least useful on its own.
No. Register the domain in a registrar account your company controls, with your company as the registrant, and give the agency the DNS access they need rather than the account itself. The reason is timing. ICANN’s rules require registrars to lock a domain against transfer to another registrar for 60 days after the registrant’s information changes, so correcting ownership during a rushed agency exit can freeze the domain at exactly the wrong moment. Registrants can opt out of that lock beforehand or transfer first, but only if they plan for it. If your domain currently sits in an agency account, move it during a calm month rather than waiting for a handover to force the issue.
A complete handover covers five accounts plus documentation: the store owner record on a company email address, the domain in your registrar account, the theme repository under your organization, administrator access on your analytics property, and a list of every app with how it is billed and under whose account. Documentation should name the custom code that was written, the integrations that were built, any scheduled jobs or scripts running outside Shopify, and the credentials store where third party keys live. Ask for this as a named deliverable in the statement of work with its own line in the payment schedule. Documentation that is a favor rather than a deliverable tends not to arrive.
A switch takes days when the five accounts are already in your name and weeks to a quarter when they are not. With the store owner record, domain, repository, analytics, and app billing in your control, a new developer requests collaborator access, clones the repository, and is productive quickly. Without them, the timeline is set by whichever recovery takes longest, and the domain is usually that one because of the 60 day transfer lock that follows a registrant change. The variable is not the complexity of your build. It is how much of the infrastructure was set up in someone else’s name, which is why the cheapest moment to fix this is before the build starts.
