The rescue project is a specific category of Magento engagement. The previous team – agency, in-house, or both – has left behind a codebase that does not work the way the business needs it to. The new partner is brought in with the expectation of stabilizing operations, surfacing the actual state of the system, and producing a path forward. The work is meaningfully different from greenfield Magento engagements, and it requires a different playbook.
This article describes the rescue project playbook we use at Bemeir when retailers come to us with inherited Magento codebases. The structure is drawn from rescue projects we have shipped across retail, B2B, and DTC contexts where the prior implementation had failed in identifiable ways. The patterns are not universal – every rescue is specific – but the overall structure tends to apply.
What a Broken Magento Codebase Actually Looks Like
The first reality check is what “broken” means in this context. The storefront usually still processes orders – broken codebases rarely produce complete operational failure. The brokenness shows up in patterns that erode business value over time: performance regressions that pull down conversion, intermittent integration failures that produce customer service load, security vulnerabilities that accumulate as compliance risk, technical debt that prevents new feature work, operational fragility that produces incidents the team cannot easily resolve, and documentation gaps that make any change risky.
The diagnostic picture typically emerges from a combination of code review and operational review. The code review surfaces architectural issues – modules that override core Magento in unsafe ways, customizations that have not been updated through platform upgrades, third-party extensions that have known issues, integration patterns that produce intermittent failures, and accumulated technical debt that compounds the cost of changes. The operational review surfaces process issues – deployment procedures that are fragile, monitoring gaps that miss issues until customers report them, incident response patterns that recover from issues without addressing root causes, and team capacity that has been consumed by operational firefighting rather than improvement work.
The combined picture is what guides the rescue plan. A codebase with architectural issues but disciplined operations needs different intervention than a codebase with clean architecture but operational chaos. The rescue plan should fit the actual situation rather than applying generic templates.
Phase 1: The Audit – Days 1 to 21
The first three weeks should be focused on understanding the actual state rather than on making changes. The audit produces six deliverables that inform the rest of the rescue.
The technical baseline audit documents the Magento version, the module inventory, the customization catalog, the theme implementation, the integration map, and the infrastructure topology. The audit goes beyond the composer.json to include runtime profiling – what actually loads on production pages, including modules that aren’t documented or that have been disabled in configuration but remain in the codebase.
The security posture audit documents the patch level relative to Adobe’s current release, the third-party module security status, the infrastructure security configuration, the authentication and authorization patterns, and the PCI compliance status if applicable. The audit identifies vulnerabilities that need urgent attention separate from the rest of the rescue plan.
The performance baseline audit documents CWV scores at the seventy-fifth percentile from real user data, server response times under typical and peak load, third-party script impact on page performance, and integration latency profiles. The baseline becomes the reference point for measuring improvement during the rescue.
The integration health audit documents each integration’s current state, recent failure patterns, latency characteristics, error rates, and data flow correctness. The audit surfaces which integrations need attention as part of the rescue versus which can be left alone.
The operational readiness audit documents deployment procedures, monitoring coverage, incident response patterns, on-call rotations, and documentation quality. The audit surfaces which operational gaps need closure as part of the rescue.
The team and stakeholder map documents who has knowledge about which parts of the system, who has decision authority for which categories of change, and who needs to be involved in which decisions. The map prevents the rescue from being blocked by stakeholder ambiguity during execution.
Phase 2: Stabilization – Days 22 to 60
The second phase addresses urgent issues surfaced by the audit. The pattern is to address things that are actively producing operational risk or business impact, while continuing to build context for the broader rescue work.
The security stabilization addresses critical and high-severity vulnerabilities that have known exploits or that would fail compliance assessments. The work typically includes applying overdue Adobe security patches, addressing third-party module vulnerabilities, closing infrastructure security gaps, and addressing customization patterns that introduce security risk.
The operational stabilization addresses incidents that are recurring without root-cause resolution. The work typically includes closing monitoring gaps that miss issues, addressing deployment fragility that produces release-time incidents, documenting operational runbooks for common scenarios, and establishing release discipline that prevents new issues from being introduced.
The performance stabilization addresses regressions that are pulling down business metrics. The work typically includes addressing CWV issues that have known fixes (LCP element optimization, third-party script audit, image format updates), closing TTFB issues that affect every page, and addressing specific performance issues that customer service or analytics have surfaced.
The integration stabilization addresses failure patterns that are producing customer service load. The work typically includes adding retry logic where appropriate, addressing data quality issues that produce integration failures, improving error visibility so failures are detected proactively rather than reactively, and addressing specific integration patterns that have been producing recurring issues.
Phase 3: The Forward Plan – Days 61 to 90
The third phase shifts from reactive stabilization to deliberate forward work. The retailer now has stable operations, a documented audit, and a track record of three months of work that the new partner has executed. The relationship has built credibility for larger commitments.
The forward plan typically covers three horizons. The first horizon is the technical debt reduction plan – which architectural issues from the audit need to be addressed, in what order, and with what budget. The plan should be prioritized by business risk and benefit rather than by technical interest.
The second horizon is the capability roadmap – what business capabilities the retailer needs that the current state cannot support. The roadmap should align with the broader business plan and should include explicit estimates and timelines for each capability.
The third horizon is the operational evolution – how the operational structure should evolve as the rescue completes. The structure typically includes the ongoing maintenance retainer arrangement, the release cadence, the monitoring discipline, and the quarterly business review cadence.
| Rescue Phase | Days | Focus | Key Output |
|---|---|---|---|
| Phase 1: Audit | 1–21 | Understand actual state | Six audit deliverables |
| Phase 2: Stabilization | 22–60 | Address urgent risks | Stable operations, closed urgent gaps |
| Phase 3: Forward Plan | 61–90 | Set deliberate trajectory | Roadmap, debt plan, operational structure |
| Phase 4: Execution | 90+ | Execute the plan | Ongoing forward work + steady state ops |
| Knowledge transfer | Continuous | Build internal capability | Documentation, ADRs, runbooks |
| Stakeholder management | Continuous | Maintain alignment | Regular reviews, escalation discipline |
What Goes Wrong in Rescue Projects
The most common failure pattern is the rescue project that tries to ship feature work during Phase 1. The new partner has not built enough context yet, the features encounter quirks that the partner does not understand, bugs surface in production, and trust erodes. The recovery from that erosion costs more than the structured discovery would have cost.
The second common failure is the rescue that addresses symptoms without addressing causes. The performance issue gets a tactical fix that improves the immediate metric without addressing the underlying architectural pattern that produced the issue. The integration failure gets a retry layer rather than addressing the underlying data quality problem. The pattern produces visible short-term improvement but the underlying issues continue to produce new symptoms.
The third common failure is the rescue that takes over too much too quickly. The new partner accepts ownership of every issue, every backlog item, and every operational responsibility within the first month. The capacity gets consumed by reactive work, the forward planning gets deferred, and the rescue becomes another sustained period of firefighting rather than a transition to stable operations.
The fix for these failures is the disciplined phase structure – Phase 1 for understanding, Phase 2 for stabilization of urgent issues, Phase 3 for deliberate forward planning, and explicit Phase 4 execution. The discipline produces better outcomes than the alternative of treating the rescue as an open-ended firefighting engagement.
The Outgoing Team Relationship
Many rescue projects involve a relationship with an outgoing agency or in-house team. The relationship affects rescue execution substantially, and the patterns vary widely.
The cooperative outgoing team makes the rescue substantially easier – they hand off documentation, walk the new team through historical decisions, protect operations during the handoff, and answer questions during the audit phase. The cooperative outgoing relationship usually requires contractual structure that incentivizes cooperation (typically payment tied to KT deliverables and reasonable timeline commitments).
The uncooperative outgoing team makes the rescue substantially harder – they delay responses, hand off incomplete documentation, refuse to discuss context, and sometimes actively obstruct. The rescue plan has to work around the uncooperative relationship by surfacing context from code rather than from conversation, by accepting longer audit timelines, and by managing operational continuity without the outgoing team’s cooperation.
The mixed outgoing relationship – some cooperation, some obstruction – is the most common pattern. The rescue plan should anticipate which areas will have cooperation and which will require workarounds, with explicit communication about the situation to the retailer’s stakeholders.
The Operational Continuity Discipline
The storefront keeps running during the rescue. Customers keep ordering. Inventory keeps syncing. Payments keep processing. The new partner has to be ready to handle operational issues from day one even while building context.
The operational continuity plan should specify who responds to production incidents during each phase, how escalations work, what the on-call rotation looks like, and how the outgoing team stays available as a fallback. The pattern that works is for the new partner to assume operational responsibility from day one for low-severity issues while keeping the outgoing team as fallback for high-severity issues during the first thirty to sixty days. After day sixty, the new partner typically owns operations fully.
The communication plan with internal stakeholders during the rescue also matters. The retailer’s internal team needs visibility into what is happening, what is being addressed, and what is being deferred. The communication should be structured – weekly status with what was accomplished, what is in progress, and what is blocked – rather than ad-hoc.
When the Rescue Succeeds
The successful rescue produces a transition from a fragile, accumulating-debt operation to a stable, deliberate-trajectory operation. The success indicators include stable production with declining incident rate, improved CWV scores measured by real-user data, documented operational procedures that the team can execute reliably, technical debt addressed in order of business risk, and capability roadmap that the retailer can defend internally.
The successful rescue takes six to nine months end-to-end from the initial audit through the establishment of stable forward operation. The investment is meaningful but typically pays back within twelve to eighteen months through reduced incident cost, improved business metrics, and faster delivery of new capability.
Bemeir’s rescue project practice handles the inherited-codebase scenario specifically because the alternative – generic Magento engagement structure – does not fit the rescue context well. The structure has produced sustained recoveries across retailers who came to us after difficult transitions from other agencies. For Hyvä-themed storefronts in particular, the rescue often includes Hyvä-specific stabilization work that requires the additional theme expertise.
For deeper reference on rescue project discipline, the Adobe Commerce DevDocs provide platform reference, the Magento Open Source community resources provide ecosystem context, and broader research from Forrester on commerce services transitions and the Project Management Institute on technical recovery projects provides additional structured frameworks. The OWASP application security resources provide the security baseline that rescue audits should validate against.
