Most enterprise eCommerce rescue stories follow a similar arc. The original team gets the contract, builds for nine months, and quietly delivers an architecture that looks fine in a demo and falls apart under audit, load, or both. The client discovers the problem either during a PCI assessment or during their first peak-traffic weekend. By the time a rescue partner is engaged, the launch deadline is non-negotiable, the team is exhausted, and the budget for redo work is already spent.
This case study covers a composite, anonymized rescue engagement on Adobe Commerce that Bemeir took over from a previous agency. The client is a regulated mid-enterprise retailer (SKU count in the low hundreds of thousands, multi-store, North American and EU storefronts) operating under PCI DSS and a SOX-adjacent internal audit regime. The names and exact figures are altered, but the architectural patterns and decisions are drawn from real Bemeir engagements.
The State of the Project at Handoff
The previous agency had been on the project for thirteen months. The launch date was four months out and effectively immovable because it tied to a contractual deprecation of the legacy platform. A PCI pre-assessment had flagged six critical findings, three of which were architectural rather than configurational. Performance testing on the staging environment was failing at thirty percent of projected peak load. The internal audit team had asked for an evidence package on user access, payment data flow, and change management, and the previous team had been unable to produce it within the requested window.
The rescue scope was direct: complete the platform, pass the PCI re-assessment, hit the launch date, and deliver the audit evidence package. Bemeir was given six weeks of discovery and ten weeks of build before launch.
What the Original Team Missed
The first week of the rescue was an architectural audit, not a status review. The findings clustered into three categories.
Custom payment integration that broke PCI scope. The previous team had built a custom checkout module that captured card data on-page before tokenizing it through the payment gateway. The pattern was technically functional but it pulled the entire checkout server, the underlying database, and the load balancer into PCI cardholder data environment scope. The remediation effort to maintain that scope going forward would have added six figures of annual compliance cost on top of the build.
Audit log gaps in admin and customer activity. The Adobe Commerce admin login, role changes, customer impersonation events, and order modifications were not being captured to a tamper-resistant log store. The platform’s built-in admin actions log was enabled but logs were never shipped off-platform, meaning a malicious admin could delete their own evidence trail. This is a documented anti-pattern in the Adobe Commerce security documentation and one of the items the PCI Security Standards Council treats as a critical control.
Performance failing under enterprise load. The previous team had layered custom modules onto the catalog rendering and checkout paths without proper indexing, full-page-cache compatibility, or product flat-table strategy. Page generation times under load were two to three times what they should have been on the provisioned infrastructure. The instinct from the previous team had been to ask for more servers; the reality was that the application was generating uncacheable HTML.
There were smaller findings too: secrets stored in environment files committed to the repository, an outdated patch baseline, and a CI/CD pipeline that allowed deploys without code review. None of those were architectural in the same sense, but they fed the audit findings.
Rescue Audit – What Was Salvaged Versus Rebuilt
Not everything was wrong. The product catalog modeling was sound, the multi-store configuration was correct, and the integration with the ERP for inventory and pricing was working. Roughly sixty percent of the codebase was salvaged. The other forty percent was rebuilt or replaced.
| Component | Original State | Rescue Action | Rationale |
|---|---|---|---|
| Custom on-page checkout | Captured PAN data, expanded PCI scope | Replaced with hosted-fields integration | Removed CDE scope from web tier |
| Admin audit logging | Local-only, no off-platform shipping | Streamed to immutable log store | Required for PCI Req 10 evidence |
| Catalog rendering performance | Uncacheable custom blocks | Refactored with proper FPC blocks | Restored full-page cache effectiveness |
| Product import pipeline | Worked but slow | Kept, added monitoring | Functioning, no rebuild needed |
| ERP inventory sync | Working | Kept, hardened error handling | Functioning, hardened only |
| Secrets in env files | In repo | Migrated to secrets manager | Required for audit evidence |
| CI/CD deploy gates | No review enforcement | Added required-review and SAST | Required for SOX-adjacent control |
| Multi-store configuration | Correct | Kept | Working |
| Custom promotion rules | Broken under edge cases | Rebuilt with proper rule precedence | Functional gaps |
The decision matrix for salvage versus rebuild was driven by three questions: does it pass PCI re-assessment as-is, does it hold up under projected peak load, and does it produce the audit evidence the internal team needs. If all three answers were yes, the component stayed. If any answer was no, it went into rebuild scope.
The Compressed Timeline to Launch
Ten weeks of build after a six-week discovery is not a normal Adobe Commerce delivery cadence. The work was possible because the discovery had already produced a clean architectural plan, a prioritized backlog, and a hardened test suite the engineering team could trust.
The rebuild of the checkout to use hosted fields took three weeks of focused work, including the integration tests against the payment gateway. The audit logging refactor took two weeks because the application code already emitted most of the events; the work was largely about routing them to a tamper-resistant log store with the correct retention. The performance work ran in parallel and took the full ten weeks because it touched many surfaces: catalog blocks, full-page-cache rules, Varnish configuration, and the Hyva theme frontend that had been added late by the previous team and was contributing to render times.
Bemeir’s enterprise Magento bench was the difference between this being a heroic ten-week sprint and an impossible one. Engineers who had shipped Adobe Commerce performance work for clients like K&N Engineering knew where the catalog rendering bottlenecks live without spending two weeks profiling them.
Evidence Package for the Audit
The internal audit team had asked for evidence covering user access, payment data flow, and change management. The previous agency had never produced this package; the rescue treated it as a launch-gating deliverable.
The user-access evidence was generated from the new admin audit log stream, exported as a versioned report covering every admin login, role change, and impersonation event for the ninety days before launch. The payment-data-flow evidence was a network and application-level diagram showing that no PAN data ever touched the web tier or the application database, supported by the OWASP secure-coding references and the merchant’s payment gateway attestation. The change-management evidence was a CI/CD log export showing that every production deploy in the rescue period had been reviewed, scanned, and tested.
The PCI re-assessment passed with no critical findings. The internal audit team accepted the evidence package without follow-up requests. The platform launched on the original date and held through the first peak-traffic weekend at two hundred percent of projected load.
What This Engagement Illustrates About Platform Expertise Depth
The rescue worked because the team that took over had shipped enough Adobe Commerce projects in compliance-heavy contexts to recognize the anti-patterns immediately. A generalist agency, even a competent one, would have spent the first six weeks discovering what an experienced Magento team recognized in five days.
Platform expertise depth shows up in three places: the speed of the architectural audit at handoff, the accuracy of the salvage-versus-rebuild call, and the quality of the evidence package the team can produce on demand. Each one of those is a function of pattern recognition built across many projects, not a function of certifications or partnership tier badges.
For compliance-focused enterprise decision makers, the lesson is that platform selection and partner selection are the same decision. A great platform implemented by a team that does not know its compliance edges produces the same outcome as a poor platform: a project that works in demo, fails in audit, and forces a rescue. The teams who can carry an Adobe Commerce project through a compliance-heavy launch are not generalists who happen to know Magento; they are practitioners who have lived in the platform’s edges, including the ones documented at Forrester’s commerce research, long enough to know which patterns hold up and which ones quietly break.
