In short
Switching Magento agency does not have to mean downtime or lost orders. The risk sits in the handover: access you do not own, code nobody has reviewed and patches nobody can confirm. This checklist shows what to secure before you switch Magento agency, how to run the handover step by step on a staging copy, and what to check in the first 30 days with your new Magento support agency.
Signs it is time to switch Magento agency
Most agency relationships end slowly rather than with one big incident. These are the signs to take seriously.
- Tickets wait days for an answer, and urgent problems are handled like normal requests
- Nobody can tell you which Magento version and patch level the store runs
- Security patches are installed late, or directly on the live store without a staging test
- Every update breaks something, and the fixes are billed as new work
- You do not have access to your own code, server or accounts, or you have to ask for it every time
- The developer who knew your store has left, and the rest of the team starts from zero
- You need skills the agency does not have, for example Hyvä, Adobe Commerce or server work
What you must own before you switch Magento agency
Before you announce anything, check that every account and key below is in your company’s name, or that you at least have admin access to it. Anything the old agency holds alone can stop the handover.
| What | Where it lives | Why it matters |
|---|---|---|
| Git repository | GitHub, GitLab or Bitbucket | The full code history, including custom modules and theme changes. It should sit in your organisation, with the agency invited as a member. |
| Server and hosting | Hosting provider account, SSH and control panel | Without owner access you cannot move, scale or restore the store. |
| Magento Marketplace access keys | Commerce Marketplace account (MAGEID) | Composer uses these keys to download Magento and Marketplace packages from repo.magento.com. Extensions bought on the Marketplace are linked to the account that bought them. |
| Composer auth.json | Project folder or Composer home on the server | Holds the credentials for private package repositories. It should not be in Git, so list every repository it contains. |
| Hyvä licence or keys | Hyvä account | The Hyvä theme is free and open source, but Composer access uses a key linked to your domain. Hyvä Checkout, UI and Commerce are paid licences. |
| Extension licences | Each vendor’s customer account | Licences bought by the agency may be in its name. Ask for a transfer, or for keys and downloads in your name. |
| Domain, DNS and Cloudflare | Registrar and Cloudflare accounts | Whoever controls DNS controls where the store points and how its email is delivered. |
| Payment and shipping API keys | Payment provider and carrier dashboards | Keys should be created in your accounts and changed after the switch. |
| Google accounts | GA4, Search Console, Merchant Center, Google Ads, Tag Manager | Your data and its history. You should be the owner, the agency only a user. |
| Backups | Hosting and offsite storage | A recent database and media backup that you can download yourself. |
| Documentation | Wiki, README, ticket system | Deployment steps, cron jobs, integrations, custom modules and known issues. |
Adobe’s documentation explains that Marketplace access keys belong to the MAGEID account that created them: the public key is the username and the private key the password for repo.magento.com. If the old agency created the keys in its own account, create new keys in yours and have them added to auth.json during the handover. Composer’s own documentation recommends keeping auth.json out of Git, so you will not find it in the repository.
Step-by-step handover without downtime
- Audit: the new agency reviews the store before it changes anything, including the Magento version, extensions, custom code, server stack, cron, indexers, logs and speed.
- Access transfer: you create personal accounts for the new agency in Git, hosting, the Magento admin, Cloudflare and Google. No shared passwords and no logins passed on from the old agency.
- Staging copy: the new agency builds a staging environment from the Git repository and an anonymised copy of the database, and checks that it deploys cleanly.
- Code review: the code on the live server is compared with the Git repository. Changes made directly on the server, and modified core files, show up at this step.
- Patch level check: Adobe’s Commerce Version Tool, run with php vendor/bin/patch-status from the Magento root folder, reports which monthly security patches are installed and which are missing. The Quality Patches Tool command vendor/bin/magento-patches status lists the quality patches that are applied.
- Monitoring: uptime, error logs, cron, queues and checkout checks are set up before the old agency’s access is removed, so nothing runs unwatched.
- Credential rotation: once the new team works on its own, the passwords, SSH keys, API keys and Marketplace keys the old agency used are changed or removed.
- Overlap and cut-over: keep a short overlap in which the old agency can still answer questions, then end its access on an agreed date.
None of these steps touches the live store. Customers keep ordering while the handover runs in the background.
The first 30 days with your new Magento support agency
- A written audit report with the version, patch level, risks and a priority list
- Missing security patches installed on staging first, then taken live
- Backups checked by actually restoring one on staging
- Deployment documented, so every developer in the team takes changes live the same way
- A plan for the coming months, such as an upgrade, speed work or an extension clean-up
What to ask a new Magento developer or agency
- How do you run the handover, and what do you need from us in the first week?
- Will you compare the code on the server with the Git repository?
- How do you install security patches, and how do you confirm the patch level afterwards?
- Which response times do you agree for urgent problems, and are they in the contract?
- Will all accounts, keys and licences stay in our name?
- What do you document, and where can we read it?
How to leave the old agency on good terms
- Read the contract first: notice period, open invoices, and who owns the code and the licences
- Give notice in writing, with a clear end date and a list of what you need handed over
- Ask for documentation, open tickets and known issues, not only passwords
- Pay open invoices on time, because a handover goes more smoothly without a dispute
- Remove access only after the new agency has confirmed that everything works
Mistakes to avoid when you switch Magento agency
- Removing the old agency’s access before you have a working copy of the code and the database
- Assuming that the Git repository matches the live server without checking
- Starting an upgrade or a redesign in the first week, before the audit is finished
- Sharing one admin login between several people instead of creating personal accounts
- Forgetting cron jobs, integrations and email settings that exist only on the server
- Leaving keys and passwords unchanged after the old team has gone
Switching to MageBooster
MageBooster is a Magento 2 agency for Magento Open Source, Adobe Commerce, Mage-OS and Hyvä. Switching to us takes four steps: an audit and access verification in the first week, 24/7 monitoring from the second week, and then ongoing care with monthly security patches tested on staging and a monthly report. It starts with a free analysis of your store, and you decide what comes next.
See our Magento support and maintenance service →
Read also: why work with a Magento agency? →
Let us get in touch with you
Leave your details and your store address. We look at your store first and contact you within one business day, by phone, WhatsApp or email, whichever you prefer.
English
German
Dutch
Turkish