The decision to replace a Magento development partner usually arrives later than it should. By the time most retailers start the conversation, they have already absorbed months of slow tickets, missed release windows, surprise infrastructure invoices, and the quiet anxiety that comes from depending on a team that no longer feels engaged. The good news is that a partner change does not have to mean a production incident. The bad news is that almost every story about a partner change going badly traces back to the same handful of mistakes during the transition, not to the underlying decision.
The retailers who execute a clean handover tend to share three habits. They start the transition before they have publicly committed to the change, they treat the codebase and the documentation as separate handover artifacts, and they refuse to let any single human be the only person who understands a production system. Everything else follows from those three habits.
When the decision is real
Most teams know they need to make a change roughly six months before they take the step. The signals are familiar: tickets that used to take days now take weeks, the agency’s most senior person stops showing up to status calls, infrastructure recommendations start sounding suspiciously like upsells, and the roadmap conversation gets pushed to a future quarter that never seems to arrive. None of these on their own are decisive. Taken together, they describe a relationship that has shifted from partnership to transactional vendor work, and a transactional vendor is not what an Adobe Commerce platform needs.
The retailers we talk to at Bemeir’s Magento development team usually go through a “validation engagement” with a second agency before making a full switch. A two-week or four-week paid scope of work focused on a real, scoped deliverable produces more honest signal than any number of sales meetings. If the new partner can ship a meaningful improvement against a real production codebase inside that window, the comparison gets clear quickly.
The pre-announcement phase
The single most consequential phase of any partner change is the period before the outgoing partner is told. This is not about secrecy for its own sake. It is about giving yourself optionality. Once an agency knows it has been fired, the institutional knowledge transfer becomes a counterparty negotiation rather than a collaboration. We have seen agencies deprioritize transition work, refuse to grant production access, and even lock out access to private modules they had built specifically for the client.
| Action | Before announcement | After announcement |
|---|---|---|
| Access audit | You can audit calmly without raising alarms | The outgoing team controls the timeline |
| Documentation pull | Native tools (Confluence, Slack, JIRA) export cleanly | Access can be revoked or restricted |
| Vendor account ownership | You can transfer ownership of New Relic, Fastly, Algolia, etc. without friction | Renegotiated as part of exit |
| Production observability | New tools can be installed via your DevOps team | Adds change-control overhead and political theater |
| Repository forensics | git log analysis is straightforward | Repos may go read-only quickly |
The pre-announcement phase typically runs four to six weeks. The work is unglamorous: pulling down every repository the outgoing agency has touched, documenting which third-party services they have admin access to, and cataloging the custom modules whose source code lives somewhere other than your primary Git host. Bemeir’s onboarding engineers have seen Magento sites where the actual production module code lived in a private Bitbucket account belonging to the outgoing agency, with no copy in the merchant’s repositories. That situation is recoverable but only if it is discovered before the announcement.
The thirty-day overlap
Production stability during a partner change depends almost entirely on whether the incoming and outgoing teams have a real overlap period. The temptation, especially for cost-sensitive retailers, is to end the outgoing engagement as quickly as possible and have the new team “ramp up” afterwards. This is the most reliable way to break production.
A thirty-day overlap structured around incident-on-call handover, not just documentation, produces dramatically better outcomes. During the overlap, the new team is paid for shadow time on the existing team’s tickets, the outgoing team is paid through the period with a clear retention clause tied to handover completion, and on-call responsibility shifts gradually rather than overnight. The cost feels uncomfortable, but it is materially smaller than a single production outage in the first week post-transition.
Per the Adobe Commerce official documentation on system requirements and deployment, any non-trivial Adobe Commerce instance has at least a half-dozen integration surfaces that need to be understood: payment processors, tax engines, ERP middleware, search providers, CDN configurations, and warehouse management systems. Each of these has its own runbook risk and its own institutional knowledge concentration. The overlap period exists to spread that knowledge across the new team.
What gets transferred and what gets discarded
A partner change is also the right moment to make hard decisions about technical debt. The outgoing partner has been operating under accumulated constraints: workarounds for old extensions, patches layered on top of patches, integrations that “work” in the sense that they have not yet caught fire. The incoming team, working with Bemeir’s Hyvä migration and performance specialists or any reputable Adobe Commerce agency, has the opportunity to draw a line and decide which debts are worth carrying forward.
The framework we use looks at each piece of inherited code through three lenses: business criticality, modification frequency, and time-to-replace. Code that is business-critical but rarely modified can be left alone for the first quarter. Code that is modified frequently is the place to invest refactoring effort early, because the cost of working in bad code compounds. Code that is neither critical nor frequently modified is a candidate for retirement entirely.
Internal Adobe Commerce best-practice guides emphasize that custom modules should be self-contained, properly composer-required, and free of core overrides. In practice, this is the single most common source of upgrade pain. A partner change is the right time to identify which inherited modules violate these principles and to triage them.
The communication layer
The thirty days following the announcement matter as much as the technical handover. The internal merchandising team, marketing team, and customer service team have all developed relationships with the outgoing agency. They have backchannels for “can you push this banner change tonight” and “the search results look wrong on this category page.” Those backchannels need to be migrated cleanly to the new partner or they will atrophy into a productivity tax.
The retailers who do this well establish an internal communication protocol in the first week of the new engagement: who can ticket what, what the SLA is, who the new escalation contact is, and how out-of-band requests are handled. A reputable agency partner, whether Bemeir’s Adobe Commerce team or another Hyvä-certified shop, will help draft these protocols rather than waiting for the retailer to figure them out.
Production observability before, during, and after
The final discipline is observability. You cannot evaluate a partner change you cannot measure. Establish a performance and uptime baseline two weeks before the announcement using New Relic, Datadog, or whatever APM stack you already run. The baseline should include page load times for the critical user journeys (homepage, category, product, cart, checkout), backend application response times segmented by controller, and the error rate by integration. According to Akamai’s Core Web Vitals research, a 100ms improvement in LCP correlates with a measurable conversion lift in mid-market eCommerce, so the baseline is not just an operational metric but a commercial one.
After the transition completes, that baseline is what tells you whether the change worked. If the new partner is doing their job, you should see steady, incremental improvement in those metrics inside the first quarter. If you do not, the conversation is now grounded in data rather than vibes.
What good looks like
A clean partner transition has a recognizable shape. The pre-announcement audit takes four to six weeks. The overlap period is funded and real. Documentation flows from the outgoing team into a structured wiki, not a Slack channel. The new partner brings observability discipline from day one. And six months later, the merchandising team has stopped mentioning the outgoing agency by name, which is the truest signal of a transition that worked.
The retailers who get this right do not see a partner change as a one-time event. They see it as a forcing function for the platform discipline they should have had all along. The next change, if it ever happens, will be easier, because the documentation and access discipline established during this transition will carry forward. That is the real return on a well-executed Magento partner change: not the new agency, but the operational maturity the change forced into existence.
