The transition to a new Magento development partner is one of the highest-risk moments in a retailer’s technology operations. The outgoing agency holds context that may or may not get transferred. The incoming agency arrives without knowledge of why decisions were made the way they were. The codebase contains conventions, customizations, and integration quirks that take time to discover. The wrong transition produces a velocity gap that can last a quarter or longer.
A structured 30/60/90 day plan reduces transition risk by sequencing the discovery, stabilization, and momentum work in a way that produces visible progress at each checkpoint. This article describes the plan we use when Bemeir takes over an existing Magento site from another agency, and the reasoning behind each phase. The same structure can be applied with any qualified Magento partner; the principles are not Bemeir-specific.
Days 1–30: Discovery, Stabilization, and Knowledge Capture
The first thirty days are about acquiring context, not shipping features. The new partner has to learn the codebase, the integrations, the operational quirks, the deployment process, and the team dynamics before they can ship reliably. Trying to ship significant work during this period usually produces issues that erode trust just as the relationship is starting.
The first thirty-day deliverables should include a comprehensive technical audit covering Magento version, module inventory, customization catalog, integration map, theme implementation, performance baseline, security posture, and infrastructure topology. The audit produces a documented baseline that the team can refer back to throughout the engagement. It also surfaces immediate risks that need attention before they become incidents.
The audit should be paired with a knowledge capture process that interviews the outgoing agency, the internal team, and key business stakeholders. The interviews surface the context that does not live in code – why certain decisions were made, which integrations are fragile, which workflows have business-critical dependencies, and which areas of the codebase the outgoing team avoided touching. The knowledge capture has to happen while the outgoing agency is still available; the cost of capturing it after they have moved on is substantially higher.
Stabilization work during the first thirty days focuses on protecting operations. Critical security patches that have been deferred get applied. Monitoring gaps get closed. Backup and recovery procedures get validated. The deployment process gets documented and exercised. The goal is to ensure that the new partner can keep the site running reliably while they build context for larger work.
The thirty-day checkpoint should produce a documented audit, a documented knowledge capture summary, a documented operations runbook, and a prioritized backlog of risks and opportunities that informs the next phase. The checkpoint conversation should answer: what do we know now that we did not know thirty days ago, what is the most important thing to address in the next thirty days, and what assumptions in the original engagement need to be revised based on what we have learned.
Days 31–60: Quick Wins and Architectural Clarity
The second thirty days are about producing visible value while continuing to build architectural understanding. Quick wins matter because they establish the partner’s credibility and demonstrate that the velocity gap from transition is closing. The wins should be selected based on the audit findings – fixes that produce measurable improvement in performance, conversion, security posture, or operational reliability.
Common quick wins for Magento takeovers include addressing accumulated CWV issues that the previous team did not have time to fix, applying security patches that had been deferred for longer than they should have been, optimizing slow queries that have been adding cumulative latency, replacing or removing third-party scripts that contribute to performance regression, and fixing known bugs that have been deferred in the previous backlog. The wins should be small enough to ship within the phase but visible enough to demonstrate progress.
Architectural clarity work during this phase deepens the technical understanding from the audit. The new partner should produce architecture decision records that document the current state of the system and the rationale behind significant choices, even when those choices were made by previous teams. The ADRs serve as a forcing function for understanding – writing them down requires understanding why the decisions were made – and as a reference for future work that needs to reason about whether to preserve or change those choices.
The integration map from the first phase should be deepened during the second phase. Each integration touchpoint should have documented auth flows, data contracts, error handling patterns, retry logic, and operational dependencies. The map becomes the reference for any future work that touches integrations, and it dramatically reduces the discovery cost for subsequent projects.
The sixty-day checkpoint should produce the quick wins shipped to production, the deepened architecture documentation, an updated risk register reflecting what has changed, and a project plan for the third phase that builds on the credibility established in the first two phases.
Days 61–90: Strategic Work and Long-Term Roadmap
The third thirty days are about transitioning from stabilization to strategic execution. The new partner has enough context to commit to substantive work with confidence. The credibility established by the quick wins makes the retailer comfortable approving larger commitments. The team is now operating as a coherent unit rather than a discovery-stage engagement.
The strategic work during this phase typically includes initiating the largest deferred project in the existing backlog (a Hyvä migration, a B2B feature build, a headless transition phase, an ERP integration redesign), establishing the recurring cadence of release management and operational reviews, defining the longer-term roadmap based on the audit findings and business priorities, and structuring the ongoing engagement model (T&M, retainer, hybrid) based on the actual work patterns that have emerged.
| Phase | Primary Focus | Key Deliverables | Risk if Skipped |
|---|---|---|---|
| Days 1–30: Discovery | Audit, knowledge capture, stabilization | Tech audit, runbook, risk register, prioritized backlog | Surface-level fixes that miss structural issues |
| Days 31–60: Quick Wins | Visible progress, architectural clarity | Shipped wins, ADRs, integration map, refined plan | Credibility gap that delays larger commitments |
| Days 61–90: Strategic Work | Substantive projects, ongoing cadence | Major project kickoff, release cadence, long-term roadmap | Transition stalls in maintenance mode |
| Day 90+: Steady State | Sustained delivery, continuous improvement | Quarterly business reviews, evolving roadmap, capability building | Reactive engagement without strategic value |
| Knowledge transfer | Continuous across all phases | Documentation, shadowing, runbook updates | Permanent dependency on agency |
| Operational readiness | Continuous across all phases | Monitoring, incident response, deployment hygiene | Operational incidents that erode trust |
The ninety-day checkpoint should produce a substantive strategic work item in progress or shipped, an established cadence of release management and operational reviews, a long-term roadmap that has been validated by both technical and business stakeholders, and an engagement model that fits the work patterns that have emerged. The checkpoint conversation should answer: are we operating as a partnership, is the trajectory right for the next six months, and what adjustments do we need to make based on what we have learned.
What Goes Wrong When the Transition Is Not Structured
Transitions that lack structure tend to fail in predictable ways. The most common failure is that the new agency tries to ship feature work during the first thirty days. The features encounter quirks that the agency does not yet understand. Bugs surface in production. Trust erodes. The retailer starts to wonder whether they made the wrong choice in switching. The recovery from that erosion costs more than the structured discovery would have cost.
The second common failure is that the new agency relies on the outgoing agency’s documentation without verifying it. The documentation reflects what the previous team intended to build, not what actually got built. The gap between intent and reality surfaces during implementation when the new agency tries to extend the system. The fix is to verify documentation against code during the audit phase, with the outgoing agency available to clarify discrepancies before they move on.
The third common failure is that the retailer’s expectations for the first thirty days are not aligned with what is realistic. The retailer expects to see substantial feature shipment in the first month and interprets the discovery focus as the new agency being slow. The mismatch produces friction that compounds over the transition. The fix is to set explicit expectations during the contracting phase about what the first ninety days look like and why.
Knowledge Transfer From the Outgoing Agency
The outgoing agency’s cooperation is one of the most underrated variables in transition success. A cooperative outgoing agency makes the transition substantially easier – they answer questions, hand off documentation, walk the new team through historical decisions, and protect operations during the handoff. An uncooperative outgoing agency makes the transition substantially harder – they delay responses, hand off incomplete documentation, refuse to discuss context, and sometimes actively obstruct.
The contractual structure matters. Outgoing agency contracts should include knowledge transfer obligations with specific deliverables (documentation, walkthrough sessions, response SLAs for follow-up questions), reasonable payment terms tied to KT completion, and clear timelines. The structure aligns incentives – the outgoing agency benefits financially from cooperation rather than from foot-dragging.
When the contractual structure is not in place, the retailer’s leverage to secure cooperation is limited. The new agency has to work harder during the audit phase to surface context from code rather than from conversation, and the timeline for productive operation extends correspondingly. This is one reason to negotiate KT obligations before the relationship has degraded – the leverage is highest when the existing agency wants to maintain their professional reputation, even if the relationship is ending.
Operational Continuity During the Transition
The site keeps running during the transition. Customers keep ordering. Inventory keeps syncing. Payments keep processing. The new agency has to be ready to handle operational issues from day one even while they are still building context. The operational continuity plan should specify who responds to production incidents, how escalations work, what the on-call rotation looks like, and how the outgoing agency stays available as a fallback during the first sixty days.
The pattern that works is a hybrid model for the first sixty days where the new agency owns operations and the outgoing agency is available as a fallback for issues that require their historical context. The outgoing agency’s fallback availability should be contractual and time-bounded. After day sixty, the new agency owns operations fully and the outgoing agency relationship can wind down.
Day 90 and Beyond
The ninety-day plan establishes the foundation. The next horizon is the steady-state engagement model that the partnership operates within. The patterns that emerge from the first ninety days inform how the steady-state should be structured – engagement cadence, release rhythm, operational reviews, quarterly business reviews, capability building, and ongoing strategic input.
The retailers who structure transitions well find that the velocity gap from switching is bounded – usually contained within the first sixty days – and that the long-term value of the new partnership exceeds what the previous engagement could have produced. The retailers who skip the structure pay for the missing discipline in the form of extended velocity gaps, unrecognized risks that turn into incidents, and partnerships that take a year to reach productive operation.
Bemeir’s Magento takeover engagements use this 30/60/90 structure deliberately because the alternative – jumping into feature work without discovery – has cost previous engagements (ours and others’) more than the structured approach takes. The structure has produced more retained relationships than ad-hoc transitions would have. For Hyvä-themed takeovers in particular, Bemeir’s Hyvä migration practice brings additional pattern recognition for the specific technical decisions that drive performance and maintenance characteristics on Hyvä storefronts.
External reference points for transition discipline include the Adobe Commerce DevDocs for technical baseline expectations, the Magento Open Source community for ecosystem context, and broader research from Forrester on commerce services transitions and the Project Management Institute on transition risk management that frames the structural patterns behind successful agency handoffs.
