Direct answer
Do not approve the first Magento rescue change until the buyer can prove ownership, issue named access, restore a verified backup, preserve logs, reconcile orders and payments, map integrations, and approve a written rollback plan. A new agency should begin read-only where possible. Production write access follows a named change, test, validation, and rollback gate.
This is a buyer-side control list, not a command to copy sensitive data or bypass an account owner. If ownership is disputed, or an active breach is suspected, stop and use appropriate legal, account-recovery, security, and incident-response support.
1. Confirm legal ownership and authority
- Record the legal entity that owns the storefront, domain, customer data, source code, design, extensions, licenses, and cloud accounts.
- Read the current and previous supplier contracts for IP assignment, data return, termination, transition help, confidentiality, retention, and deletion duties.
- List disputed assets and assign legal or procurement owners. Do not ask the rescue agency to take an asset the buyer cannot prove it controls.
- Confirm who can approve access, freeze a release, authorize a production change, accept a milestone, and order rollback.
- Capture registrar, DNS, CDN, WAF, hosting, Adobe, payment, tax, search, analytics, email, ERP, PIM, and marketplace account ownership.
- Keep a written handover request and response log with the previous provider. Preserve relevant contracts, tickets, release records, and open-defect lists.
2. Build a named access inventory
Start with the least privilege needed for inspection. Create named accounts rather than sharing a former supplier's login. Use the buyer's identity process, multi-factor authentication, expiry date, and approval record.
| System | First access | Evidence to record | Write gate |
|---|---|---|---|
| Source and CI/CD | Read repositories, branches, history, artifacts, pipeline, and deployment records. | Buyer owner, named account, MFA, latest production commit, failed runs. | Approved branch, review, test result, deploy owner, rollback commit. |
| Cloud and environments | Read topology, resources, configuration references, health, and audit history. | Environment map, account owner, region, access log, support contact. | Change ticket, impact window, backup state, validation, rollback. |
| Commerce administration | Read configuration, users, queues, indexers, cron, stores, and extensions. | Named role, scope, last login review, admin audit evidence. | Approved setting diff and post-change test. |
| Data and integrations | Read safe extracts, schemas, mappings, logs, dashboards, and interface status. | Data owner, permitted dataset, time range, masking, retention. | Approved migration or replay plan with reconciliation. |
| Edge and third parties | Read DNS, CDN, WAF, payment, tax, search, email, and monitoring settings. | Buyer-controlled account, support path, current configuration export. | Named approver, vendor dependency, test, and reversal steps. |
Do not place passwords, access tokens, private keys, customer data, or payment data in the takeover document. Record the approved vault location and access owner instead.
3. Verify backups before a write
- Inventory database, media, source, deployment artifacts, configuration, search configuration, integration mappings, and approved secret-storage coverage.
- Record backup owner, storage account, encryption, schedule, retention, last successful run, and the recovery point available for each system.
- Run a controlled restore test outside production. Record the date, restored scope, duration, checks performed, failures, and person who accepted the result.
- Take a fresh pre-change backup or snapshot under the approved runbook. Verify that it is readable and not stored only in the failing environment.
- Document data that cannot be rolled back safely, including new orders, payment events, refunds, shipments, stock movements, and third-party writes.
A “backup successful” status does not prove recovery. The gate is a usable restore plus a clear rule for data created after the recovery point.
4. Preserve logs and the current evidence state
- Capture application, web, PHP, database, queue, cron, deployment, cloud, CDN, WAF, payment, ERP, PIM, search, and monitoring evidence for the relevant period.
- Record timezone, clock source, retention window, rotation policy, sampling, redaction, and any missing interval. Normalize time only after preserving the original value.
- Export the current deployment, module, dependency, configuration, indexer, cron, queue, cache, and environment status before remediation changes it.
- Protect logs from routine rotation or deletion when they may be needed for a dispute, legal hold, financial investigation, or security incident.
- Use approved storage and restrict access to customer, payment, authentication, or security-sensitive evidence.
5. Establish the order and payment truth
Choose stable identifiers and a time window. Compare commerce orders, payment events, invoices, credit memos, shipments, queue messages, middleware records, ERP entries, tax documents, and stock updates.
- Record counts and totals by status before any replay, cancellation, refund, import, or repair.
- List missing, duplicate, partial, stuck, and out-of-order records with source and target identifiers.
- Define the system of record for order, payment, fulfillment, customer, price, stock, and refund states.
- Stop uncontrolled retries. Test idempotency and duplicate protection before replaying an event or order.
- Require finance and operations approval for affected financial records, then reconcile the result across every system.
- Preserve an audit trail that shows who approved the action, what moved, what failed, and what was verified.
6. Map integrations and asynchronous work
| Area | Required record | Failure control |
|---|---|---|
| Interface | Source, target, owner, purpose, direction, protocol, endpoint class, and environment. | Health check and safe stop procedure. |
| Data contract | Schema, mapping, stable IDs, required fields, currency, locale, and version. | Validation and rejected-record handling. |
| Timing | Trigger, schedule, expected delay, timeout, batch size, and dependency. | Alert threshold and backlog limit. |
| Queue and retry | Topic or queue owner, consumer, retry count, dead-letter path, and current depth. | Idempotency, pause, replay approval, and duplicate check. |
| Credentials | Buyer-controlled vault reference, credential owner, scope, expiry, and rotation contact. | Revocation and rotation runbook. |
7. Set the production-change gate
- Gate 01
Freeze or bound releases
Name which releases stop, which emergency work remains allowed, who can approve it, and when the freeze ends.
- Gate 02
Open one change record
State the defect, evidence, proposed diff, dependencies, affected systems, data risk, owner, window, and expected result.
- Gate 03
Test outside production
Reproduce the issue where possible. Record code review, automated and manual tests, representative data, performance impact, and unresolved risk.
- Gate 04
Approve deployment and observation
Name the deployer, buyer approver, communication channel, monitoring window, business validator, and stop condition.
- Gate 05
Validate the business result
Check checkout, payment, order creation, emails, tax, stock, queues, ERP or PIM flow, logs, performance, and the exact failed path.
8. Write rollback before deployment
- Name the rollback decision owner and the person who can execute it.
- Define measurable triggers, including errors, failed transactions, wrong totals, queue growth, latency, health checks, or integration loss.
- List the exact code, configuration, infrastructure, cache, index, extension, schema, and feature-flag reversal steps.
- State the recovery point, expected rollback time, dependencies, and validation steps.
- Separate code rollback from data correction. Do not blindly restore a database over orders, payments, refunds, or shipments created after deployment.
- Prepare forward-repair and reconciliation steps for data that cannot safely move backward.
- Record the final decision, execution time, outcome, and remaining customer or operational impact.
9. Hold the takeover go/no-go review
A rescue team is ready for controlled work only when the buyer can answer yes to the relevant gates:
- Ownership and production authority are documented, and material disputes have named owners.
- Named, least-privilege accounts work, and the buyer can revoke them.
- A backup has been restored and the post-backup data risk is understood.
- Logs and current-state evidence are preserved with timestamps and retention.
- Orders, payments, refunds, shipments, stock, and key integrations have a reconciliation baseline.
- The first production change has a ticket, diff, tests, approver, deployer, observation window, acceptance check, and rollback trigger.
- Security, privacy, legal, and financial risks have been escalated to the correct specialist where needed.
If a critical gate is not ready, keep investigation read-only, document the exception, and assign the person who can resolve it. Urgency does not create ownership or make an untested restore safe.
10. Define handover and rescue exit
Agree how the previous provider will transfer repositories, infrastructure records, configuration, licenses, open incidents, known defects, test assets, vendor contacts, and operational knowledge. Record missing items rather than assuming they do not exist.
Close the rescue phase only against written acceptance: stable checkout, reconciled transactions, controlled deployment, healthy priority integrations, usable monitoring, buyer-controlled access, restored documentation, known-risk register, and an accepted backlog. Ongoing support, modernization, rebuild, or replatforming is a separate decision.
Continue the controlled rescue
Compare eligible providers in the main agency ranking and read the RESTORE-100 method. Use the first 72 hours plan to sequence early work. Review rescue versus rebuild after the evidence baseline is preserved. Publication ownership and claim rules are on the about page and editorial policy.