Do we need the outgoing agency's cooperation to change Magento support agencies?

It helps, but how much you need it depends on what you already own. If the repository, hosting, domain and Adobe accounts are in your name, a new agency can start from those and the outgoing team's job is mainly to explain what is undocumented. If the agency holds those accounts, its cooperation becomes essential. That is why we tell people to sort out ownership before they give notice.

Who should own the Adobe Commerce licence?

Your business. On Adobe Commerce on Cloud, Adobe describes the License Owner as the person in your business or finance organisation who manages payments and business transactions, and says changing the License Owner means contacting your Adobe Account Team. Agencies should work through shared access, which Adobe says can be revoked but not transferred.

Should both agencies work on the store at the same time?

Only briefly, and with one team owning deploys from a fixed date. The overlap is the riskiest part of a handover: two teams deploying, a cron job or monitoring account that disappears when the contract ends, and credentials rotated too early or not at all. Keep the overlap short and write down who responds to an incident during it.

Does changing agencies mean rebuilding the store?

No. A takeover should start with an audit, not a rebuild. When we took over Aelia Duty Free's Adobe Commerce platform, the first phase was triage and stabilisation, and feature work began only once the platform was safe to change. A rebuild is the most expensive recommendation available, and it is the right one less often than it gets proposed.

Changing Magento Support Agency: How a Takeover Works

If you are unhappy with your Magento or Adobe Commerce support agency, changing can feel riskier than staying. The agency holds the knowledge, often holds the accounts, and may be the only team that has ever deployed your code. That is why the change is worth doing in order.

Most rescue pages answer this with a process diagram. Here is the playbook we use, and three takeovers we can name because they are still running.

Signs it is time to change

Support arrangements drift for ordinary reasons: the developer who knew your store left, or the retainer covered fixes but not upgrades. No single sign below means your agency is bad. Several together usually mean the arrangement has stopped working.

Tickets age. Fixes take weeks, and the same bugs come back.
Nobody knows your patch level. You cannot get a straight answer on which version you run or when Adobe stops patching it.
Only they can deploy. There is no documentation, and you cannot see the repository.
The upgrade keeps moving. Every quarter it is next quarter’s job.
Every answer is a rebuild. An agency that wants to rebuild before it will fix anything is solving its own problem.
A new person every month. Continuity is most of what you pay for in support.

What you need to own before you switch

Do this before you give notice. It is worth doing even if you stay.

The code repository, with full history, in an organisation you control. A copy of the live server is not the same thing.
Hosting and cloud accounts. The server, cloud project, CDN and backups should be billed to you and administered by you.
Your Adobe Commerce licence or Magento account. More on this below.
DNS and the domain registrar. If the agency registered your domain, move it into your name.
The payment gateway. Check who holds the admin login and the API keys.
Third-party extension licences. Find out which account bought each one.
Credentials. Magento Admin, SSH, database, and the API keys for your ERP, PIM, shipping and email services.
Documentation. How the store deploys, what is customised, and what runs on a schedule.

The Adobe accounts

On Adobe Commerce on Cloud, Adobe describes the License Owner as the person in your business or finance team who manages payments and other business transactions with Adobe, and says that person “can add user accounts to provide access to code, manage branches, enter tickets, and support environments.” If that person is not in your business, Adobe says: “If you must change the License Owner on your account, you must contact your Adobe Account Team.”

Agencies should work through shared access, not your login. Adobe lets the primary account holder share the Commerce account with “trusted employees and service providers who help manage your site”, and notes that “Shared access can be revoked, but not transferred.” Revoking it is how the outgoing agency’s access ends.

Three details catch people out:

Composer keys. Your store downloads Magento packages using authentication keys from a Commerce account. Adobe lists “Using keys generated from a shared account” as a cause of failed Cloud deployments, and says to use keys generated under “the currently entitled Adobe Commerce account.” If your keys came from the agency’s account, replace them before its access ends.
Marketplace extensions. Adobe’s account transfer guide says “Extension purchases cannot be transferred to a different account.” If the agency bought extensions on its own Marketplace account, sort out the licences while you are on good terms.
Commerce Services keys. For Live Search or Product Recommendations, Adobe says developers with shared access “cannot generate the keys on the license owner’s behalf”. Someone in your business has to.

Read your contract before you tell anyone

Check your own agreement for the notice period, what happens to work in progress, who owns the code and designs, whether handover help is included or billed, and anything tied to unpaid invoices. We cannot tell you what yours says. Read it before the conversation.

The handover checklist

Ask the outgoing agency for these in writing, so both sides know when the handover is done:

