Some of the hardest Magento work does not start from a blank slate. It starts from a half-finished build that a previous team left behind, a project that ran out of budget, lost its lead developer, or simply stalled when the original agency stopped delivering. You inherit a codebase nobody fully understands, a launch date that already slipped, and a stakeholder who wants to know whether any of the existing work is salvageable. Panic-deleting it and starting over is rarely the right answer, and neither is blindly finishing what someone else began.
A rescue is a diagnosis before it is a build. Adobe Commerce powers about 20 percent of the top 1,000 US retailers, according to Magento market data from MGT Commerce, which means there is a large pool of complex, high-stakes builds, and a steady supply of them that stall partway. The teams that rescue these well follow the same discipline every time: audit first, decide what survives, then sequence the work so the store reaches a shippable state without inheriting all the old debt.
How do you audit a stalled Magento build?
You audit it across four dimensions, code, data, infrastructure, and integrations, before writing a line of new code, so you know what you are actually inheriting. Start with a code audit: inventory every custom module, third-party extension, and theme change, and flag which are load-bearing, which are abandoned, and which can be replaced with native Adobe Commerce features. On a typical inherited build, a meaningful share of customizations turn out to be unnecessary once you map them against what the platform already does.
Then map the rest. A data audit confirms catalog, customer, and order integrity, because a half-migrated store often has silent gaps. An infrastructure review checks hosting, caching, and current Core Web Vitals so you have a real performance baseline. An integration map names every external system, ERP, PIM, payment, analytics, and whether each is connected, half-connected, or broken. The deliverable is a single honest document: what exists, what works, what is missing, and where the landmines are. Without it, you are finishing someone else’s guess.
What should you keep, rebuild, or throw away?
Keep what is sound and documented, rebuild what is load-bearing but fragile, and discard what is abandoned or replaceable with native features. The temptation in a rescue is to preserve everything to avoid “wasted” prior work, but carrying forward bad architecture is how you inherit the exact problems that stalled the project. The previous spend is sunk. The only question that matters is what gets you to a stable, maintainable store fastest.
Apply a simple test to every custom piece: does it still serve a real business need, is it built in a way the team can maintain, and does Adobe Commerce now do this natively. Anything that fails the first question goes. Anything that passes the first but fails the second gets rebuilt cleanly. Anything the platform handles natively, B2B workflows, page building, certain catalog logic, gets replaced rather than maintained as custom code. This is where a rescue quietly pays for itself, because every module you retire is one less thing to patch forever. The Hyva frontend work often falls into the rebuild bucket, since inherited Luma themes are a common source of the performance problems that stalled the launch.
How do you sequence the rescue to actually ship?
Sequence it as stabilize, then close the critical gaps, then launch behind a watch window, so the store reaches production safely instead of chasing a perfect rebuild. First, stabilize: apply outstanding security patches, fix anything broken in checkout, and get the environment to a known-good state. A half-built store is often also an unpatched store, and shipping new features onto an insecure base is the wrong order.
Then close only the gaps that block launch, not every nice-to-have the original scope imagined. Rescues fail when the new team tries to deliver the old project’s full wish list instead of the minimum shippable store. Define what “live” requires, build to that, and schedule the rest for after launch. Cut over with a rollback plan and a watch window, the same discipline a clean migration uses. Our Magento and Adobe Commerce engineering team is hired for exactly this work often enough that the pattern is predictable: the build did not stall because Magento is impossible, it stalled because no one audited honestly and sequenced ruthlessly. Do both, and most half-built stores are very much salvageable.
