Hiring a Magento Agency for a Rescue Project: The First 72 Hours After Handoff

A Magento rescue project lives or dies in the first three days. The previous agency has been removed, the codebase has just become someone else’s problem, and the production store still has to take orders tomorrow morning. The new agency arrives with fragmentary documentation, partial credential access, and a backlog of issues that the outgoing team did not finish or did not disclose. What happens between Monday morning and Wednesday evening sets the tone for the next year of the engagement, and the work has very little to do with feature delivery and almost everything to do with triage, transparency, and getting the store on solid ground.

This guide is written for engineering leaders, private equity portfolio operators, and in-house teams who are about to hand a stalled or troubled Magento codebase to a new partner. It is also useful for the incoming agency itself as a reference for what the early hours should look like. The patterns below come from Bemeir’s rescue practice, where we have onboarded dozens of inherited codebases from previous partners.

Hour Zero: Establish Production Stability First

Before anyone reads any code, the new team needs to confirm the store is currently functioning and that you have credentialed access to monitor it. The very first action is to verify production health: check the storefront loads, check checkout completes a test order, check the admin is accessible, check that the order queue is being processed, and check that emails are being delivered.

If any of those are broken on day one, that becomes the first work item. Code reviews wait. Migration planning waits. The store has to be capable of taking orders before any other work is meaningful.

Set up read-only access to the production database for the incoming team’s lead engineer. Establish a production deployment freeze for the first 72 hours, no code changes ship until the team has a clear understanding of what is in production. This is the single most common mistake in poorly run rescues: the incoming agency starts changing things before they understand what was already there, and the resulting incidents compound the problem.

Hour Six: Credential Inventory

The second early action is a written credential inventory. Most rescue projects arrive with a partial set of access handed over by the outgoing agency, plus a longer list of accounts that exist somewhere and need to be tracked down. The incoming team should produce, within six hours, a written inventory of:

• Adobe Commerce admin accounts and their roles
• Server access (SSH keys, bastion configurations, cloud platform IAM)
• Database access (production, staging, development credentials)
• Git repository access (and history of who has access)
• Third-party SaaS credentials (payment, shipping, CMS, search, analytics, email)
• DNS and domain registration access
• SSL certificate ownership
• CDN and image optimization service access
• Monitoring and alerting access (New Relic, Datadog, Sentry, etc.)

For each row, the inventory records who currently has access, who should have access, and what is missing. Anything missing becomes a tracked recovery task. Bemeir’s rescue engagements treat this inventory as a contractual deliverable in the first 48 hours, because credential gaps are the most common source of late-stage rescue failures.

Hour Twelve: The Code Audit Pass

With production confirmed stable and credentials inventoried, the technical lead runs a first-pass code audit. This is not a deep architectural review, that comes later. The first pass is looking for:

• Modules that have been customized in ways that block Adobe Commerce patches
• Database schema deviations from declarative schema
• Indexer configurations that have been changed and may have caused current performance issues
• Cron jobs that are running, failing silently, or have been disabled
• Cache configurations and current invalidation patterns
• Any disabled-but-not-removed modules that may be causing dependency conflicts

The output of the first-pass audit is a written triage document with categories: known-good, known-broken, unknown-status. The known-broken items become the immediate fix queue. The unknown-status items become the investigation queue.

Hour Eighteen: The Production Issue Backlog

Every rescue project arrives with a backlog of production issues the outgoing team did not finish. The incoming team has to capture this backlog explicitly, because the items will not stay in the previous agency’s ticketing system after handoff. Schedule a backlog transcription session within the first day: walk through every open ticket, every known issue, every “we’ll get to that next sprint” item, and capture each in the new ticketing system with the original context preserved.

The eighteen-hour mark is also when the incoming team should be able to identify the issues that, left unaddressed, will cause an incident within the next two weeks. These become the urgent fix queue, and they take priority over the next sprint’s planned work.

Hour Twenty-Four: The Infrastructure Map

By the end of the first day, the incoming team needs a written infrastructure map. For most Magento stores in 2026 this means an Adobe Commerce Cloud or AWS architecture diagram showing the application servers, the databases, the Redis or Varnish layer, the search engine (OpenSearch or Elasticsearch), the CDN, and any other moving parts. The map needs to include versions, instance sizes, and current configuration. Adobe’s infrastructure documentation is a useful reference for what the standard architecture should look like.

The infrastructure map is the foundation of everything else. Performance work, integration work, and security work all require accurate infrastructure context, and the map produced in the first 24 hours becomes the reference document for the rest of the engagement.

Hour Thirty-Six: Integration Inventory

Most rescue projects arrive with a tangle of integrations whose current status is uncertain. By hour 36, the incoming team should produce an integration inventory: every external system the Magento store talks to, the direction of data flow, the authentication mechanism, the failure mode, and the current health.

Common integrations to inventory include ERP (NetSuite, SAP, Dynamics), CRM, PIM, payment gateways, shipping carriers, tax engines, marketing automation, customer data platforms, A/B testing tools, and any custom internal systems. For each, the inventory records the last known successful sync, the current error rate, and the credentials in use.

Bemeir’s integration practice has documented patterns for Adobe Commerce + ERP integrations and headless storefront APIs that map onto this kind of inventory. The integration map produced in the first 36 hours is what allows the team to triage which integration issues are urgent and which can wait.

Hour Forty-Eight: Documentation Gap Analysis

By the end of day two, the incoming team has built enough context to identify the most important documentation gaps. The output is a ranked list of missing documentation, where each item is scored by the risk of being missing. Architecture decisions, deployment runbooks, and incident response procedures usually top the list. Onboarding documentation for new team members is also high-priority for any retainer engagement.

The documentation gap list becomes a parallel work stream that runs through the first quarter of the engagement, separate from feature work. The team that does not invest in documentation early ends up rebuilding the same context every time someone rotates onto the project.

Hour Seventy-Two: The State-of-the-Store Report

The 72-hour deliverable is a single written document, delivered to the client, summarizing what the new team has found and what it intends to do about it. This is not a marketing document. It is an honest, specific, technical report covering:

• Production health: what is stable, what is at risk, what is broken
• Codebase health: what is well-architected, what needs refactoring, what is acceptable as-is
• Infrastructure health: what is sized correctly, what is misconfigured, what is at end-of-life
• Integration health: what is reliable, what is fragile, what is broken
• Documentation health: what exists, what is missing, what is wrong
• The top ten action items, ranked by risk and effort
• A proposed sprint plan for the next two weeks

The honesty of this report is the contract-level test of whether the new agency is going to be a good partner. An agency that delivers a glossy “everything is going great” report at 72 hours is not paying attention. A serious partner delivers an uncomfortable, specific, useful document that the client may not want to read but cannot afford not to. For a sense of how this works in practice, see Bemeir’s Magento rescue and audit work. The same first-72-hours discipline applies to Hyvä rescue engagements where the Hyvä practice inherits a partial or stalled migration, and to platform-transition rescues that touch the Shopify Plus practice or the Shopware team.

For independent benchmarks on the kinds of issues that surface in eCommerce rescue work, Adobe’s commerce operations documentation and OWASP’s eCommerce security guidance are useful third-party references.

What Comes After 72 Hours

The first three days are about triage and transparency. The next two weeks are about stabilization, fixing the urgent items from the audit, closing the credential gaps, and establishing the cadence that will run the rest of the engagement. Then the team can start delivering features again. But the foundation laid in those first 72 hours is what makes everything that follows possible. Skip the foundation and the rescue project becomes a slow-motion second failure.