Switching Ecommerce Agencies: The Handover Checklist

Switching ecommerce agencies is the one project nobody plans. The decision takes months; the handover takes a fortnight, and the fortnight decides whether the store is still yours at the end of it. This handover checklist is the list we use when a merchant brings us a store another agency built, written for the merchant rather than for either agency.

Handovers go wrong for a simple reason. The outgoing agency has no reason to be thorough: it is losing the account, and every hour spent on you is an hour it does not bill. The incoming agency is willing but does not yet know what to ask for, because it has not seen the code, the hosting or the accounts opened in the old agency's name over the years.

What falls through the gap is never the theme. It is the Composer key that downloads Magento, the registrar login, the gateway account opened under a developer's personal email, and the note that said why the checkout was patched. Each surfaces weeks later as an outage or a bill.

Before you give notice

Confirm what is in your name

List every account the store depends on and, against each, whose email address owns it: the platform admin, the repository, the registrar, the hosting panel, the payment gateway, analytics, the email sender, the search service, the CDN. Anything owned by an address at the agency's domain is a transfer to request, and it is far easier to request from a supplier you are still paying.

Export what you can

Before anyone's access changes, take your own copies: a full database backup, the media folder, a zip of the theme and custom code, last year's analytics reports, the DNS zone file, and screenshots of the admin configuration pages that matter. It is the insurance in case the handover stalls.

Pick the overlap window

Agree the dates in writing: the day the new team gets read access, the day it gets write access, the day the old team's access ends. Two weeks is enough for a stable store; a store mid-project needs longer, and a broken store is covered at the end of this article.

The handover checklist: code and repositories

The repository in your organisation

The store's code should live in a repository owned by your company, with the agency's developers as collaborators you can remove. If it sits under the agency's organisation, ask for a transfer rather than a copy: a transfer keeps the history, the branches and the pull requests, and the history is where the reasons live.

Branches and deploy keys

Ask which branch is production, which is staging, and whether anything on production was never merged. Then collect every deploy key and access token the pipeline uses and rotate them during the overlap week, so nothing the old agency holds can still push to your store.

The build and deploy pipeline

How does a change reach production: a pipeline in the repository, a script on the server, a button in a panel, or one developer's laptop? If it is the laptop, the pipeline is the first thing to rebuild.

Local setup, documented

A new developer should be able to run the store from the repository and a readme. If the readme does not exist, ask the outgoing agency to write one while the steps are still fresh; it costs them an afternoon and saves the new team a week.

Platform accounts

Magento Composer keys under your own Marketplace account

Magento and Adobe Commerce download their own code, and every extension bought on the Marketplace, with a pair of authentication keys. Adobe's documentation says those keys are generated in a Commerce Marketplace account, the public key is the username and the private key the password, and they are tied to the account's MAGEID; a key can be disabled or deleted when the person it was issued to leaves. If the keys in your store's configuration belong to the agency's account, the next upgrade fails the day they are revoked. Create your own account, generate your own keys, and have the new team swap them in.

Adobe Commerce Cloud project ownership

On Adobe Commerce on cloud infrastructure the project has an owner and users with roles. The owner should be a person at your company, and the licence and the support entitlement should be in the company's name.

Shopify store owner and collaborator access

Shopify has one store owner; everything else is staff or collaborator access. The owner must be you. The outgoing agency's collaborator account is removed in one click, and the incoming agency requests its own through Shopify's collaborator flow, so nobody shares a password.

App and extension licences

Every paid extension and app has a licence tied to an account and usually a domain. List them, confirm whose account each sits in, and move the ones in the agency's. A lapsed licence stops the security releases you rely on.

Domain and hosting

Registrar login and the AuthInfo code

The domain is the store. If the registrar account is not yours, this is the transfer to make first. ICANN's transfer policy sets the floor: the registrar must give the registered name holder the AuthInfo code, must lift a transfer lock within five calendar days of a request if it offers no self-service way, and may not withhold the code or the unlock because of a payment dispute. One trap: a change of registrant starts a 60-day lock on transfers between registrars, so change the ownership details and the registrar in the right order, not in the same week.

DNS records, exported

Export the full zone before anything moves: the A and CNAME records for the store, the MX records for email, and the TXT records that verify the domain for Google, your email sender and your payment provider. One dropped TXT record stops transactional email for everyone.

Hosting and CDN accounts

