Switching ecommerce agency: how to take over your store safely

Store owners who have had enough of their agency come to us regularly. Tasks drag on for weeks, the store keeps going down, and nobody gives a straight answer when they ask “why?”. I’ve been writing code for twenty years, and I know one thing for sure: deciding to switch agencies is the easy part. The hard part is taking the store back without losing anything along the way.

Why companies switch agencies

There’s nothing shameful about changing agencies. In US advertising, where companies switch agencies routinely, a relationship now lasts about seven years on average². Every partnership ends at some point, so it pays to know what state the store will be in when yours does.

What’s striking is how differently the two sides see the break-up. In a survey of brands and their marketing agencies, the reason clients gave most often was dissatisfaction with delivery: 48% of them said so. Agencies ranked that reason only seventh, and put changes in the client’s leadership first¹.

Think about that for a moment. If the agency doesn’t see a problem, it won’t be in a hurry to hand the store over properly either. So the takeover has to be planned on your side.

What the previous agency leaves behind

After a few years of work, a store is full of code nobody but its authors understands. Often it has quick-fix workarounds and modules nobody ever updated. Documentation usually doesn’t exist at all. Developers call this technical debt: every postponed fix comes back later with interest.

What does it cost? Stripe asked over a thousand developers where their time goes:

Large companies see the same thing. McKinsey found that 10–20% of the technology budget meant for new products goes on paying down technical debt⁴. That adds an extra 10–20% to the cost of every new project⁵.

Missing documentation makes it worse. 61% of developers spend more than 30 minutes a day searching for answers, and 30% say knowledge locked in individual people’s heads slows them down ten or more times a week⁶. When those people work at the agency you’re leaving, that knowledge walks out the door with them.

Who actually owns your store’s code?

This is where many store owners get an unpleasant surprise. Paying for a store doesn’t mean its code is yours.

We work under Polish law, so that’s the example here. A computer program is protected like a literary work. The rights to code written by an agency’s employee belong to the agency, not to its client⁷. They pass to the client only when the contract explicitly says so. And if it doesn’t?

In the absence of an explicit provision on the transfer of a right, the author is deemed to have granted a licence. Polish Act on Copyright and Related Rights, Art. 65 (own translation)

Unless the contract says otherwise, such a licence lasts five years and then expires⁷. On top of that, a transfer of economic rights must be made in writing or it is void, and the contract covers only the fields of use it lists explicitly⁷. Accepting a quote by email doesn’t meet that requirement.

What does this mean in practice? Before you give notice, have a lawyer read the contract. Check whether it transfers the rights to the code or only grants a licence, and whether it allows another company to modify the code. That decides whether a new agency can legally develop your store.

The logins you need to ask for

The most common takeover problem is a mundane one: the accounts are registered to the agency, or to someone who used to work there. Make a list and take everything back before the contract ends:

1. The code repository. The full change history, not a zip file sent by email. Ideally under your company's own GitHub or GitLab account.
2. Server and hosting. The provider's panel, server access, backups of the database and files. The hosting contract should be in your company's name.
3. Domain and DNS. A .pl domain is controlled by its holder: the holder gets the authinfo code from the registrar and confirms the transfer through a link sent to their email address⁸. If the registry shows the agency's email, change it first. For .com domains, the registrar has 5 days to provide the code⁹.
4. Payments and integrations. The payment gateway account and the keys to your ERP, couriers, marketplaces and invoicing systems. After the takeover, the keys need to be replaced with new ones.
5. Google accounts. In Search Console, adding a new owner isn't enough: the old verification token has to be removed from the site, or the previous agency keeps its access¹⁰. A Google Analytics property can be moved to your account together with its data¹¹.
6. The store's admin. Admin accounts in the store, the list of installed modules and the licences for paid extensions.

The old agency still has the keys

Taking back the logins is half the job. The other half is checking who else still has them.

In the summer of 2024, criminals broke into 4,275 Magento and Adobe Commerce stores through a single vulnerability, 5% of all such stores¹². When the attackers started scanning stores automatically, 75% of them hadn’t installed the fix. Sansec, the company that tracked the attacks, makes a point that matters for any takeover: the patch alone isn’t enough. You have to rotate the encryption key, reset admin passwords and remove unknown integrations¹².

The same applies when a contract with an agency ends. The UK’s NCSC recommends removing a supplier’s access once it’s no longer needed, and having the contract set out how your data is returned and deleted when it ends¹³. The GDPR says the same about your customers’ data: the company you entrusted it to must delete or return it, copies included, when the service ends¹⁴. Ask outright about database copies on test servers and developers’ laptops.

What a good takeover looks like

A good takeover follows a set order. A new agency that promises new features from day one usually doesn’t yet know what it’s taking on.

• Collecting the logins. Everything on the list above, checked in practice: does the backup actually restore, and is the code in the repository the same code running on the server?
• Audit. The platform version and its support end date, modules, changes to the code that depart from the standard, security. Regular support for Adobe Commerce 2.4.6, for example, ended in August 2026¹⁵. A store on that version needs an update before anyone builds anything new.
• Stabilisation. First remove the causes of crashes and outages, then everything else. A customer who can’t place an order won’t appreciate the new banner.
• Documentation. A written record of modules, integrations, how changes are deployed and who has which login. If you ever switch agencies again, you won’t be starting from scratch.

Not all debt needs paying off at once. Even McKinsey writes that it usually doesn’t make sense to get below 10% of tech debt, because some of it isn’t worth paying down⁵. A good agency will tell you what to fix now and what can wait.

What to put in the contract with your new agency

When you sign with a new agency, check that the contract includes these clauses:

1. Transfer of rights to the code. In writing, with the fields of use listed, including the right for other companies to modify the code⁷.
2. Accounts in your company's name. The repository, hosting, domain, payments and Google accounts belong to you, and the agency is given access to them.
3. Documentation as part of the job. The agency keeps a running record of integrations, modules and how changes are deployed.
4. Exit terms. The notice period, the handover of logins and code, and help for the next developer during that time.
5. A data processing agreement. With a clause on deleting or returning customer data when the contract ends¹⁴.

Have a lawyer look over the contract anyway. This list will help you ask them the right questions.

How we take over stores

We take over projects started by other companies, clean up the code we inherit and keep developing them. Our longest partnership has lasted over 10 years.

We took over the Quiosque store from its previous developer in 2020. We started with the repository, the servers and the deployment process, and wrote down the modules and the places where the code bypassed standard Magento. All the clean-up happened on the live store, during normal trading.

System 3D came to us in 2023 with outages and a search engine, Elasticsearch, that kept failing. After a Magento update, catalogue optimisation and Varnish, a cache that serves ready pages faster, the outages and search failures stopped. Only now, on a stable foundation, are we building the store’s new front end. You can read more about how we work with stores on our ecommerce stores page.

If you remember one thing from this post, let it be this: a store whose code, domain and accounts aren’t registered to your company isn’t fully yours.