Admin rights moved to accounts you own, for everything in the ownership list above.
The full repository with history, and confirmation that what is deployed matches the main branch.
A list of every extension: version, where it came from, and whose account holds the licence.
Any patches applied outside Composer, and any changes to core files.
Environment details: hosting setup, cron jobs, queues, search, caching, and whether staging matches production.
An integration map: what talks to the store, in which direction, with which credentials, and who to call at the other end.
Open tickets, known issues and anything half-built.
How a deploy works, step by step.
Renewal dates for domains, certificates, licences and any service billed through the agency.

A paid handover session with the developer who knows the store is cheaper than working this out from the code.

The risks during the overlap

There is usually a period when both agencies have access. That is where things break.

Two teams deploying. Agree one deploy owner from a fixed date.
Hidden dependencies. A cron job on the agency’s server, monitoring on its account, transactional email through its mail service. These fail quietly after the contract ends.
Credentials. Rotate admin passwords, SSH keys, API keys and Composer keys once the outgoing team’s access ends. Adobe’s key documentation mentions disabling keys after someone leaves your organisation. Rotate too early and you lock out the people still doing the handover.
Cloud access. New users need an Adobe ID before they can be added to a Cloud project, and Adobe says: “After adding users, redeploy all environments to apply the changes.”
Incidents and timing. Write down who responds if the store goes down mid-handover, and do not change teams just before your biggest trading period.

The first 30 days of a takeover

The first month is for knowing what you have, not shipping features. The general code assessment is in inheriting a legacy PHP application. For Magento, it covers six things.

Code audit. Get the store running locally from the repository. If that cannot be done, that is the first finding. Then find the custom modules, core overrides, and anything outside Magento that writes to its database.

Patch level. Check the version with bin/magento --version and compare it with Adobe’s dates. The version string does not show isolated patches or hotfixes, so also run php vendor/bin/patch-status and check for hotfixes such as VULN-39341; how to apply Magento security patches covers both. Regular support for 2.4.6 ended on 11 August 2026, and for 2.4.7 it ends on 31 May 2027. The full table is in Magento 2.4 end of life dates. If the store is behind on its own line, the latest patch release is usually the first change worth making.

Extensions. Check each one is maintained, compatible with the version you are heading for, and licensed to you. The version jump is rarely the hard part of an upgrade. Extensions and custom code are.

Environments. Confirm staging exists, matches production, and that deploys run from the repository rather than by hand.

Monitoring. Uptime, errors, cron and integrations, alerting to accounts you own. A sync that fails overnight should reach a dashboard before it reaches a customer.

Backlog triage. Sort the inherited tickets into broken, risky and wishlist. Stabilise first. Feature work starts once the platform is safe to change.

Takeovers we can name

These are still running, which is the measure that matters.

Aelia Duty Free. An Adobe Commerce platform serving Aelia’s airport stores in Australia and New Zealand. Under a previous support arrangement it suffered slow issue resolution, performance problems and unaddressed bugs. We took over support and development and did not start by rebuilding. The first phase was triage: stabilise the platform, then clear the long-standing issues affecting performance and access. Feature work began once it was safe to change. The platform has operated across Aelia’s airport stores since 2021, and we remain its ongoing partner.

Merivale. We took over the full support contract for Merivale’s website and digital infrastructure from a previous digital partner: maintenance, performance, integrations with booking and CRM tools, new features and hosting.

Customer Owned Banking Association. A website and member portal inherited from a previous agency. We ran a full design and code review before proposing anything, set up environments and CI/CD, fixed and enhanced what was there, then moved to an ongoing support contract.

Aelia is the Adobe Commerce one. The Merivale and COBA case studies are not about Magento, but the hard part of a takeover, keeping a live platform running while it changes hands, is the same.

Keeping it civil

You will need the outgoing agency’s help, and a civil exit is a faster one.

Give notice the way your contract says, and pay what is owed. Access disputes and invoice disputes tend to become the same dispute.
Ask for the handover as a written list with an end date, not a series of favours.
Keep the new agency out of the blame. Support arrangements stall for ordinary reasons, and a new team that criticises the last one will one day be the last one.

We hold ourselves to the same test: code in repositories you own, documented setup, and a team that could hand over if you asked. We would rather be kept because the work is good than because leaving is painful.

Change agency, or change platform?

Sometimes the agency is not the problem. If you are facing a third paid upgrade, ask whether to stay on Magento or move before you sign a new support agreement. If the store is in real trouble, that is project rescue. If it needs a team that patches, upgrades and answers, that is Magento support.

Sources: Onboarding to Commerce, Manage user access, Share a Commerce account, Transfer an Adobe Commerce account, Get your authentication keys, Can’t access Adobe Commerce on cloud repo: 403 Forbidden or 404 Not Found error when deploying, Commerce Services Connector and Adobe Commerce lifecycle policy (Adobe).

Changing Magento Support Agencies: How a Takeover Actually Works