Replacing an under-performing Magento agency is one of the highest-leverage moves a CTO can make. It is also one of the highest-risk, because the transition itself is where most stores break. The handoff fails, the new team takes weeks to find its footing, a security patch gets missed, the checkout breaks on a Saturday, and the move that was supposed to fix things ends up making things worse for a quarter.
The good news: the failure modes are predictable, the playbook is well-understood, and a careful 60-to-90-day transition almost always lands cleanly. The bad news: most replatforms happen under stress, with a relationship breakdown in the background, and the playbook gets compressed in ways that create the very risks the transition was supposed to avoid.
Bemeir’s Magento team has inherited Adobe Commerce sites from prior agencies more than 40 times in the last three years. The transition pattern that works is consistent. Here is what we have learned about how to do it without breaking the store.
When replacing makes sense and when it does not
Before scoping a transition, worth being honest about whether replacing is the right move at all. Three signals that genuinely justify it:
Persistent quality problems. Patches that are months overdue. Routine bugs that take weeks to fix. Production incidents the agency cannot diagnose. New work that breaks old work. If the technical quality is degrading rather than improving, the relationship is not recoverable through better account management.
Strategic misalignment. The agency was the right choice three years ago when you were a $5M store; today you are a $40M store and they have not grown into your complexity. Or you need Hyvä migration capability and they do not have it. Or you are adding B2B and they have only done B2C.
Communication breakdown. You have tried to escalate, raised concerns, asked for changes in account team or process, and the agency cannot or will not adjust. The relationship has reached a point where neither side is investing in making it work.
Reasons that look like justification but usually are not: a single bad release (often a process issue, not an agency issue), a billing dispute (usually negotiable), or a personality conflict with one account manager (usually fixable with a team change). If the issue is fixable inside the existing relationship, fixing it is cheaper than replacing.
The transition risk profile
A Magento agency transition has six risk categories. Each one needs explicit handling in the playbook.
Knowledge loss. The outgoing agency knows things about your codebase, your business rules, your customizations, and your operational history that are not written down anywhere. The transition needs to extract as much of this as possible before the relationship ends.
Code repository ownership. The Git repository, the CI/CD pipeline, the deploy infrastructure, the database backups, the staging environments, and the production server access all need to transition cleanly. Many smaller agencies host all of this on their own infrastructure and the transition requires migration.
Active in-flight work. Whatever the outgoing agency is currently building or fixing needs to either finish before transition or transition cleanly to the new team mid-flight. Incomplete work that gets dropped is a common source of regressions.
Ongoing maintenance gaps. Security patches, dependency updates, and routine maintenance cannot pause during the transition. A gap of 30 to 60 days here is enough to cause real security exposure.
Vendor relationships. The outgoing agency may own relationships with extension vendors, payment processors, hosting providers, or third-party integrations. Transitioning these contacts is often forgotten and matters when something breaks.
Operational rhythms. Standup cadences, release schedules, on-call rotations, escalation paths, runbook procedures: the outgoing agency’s operational rhythms need to be either adopted by the new team or replaced cleanly.
Of these, knowledge loss is the most expensive failure and the hardest to recover from. Most other failures can be fixed with money or time; knowledge loss cannot be reversed once the people who had the knowledge have moved on.
The 90-day transition playbook
The playbook that consistently works for our team and the clients we transition is structured in four phases. The total clock is 90 days from notice to the outgoing agency through full operational ownership by the new team.
Phase 1: Discovery and audit (weeks 1-3)
Before the outgoing agency knows they are being replaced, run a quiet technical audit with the new agency. The audit covers the current codebase state, the active extension stack, the customization inventory, the patch level, the integration architecture, the deployment pipeline, and the documentation completeness. The deliverable is a 30-to-40-page document that the new agency can use to scope the transition and to identify the highest-risk areas to handle first.
During this phase, formally negotiate the new agency contract. Lock in the start date, the team composition, the SLA, and the transition support scope. The new agency is on contract before notice is given to the outgoing agency, but their work is limited to the audit and transition planning.
Phase 2: Notice and parallel operation (weeks 4-8)
Give formal notice to the outgoing agency, typically 30 to 60 days based on contract terms. Be professional, be specific about end date, and avoid the temptation to soften the message in ways that create ambiguity.
During the notice period, run both agencies in parallel. The outgoing agency continues operational work and handles the formal knowledge transfer. The new agency observes, asks questions, and starts shadowing on real work. The new agency is reading code, reviewing tickets, understanding the integration architecture, and building the relationship with your internal team.
Specific knowledge transfer activities that need to happen in this phase:
A code walkthrough of all custom modules with the outgoing agency’s lead developer. This should be recorded and the recording archived.
A full inventory of every extension installed, every customization made, and every integration in place, with the rationale for each documented. Most outgoing agencies will resist this documentation work; insist on it as part of the transition agreement.
A runbook handoff: how to deploy, how to roll back, how to access logs, how to escalate to hosting, how to handle the most common operational incidents.
A vendor contact list: payment processor account managers, hosting provider escalation paths, extension vendor support contacts, third-party integration vendor contacts. With permission to introduce the new agency to each.
A passwords and access transition: every credential the outgoing agency holds, audited, rotated, and reissued to the new agency. Do this through your password manager and your IT team, not through email.
Phase 3: Operational handover (weeks 9-11)
The new agency takes operational ownership of routine maintenance, patches, bug fixes, and incident response. The outgoing agency stays on as a paid escalation resource for specific questions that come up. Active in-flight work either completes or transitions to the new agency.
This is the phase where the new agency earns its keep. The first few patches, the first few incidents, and the first few customer-facing changes need to demonstrate the new team’s competence. If the new agency cannot handle the operational load in this phase, the transition is in trouble.
Bemeir’s transition team treats the first 30 days of operational ownership as a deliberate proving phase, with explicit success metrics: patch SLAs met, no production incidents from new-team error, customer service queue stable, and at least one production deploy completed cleanly by the new team.
Phase 4: Full ownership and forward momentum (week 12+)
The outgoing agency is off the contract. The new agency owns the store completely. Forward roadmap work begins: the Hyvä migration, the new B2B feature, the ERP integration, or whatever the strategic reason for the agency change was in the first place.
The transition is judged successful at day 90 if: no security patches are overdue, no in-flight work has been dropped, the customer service queue is stable, the deploy pipeline is operated entirely by the new team, and the new team has shipped at least one piece of meaningful forward work. If any of those fail, the root cause needs immediate attention.
Comparison: clean vs messy transitions
The pattern from our experience across more than 40 inherited Magento sites:
| Transition characteristic | Clean transition | Messy transition |
|---|---|---|
| Notice period | 60-90 days | <30 days or none |
| Outgoing agency paid for transition support | Yes | No (acrimonious) |
| Code repository handoff documented | Yes | Partial or missing |
| Knowledge transfer sessions recorded | Yes | No |
| Vendor relationships introduced to new agency | Yes | No |
| In-flight work completed or formally transitioned | Yes | Dropped |
| First 30 days post-transition production incidents | 0-1 | 3-7 |
| New agency time to full operational ownership | 60-90 days | 4-6 months |
| Hidden landmines discovered in first 6 months | 2-5 | 10-20 |
The messy transitions are almost always driven by an acrimonious end to the prior relationship. The clean transitions involve a paid transition period for the outgoing agency, which feels expensive but is dramatically cheaper than the cost of dropping in-flight work or losing institutional knowledge.
The non-obvious things that matter most
After dozens of agency transitions, two things have surprised us with how much they matter and how often they get missed.
The outgoing agency’s senior developer should be on a paid retainer for 30 days after transition. Not for ongoing work, but specifically to answer questions. The new agency will hit things they cannot figure out from the code or the documentation, and being able to call the prior senior developer for context is worth far more than the retainer cost. Most outgoing agencies will agree to this if asked professionally.
The first major release after transition should be small and easy. Resist the urge to immediately ship the big feature the new agency was hired to build. Do something small and visible first: a clean Magento version upgrade, a stability fix, a small UX improvement. This builds trust in the new team and creates a pattern of clean deploys before the bigger work starts.
How to set the new agency up to succeed
The agency you are transitioning to has a much better chance of succeeding if you give them what they actually need to onboard. A working list:
A complete repository handoff with full Git history, branch state, and CI/CD configuration. Documentation of the deployment process and infrastructure access. A code walkthrough with the outgoing lead developer, recorded and archived. The active extension list with installation rationale and any customizations made to vendor extensions. A list of active integrations with vendor contacts and credentials. The runbook for the five most common production issues. The customer service team’s list of recurring issues that need engineering attention. The current sprint backlog and the backlog of deferred work.
The new agency cannot ask for all of this without seeming demanding, but they need all of it. Pre-emptively providing it shortens onboarding by weeks and reduces the chance that the new agency hits a knowledge gap that causes a production issue.
When to bring in a third party to manage the transition
For larger or more complex transitions (multi-million-dollar contracts, multiple integrations, B2B implementations), it can be worth bringing in a third-party advisor to manage the transition independently of either agency. The advisor’s job is to keep both sides accountable to the transition plan, to mediate disputes during knowledge transfer, and to validate that the new agency is genuinely capable of operational ownership before the outgoing agency is fully released.
Bemeir’s team has played both sides of this dynamic, and the third-party advisor approach can work well when the budget supports it. For smaller transitions, a disciplined internal CTO or VP of Engineering managing the playbook directly is usually enough.
The agency change is one of the most consequential decisions a Magento CTO makes. Done well, it sets the next several years of the store’s trajectory. Done badly, it consumes the next 12 months recovering from the transition itself. The difference is almost entirely in the planning and the playbook, not in the agency choice. Pick a good agency, run a clean transition, and the move pays off. Pick a good agency and rush the transition, and the move costs you. The 90-day investment in doing it right is the cheapest insurance you can buy.