The hosting panel, the server provider and the CDN each have an owner and a billing contact, and both should be you. Hosting resold under the agency's account needs a transfer or a migration to your own, and the migration is usually cleaner.

SSL certificates

Find out where the certificate comes from and when it renews. One issued through the CDN renews itself while the DNS is right; one installed by hand expires on a date somebody has to know.

Server and SSH access

List every SSH key and user on the servers and remove the ones belonging to people who no longer work on the store. The new team gets its own keys; nobody inherits one.

Payments and data

Payment gateway and processor accounts

The merchant account, the gateway and any fraud or tax service each have an owner, API credentials and a webhook pointing at your store. Confirm the owner is you, record where the credentials live, and rotate the API keys during the overlap week.

The PCI DSS payment-page script inventory

PCI DSS 4.0 requires an inventory of every script that runs on your payment pages, a reason for each one, and a way to detect when they change. The outgoing agency usually holds that list, if anyone does. Ask for it, and if it does not exist, make writing it the new team's first security task; patch cover for Magento keeps it current afterwards as part of the monthly report.

Analytics and tag manager

Google Analytics, Search Console, the tag manager container and the ad accounts should each be a property in your organisation with the agency as a user. A property created under the agency's account cannot always be transferred, and a new one loses your history.

Email and marketing accounts

The transactional email sender, the newsletter platform, the review service and any loyalty tool hold customer data, and their account owner is the data controller in everyone's eyes but yours. Move them to your name, after exporting the lists and templates.

The database backup

Take a fresh backup on the old team's last day and another on the new team's first, and keep both where neither agency can reach. If a dispute arises about what changed, those two files settle it.

Knowledge

Architecture notes

What runs where, which services the store calls, which cron jobs exist and what each does. If none of it was written down, an hour on a recorded call with the outgoing lead developer is worth more than a document written under protest.

The integration map

Every system the store exchanges data with, the direction of each flow, the credentials involved and the person to call when it breaks: ERP, warehouse, PIM, marketplace feeds, carriers. Integrations fail silently: nothing looks wrong until an order misses the warehouse.

Open tickets and known bugs

Ask for the backlog, including what the agency decided not to fix. The known bugs are the most valuable page in the handover; without them the new team rediscovers each one at the cost of a day.

The release calendar

What is scheduled: the platform upgrade, the extension and certificate renewals, the campaign launches that cannot slip. A handover in the middle of a Magento upgrade is a different handover, and the calendar is how you find out.

Switching ecommerce agencies without losing a week

One team edits at a time

During the overlap only one agency deploys: the old team finishes and freezes, the new team reads, then takes over. Two teams editing the same store produce changes nobody can attribute, and the first incident becomes an argument instead of a fix.

Remove access last

Do not revoke the outgoing agency's access until the new team has confirmed it can deploy, restore a backup and reach every system on the integration map. Then revoke everything at once: repository, servers, panels, accounts, keys.

If the outgoing agency goes quiet

It happens, which is why the exports come first. With your own backup, your own copy of the code and ownership of the domain and hosting, a quiet agency is an inconvenience. Without them it is a hostage situation, and the registrar and the platform are where you start recovering control.

When the handover is already a rescue

Some handovers are recoveries: the launch broke the store, the upgrade stalled between versions, the developer stopped answering, and the question is not who maintains the store next but whether it can be saved. That is a different engagement, and it starts with a read rather than a list.

Our ecommerce project rescue begins with a free two-business-day read of the repository and the store, then a fixed-scope first week that recovers access, secures the store and fixes what is losing orders, with a written state of the store and a plan. We assess without involving the previous agency, which is usually the only way to get an honest answer.

On Magento the same read covers the version, the patch level, the extension stack and whatever the previous team changed in core, and Magento project rescue takes it from there, from stabilising a live store to finishing a stalled upgrade.

Key takeaways

• Confirm ownership before notice: every account the store depends on should belong to an email address you control.
• Export your own copies first, so a stalled handover is an inconvenience rather than a crisis.
• The small things are the dangerous ones: Composer keys, the registrar login, the gateway credentials, the script inventory.
• One team edits at a time, and the old team's access is removed last, all at once.

Conclusion

Switching ecommerce agencies is a logistics problem dressed up as a relationship problem, and the logistics are still yours to control. Work through the handover checklist before you give notice, keep the overlap short and disciplined, and the store reaches its new team with its code, its accounts and its history intact. If it is already past that point, a rescue read tells you where you stand inside two business days.