Most Magento agency rescues land on a new team’s plate the same way: a CTO calls, the relationship with the prior agency has just ended badly, the site has multiple known issues and an unknown number of latent ones, the patches are months overdue, and the new team has to take operational ownership in two weeks. The work that follows is some of the highest-leverage work an agency does, and the playbook for it is consistent enough to write down.
Bemeir’s Magento team has rescued enough broken Adobe Commerce codebases that the sequence has become a documented practice. The order matters. The temptation is to start fixing the most visible problems immediately. The discipline is to stabilize the foundations first so the visible fixes do not introduce new failures. Here is what the first 60 days look like when done right.
What a “broken” Magento codebase actually looks like
The word “broken” gets used loosely. The codebases we rescue typically share a specific set of characteristics:
Patches significantly behind. The store is running a Magento version that is three or more security patches behind. The composer.lock file shows dependencies pinned to versions with known CVEs. Adobe’s patch cadence has moved on without the store.
Custom modules of varying quality. Some modules were written by a competent developer years ago and are clean. Others were written under deadline pressure by a different developer and are not. Some are abandoned mid-implementation. Some have been edited directly in production. The quality varies wildly within the same codebase.
Extension stack with conflicts. Multiple commercial extensions installed, some overlapping in functionality. A few have been customized in vendor folder (an anti-pattern that breaks on update). Several are older than the current Magento version and have known compatibility issues.
Caching inconsistently configured. Full-page cache is enabled but with a hit ratio under 60%. Block cache exclusions are excessive. Redis is running but configured with default eviction policies. Varnish is either not present or misconfigured.
Database not maintained. No reindexing schedule. Indexes that should be on are off. Stuck cron jobs accumulated over months. URL rewrites table bloated to gigabytes. Customer log tables never cleaned up. Database size 3-5x what it should be for the catalog and traffic levels.
Deploy process broken or undocumented. Either the CI/CD pipeline does not work and deploys happen manually, or the pipeline works but no one outside the prior agency knows how to use it. Rollback procedure is not documented or has never been tested.
Documentation effectively nonexistent. Code comments are sparse. Architecture decisions are not recorded. Integration patterns have to be reverse-engineered from the code. Operational runbooks do not exist.
Not every rescue presents all of these. Most rescues present six or more.
The 60-day stabilization sequence
The right order matters because some fixes depend on others, and some fixes are impossible to do safely until the foundations are stable.
Week 1: Baseline and triage
Before changing anything, establish a clear picture of the current state. Run a full technical audit: Magento and patch level, extension inventory, custom module inventory, customization inventory, database health, deploy pipeline state, monitoring and logging state, integration architecture, and known production issues.
The audit deliverable should be a 30-to-40-page document that the new team uses to drive the rescue plan. Without it, the rescue becomes whack-a-mole.
Also in week one: take a full backup of the codebase and database. Set up monitoring if it doesn’t exist (uptime monitoring at minimum, application performance monitoring strongly recommended through tools like New Relic or Datadog). Validate that the new team has emergency access to everything that might break.
Weeks 2-3: Critical security patches and infrastructure stability
Apply the most recent Magento security patches. This is non-negotiable. The longer the rescue waits to do this, the more exposure the store carries. Patches need to be applied to a staging environment first, regression-tested, and then deployed to production with a rollback path ready.
In parallel: stabilize the infrastructure. Confirm Varnish is running and configured correctly. Confirm Redis is running with appropriate eviction policies. Confirm the database has automated backups and a tested restore procedure. Confirm the deploy pipeline works end-to-end with a small low-risk deploy.
The goal at the end of week 3: the store is no longer accumulating risk. Patches are current. Infrastructure is monitored. Backups work. Deploy pipeline is functional.
Weeks 4-5: Database cleanup and cache tuning
Database performance is the most common silent killer of inherited Magento stores. The cleanup work:
Reindex everything. Schedule reindexing on a regular cadence. Clean up the URL rewrites table (Magento accumulates these aggressively). Truncate customer log tables. Clean up cart_price_rule rules that have expired. Audit the database size and identify any tables that should not be as large as they are.
Cache tuning: set full-page cache lifetimes appropriately, audit block cache exclusions and remove unnecessary ones, configure Varnish ESI for blocks that genuinely need to be per-user, and validate that the cache hit ratio is above 80% in production.
The goal at the end of week 5: page load times are visibly improving, server load is dropping, and the database is no longer a bottleneck.
Weeks 6-7: Extension audit and consolidation
Walk through every installed extension. For each: is it actively used, does it have a current version available, does it have known security issues, are there better alternatives, and is it worth keeping at all.
Common findings: 30-40% of installed extensions are not actively used and can be uninstalled. Another 15-20% are redundant with other installed extensions or with Magento’s native functionality. Removing the bloat reduces attack surface, simplifies upgrade path, and often improves performance.
Customized vendor-folder extensions need to be handled carefully. Either the customizations need to be moved into proper Magento module overrides, or the extension needs to be forked into a maintainable in-house version, or the customizations need to be rebuilt as a separate module that does not modify vendor code.
The goal at the end of week 7: the extension stack is clean, documented, and upgrade-safe.
Weeks 8-9: Code quality and documentation
With the foundations stable, the team can now work on the codebase quality without risking new production issues. The work:
Code quality assessment of custom modules. Identify the highest-risk modules and prioritize them for refactor. Most rescues find two or three modules that are responsible for a disproportionate share of the production incidents; targeting these gives the largest stability lift.
Documentation: write the architecture overview, the integration map, the runbook for the most common operational issues, and the deploy and rollback procedure. This is the documentation the prior agency should have left and didn’t.
The goal at the end of week 9: the team can onboard a new developer to the codebase in days, not weeks. The runbook supports operational incidents without team lead intervention.
Weeks 10-12: Forward momentum begins
By week 10, the foundations are stable, the patches are current, the database is clean, the extension stack is consolidated, and the documentation exists. Forward work can begin without dragging the operational firefighting from the early weeks.
The first piece of forward work should be modest and visibly successful: a clean Magento minor version upgrade, a performance optimization that improves Lighthouse score by 15+ points, a small UX improvement that the customer service team has been requesting for months. The goal is establishing the pattern that the new team ships things that work.
The trade-off: cleanup vs forward progress
The pressure during a rescue is always to start delivering forward features quickly. The business has been waiting on the roadmap for months. The CTO wants to demonstrate that the agency change is producing results. The temptation is to compress the stabilization phase and start shipping features in week three.
The cost of doing this is consistent: the forward features get shipped on an unstable foundation, the unstable foundation continues to produce incidents, the incidents consume the team’s capacity, and the agency change starts looking like it produced no real improvement. We have seen this pattern multiple times in clients who pushed for fast forward delivery before the rescue was complete.
The better path is to manage expectations clearly: the first 60 days are stabilization, with limited forward delivery. After day 60, forward velocity is meaningfully higher than the prior agency could deliver, and the velocity is sustainable rather than rushed. The total quarterly throughput is higher with the stabilization phase than without it.
Comparison of rescue paths
The choice of how aggressively to handle the rescue affects timeline and risk.
| Rescue approach | Timeline to stability | Risk during rescue | Forward velocity at day 60 | Forward velocity at day 180 |
|---|---|---|---|---|
| Compressed (skip stabilization) | “Stable” at day 30 nominally | High – new issues weekly | Apparent fast | Slow, with regressions |
| Standard 60-day stabilization | Real stability at day 60 | Low to moderate | Modest | Sustained high |
| Slow methodical (90-120 days) | Excellent stability | Very low | Minimal early | Slightly higher than 60-day |
The 60-day standard is the sweet spot for most rescues. The 90-120 day approach is justified only for genuinely catastrophic codebases. The compressed approach is justified almost never.
What the client needs to do during the rescue
The rescue goes faster when the client side is set up to support it. The list:
A single technical point of contact on the client side who can answer questions about business rules, customer flows, and historical context. Access to the prior agency’s senior developer on a paid retainer for the first 30 days, for institutional knowledge that is not in the code. Patience on the forward roadmap during the first 60 days, with clear communication to business stakeholders about why. Budget approval for the stabilization work, which is not glamorous but is required.
Clients who provide these accelerate the rescue meaningfully. Clients who do not provide them often see the rescue stretch to 90 or 120 days.
The honest framing for clients in the middle of a rescue
The first 30 days feel like the new team is not delivering anything visible. The CTO starts wondering if the agency change was a mistake. The pressure to start shipping features intensifies.
This is normal and the worst time to give in. The work happening in the first 30 days is exactly the work that prevents the rescue from failing. Patches that are not visible, infrastructure stability that does not show on the roadmap, documentation that the prior agency should have left: all of this is the foundation that makes the next 18 months possible.
Bemeir’s team communicates this explicitly at the start of every rescue and produces weekly reports during the stabilization phase that show what is being done and why. The transparency manages the anxiety and builds the trust that lets the rescue complete cleanly. By day 60, the conversation has shifted from “is this working” to “what should we build next.”
The Magento rescue is one of the most rewarding kinds of work to do well. The store stabilizes. The patches catch up. The customer experience improves. The internal team morale recovers. The business gets back on track. The discipline to do the stabilization work in the right order is what makes that outcome reliable. The shortcuts that feel like efficiency are usually the path to a second rescue six months later. Done right, the work pays back for years.
