What You Should Own When You Hire a Magento Agency

Almost every merchant asks some version of the same question during a pitch. Will I be locked in with you? And almost every agency gives the same answer, which is no, of course not, we are not like that.

It is a bad question because it invites a reassurance rather than a fact. Lock-in is not an attitude or a clause. It is a list of assets, and either you hold them or somebody else does. You can check the list in twenty minutes, before you sign anything, and you can check it again on a relationship you are already in.

The repository

You own the organisation. The agency is a member of it. Not the other way around.

This sounds like a detail and it is the single most common failure. A repository that lives in the agency’s account, with you invited as a collaborator, means every line of code written for your business sits inside an account you cannot administer. If the relationship ends badly, or simply if the person who set it up leaves, your access is a favour rather than a right.

You also want the full history, not a snapshot. A zip of the current code is not a handover. The commit history is where the reasoning lives: why a workaround exists, when a bug was introduced, which change preceded an incident. A new team reading three years of commits can orient itself in a week. A new team reading a zip file starts from nothing.

The test is simple and you can run it today. If you revoked the agency’s access this afternoon, would you still be able to see your code, clone it, and grant access to somebody else? If the answer needs a phone call to them, you do not own it.

The accounts and the credentials

Everything with a login and a bill should be in your name, on your payment method, with the agency added as a user.

• The domain registrar. The most damaging single item on this list. A domain held in an agency account is leverage, whether or not anyone intends to use it that way.
• DNS. Separate from the registrar, and the thing you need fastest in an emergency.
• Hosting and any CDN or WAF. Including the ability to open a support ticket with the provider yourself.
• Payment gateways and the acquirer relationship. These are contractual relationships with your business, and they should never be intermediated.
• Search Console, Merchant Center, analytics and tag management. Years of historical data that cannot be recreated if access is lost.
• The error tracking and uptime monitoring accounts. Because the history of your incidents is evidence about your store.

Adding an agency as a user costs nothing and takes a minute. Any resistance to this arrangement is itself the answer to your original question.

The deployment pipeline

If deploying your store requires one particular person’s laptop, you do not have a pipeline, you have a dependency with a pulse.

Deployment configuration belongs in the repository, as code, so it travels with the code. A new team should be able to read how the store gets from a commit to production without anyone explaining it. Secrets are the exception and live in a secret store, but the list of which secrets exist and what they do should be written down.

The same applies to environments. Staging should be reproducible from the repository plus a database restore, not a machine that was hand-assembled in 2022 and has been patched ever since.

The knowledge

This is the asset most merchants do not think to ask for, and it is the one that decides how expensive your next agency is.

You want a document that describes the state of your store and is written to be useful to somebody who does not work there. The module inventory, with which ones are customised and why. The known issues and the deliberate compromises. The integrations, their owners and their failure modes. The parts of the codebase that are fragile and the reason.

The distinguishing feature of a real one is that it is vendor neutral. If the document only makes sense as an argument for continuing to employ the people who wrote it, it is a sales asset, not a handover. A technical audit worth paying for produces a plan that works with any partner, including one who is not the author. That is precisely what makes it worth paying for.

The data, and a restore you have actually tested

You should be able to obtain a current database export and a copy of your media without asking permission, and you should have restored one at least once.

An untested backup is a belief, not a safeguard. The common discovery during a real incident is that the backup exists, is being written faithfully every night, and cannot be restored, because it omits a table, or the media lives somewhere the backup never looked, or nobody has the encryption key. Test a restore into a scratch environment once. The exercise takes an afternoon and it converts an assumption into a fact.

Where proprietary is legitimate

An honest section, because the maximalist position is not realistic and you should be suspicious of anyone who pretends otherwise.

Agencies build their own tooling. Deployment frameworks, monitoring layers, internal libraries, in-house modules that make their work faster. That is normal, it is often what makes them good, and it is reasonable that you license it rather than own it. The same is true of third-party commercial extensions, which you license too.

The question is not whether anything is proprietary. It is what stops working if you leave. A proprietary deployment tool that you could replace with a standard pipeline in a week is a convenience. A proprietary layer that your checkout depends on at runtime is a hostage situation. Ask which category each item falls into, and get the answer in writing while everyone is still enthusiastic.

Three questions for the first call

These are short, they are hard to deflect, and the quality of the answer tells you more than an hour of portfolio.

• If we part ways on Friday, what stops working on Monday? A good answer is specific and short. A vague answer means nobody has thought about it, which is worse than a bad answer.
• Who can lock me out of anything? Walk the list above. The correct answer is nobody.
• Could another agency read your handover and be productive in a day? Then ask to see an example, with the client details removed. Agencies that write good documentation are pleased to be asked.

The point of all this

None of it is about distrust. It is about making the relationship voluntary on both sides, which is the only arrangement that stays healthy. An agency that knows you could leave next month behaves differently from one that knows you cannot, and the difference shows up in the work long before it shows up in a contract.

If you are still deciding who to work with, the questions that separate a capable Magento agency from an expensive one are worth reading alongside this. And if you have not settled whether you want an agency at all, we compared that against hiring in-house here.

Book a free strategy call

Not sure what you currently own? Bring us your setup and we will walk the list with you: repository, credentials, pipeline, documentation and backups. You will get an honest answer about where you stand, including the parts we cannot help with. Book a free strategy call.