Most CTOs do not call us when they are dating their current Magento agency. They call us about six weeks after they realized the partnership is not working but before they have a clean exit plan. That window is the most dangerous moment in a replatform. The wrong move here costs you the project. The right move keeps the build alive, preserves your code quality, and gets you to launch only slightly behind schedule.
Switching agencies mid-project on Adobe Commerce is not the same as switching agencies on a marketing retainer. You are not just changing who runs your campaigns. You are changing who has commit access to the production codebase, the deployment pipeline, the staging environment, and the secrets that gate your payment processor. Done badly, you can end up with two angry teams, no working build server, and a launch date that has slipped twice before the new agency has shipped a single feature.
This guide is the playbook we run when clients ask us to step into an in-flight Adobe Commerce build. The mechanics are mostly operational, not technical, which is why teams that focus only on the code transfer usually fail. The political work is the work.
Before the call: get your house in order
The decision to switch is almost never the bottleneck. The bottleneck is preparation. You want to walk into the agency switch already holding the four artifacts that determine how fast a new partner can get productive.
The first artifact is a complete repository inventory. List every repository, who has commit access, where it is hosted, what its branching model is, and what state the main branch is in. Second, a deployment topology document that names every environment from local through production, who owns each, and what the promotion path looks like. Third, a credentials inventory that lists every third-party service the store integrates with along with the contact who owns each. Fourth, a list of in-flight tickets with current status and the engineer who last touched each one.
If you cannot produce these in 48 hours, you do not have an agency problem yet. You have a documentation problem. Fix that first. Bemeir has inherited Magento builds with no repository inventory at all, and the first two weeks of every one of those engagements is spent on archeology rather than progress. That is two weeks of payroll you are spending on a transition tax, not on shipping features.
The agency switch is a project, not a meeting
Treat the switch itself as its own scoped project with a named accountable owner, a deadline, and a budget. Most teams treat it as a series of conversations that happen in parallel to other work. That is how the launch slips.
A reasonable switch project has six workstreams running in parallel. Code transfer, infrastructure transfer, knowledge transfer, in-flight work continuity, vendor and integration notification, and stakeholder communication. Each one has a separate owner and a separate timeline. The owner of the whole switch project is almost always the in-house CTO, because no agency can own their own transition out of an account credibly.
The table below is the cadence we recommend for a four-week transition. Compress it if you must, but recognize that compression buys you risk in the form of regressions during the cutover.
| Week | Code transfer | Infra transfer | Knowledge transfer | In-flight work |
|---|---|---|---|---|
| 1 | Audit repos, snapshot main | Inventory environments | Recorded walkthroughs of architecture | Freeze new feature work |
| 2 | New agency clones, runs build locally | New agency takes read access | Architecture decision log review | Existing agency finishes ticketed work |
| 3 | New agency takes write access on feature branches | New agency takes deploy access to staging | Handover Q&A sessions twice a week | Joint sprint with both teams |
| 4 | Existing agency archives access | New agency owns production deploys | Documentation gaps closed | New agency owns all new tickets |
The technical handover that actually matters
A lot of agency switches die on technical handover because the outgoing team is given a vague brief like “document what you built.” That produces 80 pages of nothing useful. Be specific. The outgoing team should produce three artifacts: a written architecture decision record that explains why the major patterns exist, a recorded video walkthrough of any custom modules that have non-obvious business logic, and a tested local development setup that the incoming team can stand up in under two hours.
Make the incoming agency run the build locally on the kickoff call. That single test surfaces 80 percent of the undocumented infrastructure assumptions that would otherwise show up at the worst possible time. Our team at Bemeir’s Magento development practice treats the local build replay as the official close of the handover phase. If we cannot run the project, we have not actually inherited it.
For composer dependencies, run a fresh `composer install` against the lockfile on a clean machine. Do not assume the lockfile is accurate. Inherited Adobe Commerce projects routinely have lockfiles that diverge from production because the outgoing team patched something manually in production and never committed it back. The Adobe Commerce DevDocs guide to package management is the reference point for what should be true on a healthy project.
Keep production safe during the transition
The single largest risk during an agency switch is a production incident in the gap between teams. Reduce that risk by enforcing three rules during the transition window.
First, no production deploys for the first 14 days unless they are security patches. Second, the outgoing team retains read access to production for 30 days even after the new agency takes over so you have a fallback for diagnostic questions. Third, every credential rotates the day the outgoing team is officially out, but in a planned sequence that does not break running cron jobs or scheduled syncs.
Adobe Commerce gives you specific footguns to watch during this window. Indexer changes, cache invalidation strategies, and admin user audit trails should all be reviewed before any new deploy. The OWASP cheat sheet on credential rotation is a useful guardrail even though it is not Magento-specific.
Communication is the work
You will spend more time on communication during an agency switch than on technical handover. Plan for it. The stakeholders who need a structured update are the executive team, the in-house engineering team, the marketing and merchandising teams, the finance team for contract reasons, and any vendor partner whose work touches your store.
The communication you owe each group is different. Executives need confidence that the build will still land. Engineering needs to know how their workflow changes. Marketing needs to know whether any campaigns or seasonal pushes get rescheduled. Finance needs the paper trail. Vendors need to be told who their new technical contact is so support tickets do not get lost in the gap.
Write the comms plan before you announce the switch internally. Then announce internally before externally. Bemeir’s experience is that the agencies who try to skip the comms layer and just “move fast on the code” end up with internal stakeholders who feel surprised and who blame the new agency for the disruption. That is a politically expensive way to start a partnership.
What success looks like at day 60
A clean agency switch produces three observable outcomes by the 60-day mark. First, the new team has merged at least two non-trivial features that they wrote from scratch. Second, the deployment pipeline has run end-to-end at least 10 times without human intervention. Third, the production incident count in the first 60 days is no higher than the trailing 60-day average from before the switch.
If you cannot point to all three at day 60, the switch is not working and you should pull a senior engineering leader from your side in for a hard look at what is stuck. Either the new agency is still in onboarding theater, or the codebase you inherited was worse than disclosed, or the in-flight work continuity plan was unrealistic.
Most CTOs we work with go through one agency switch in their career on a Magento store. Some go through two. The pattern that distinguishes the smooth switches from the painful ones is preparation. The agencies that take it well treat the transition as a craft of its own. The ones who treat it as a side task lose the project. If you are about to start this conversation, the right move is to act like a project manager first and a CTO second for the next 60 days. The technical depth comes back online after the dust settles. The political and operational discipline cannot be delegated.
If you are also evaluating whether to keep a portion of work in-house, or consolidate work across Hyvä, Shopify Plus, or other platforms during the transition, run those decisions in parallel with the agency switch rather than after it. Founders who try to do them serially usually find that the platform decision blocks the agency decision blocks the staffing decision, and nothing moves for a quarter.
