When a Magento agency stops responding, the correct move is to treat it as an operational incident with a clock on it, not a relationship to repair. Secure every credential you can reach in the first 48 hours, measure your security patch exposure in the first week, put interim coverage on the store, and only then run a proper replacement search. The sequence matters, because an unmanaged Adobe Commerce store is not standing still. It is drifting toward its next missed security patch while attackers scan for exactly that.
We do rescue work on Magento stores, and the went-dark call follows a pattern. It is rarely a dramatic disappearance. Replies stretch from hours to days to nothing. A deploy that was promised for March quietly stops being mentioned. The monthly invoice keeps arriving, which is often the last part of the operation still functioning. By the time a merchant says the word “ghosted” out loud, the store has usually been unmanaged for two or three months. This playbook is what we tell them on the first call, in the order we tell it.
Is your agency actually gone, or just slow?
An agency has effectively gone dark when response time and shipped work both trend to zero while the engagement is still being billed. Slow is a communication problem. Dark is an operational one, and you should make the call on evidence, not on tone.
Four signals separate the two. First, check your patch state: pull up your Adobe Commerce version and compare it against the current security patch line. If one or more security releases have shipped since your last deploy, nobody is maintaining the store, whatever the account manager says. Second, look at ticket half-life. A struggling team answers critical tickets and lets small ones age. A gone team stops distinguishing. Third, check your repository. Commits are the one thing that cannot be faked on a status call, and an empty commit log during a paid retainer month tells you everything. Fourth, count the people. If every thread now routes through one project manager and the developers you used to talk to have vanished from the channel, the team behind the curtain may already be gone.
We wrote previously about the communication cadences that separate healthy agencies from failing ones. If your engagement has been in the warning column of that piece for a quarter, stop waiting for it to self-correct.
What should you lock down in the first 48 hours?
Before any conversation about blame or contracts, inventory and secure every system the agency can touch. You are not accusing anyone of anything. You are restoring the basic condition that the business owns its own store, and you want it done while credentials still work and before any dispute begins.
Work through the access surface in priority order:
| Asset | Where it lives | What to do first |
|---|---|---|
| Magento admin accounts | Your store’s admin panel | List all admin users, disable ones you cannot name, rotate every password, enforce 2FA |
| Hosting control panel | Adobe Commerce Cloud, AWS, or a managed host | Confirm the account is in your company’s name and billing; if it is in the agency’s name, start transfer now |
| SSH and deploy keys | Server authorized_keys, cloud console | Remove keys you cannot attribute to a current, named person |
| Domain and DNS | Your registrar | Confirm registrant contact is you, not the agency; lock transfers |
| Code repository | GitHub, GitLab, Bitbucket | Confirm your organization owns the repo, not a fork in the agency’s account |
| Integration credentials | Payment gateway, ERP, email, tax, search | Rotate API keys the agency created or stored |
| Composer and license keys | Project files, marketplace accounts | Confirm marketplace and extension licenses are registered to you |
Two of these carry most of the risk. If the hosting account is in the agency’s name, your store can be switched off by an unpaid bill you never see. And if the domain registrant is the agency, you do not fully own your own storefront, a situation far more common than it should be. In our rescue engagements roughly a third of inherited stores have at least one of those two problems, and neither is fixable in an afternoon once the other side has stopped answering email.
How exposed is an unmanaged Magento store?
More than most merchants want to hear, and the exposure compounds monthly. Adobe ships security fixes on a defined cadence, and now publishes isolated security patches specifically so critical vulnerabilities can be fixed without waiting for a full release, on the condition that your store is already on the latest security patch line. A store that has missed two quarters of patching cannot even apply the emergency fix without remediation work first. That is the trap an absent agency leaves you in.
The threat side is not theoretical. When the SessionReaper vulnerability hit Adobe Commerce and Magento in late 2025, Sansec found that three in five stores were still unpatched six weeks after Adobe’s emergency patch, while active exploitation was underway. Their researchers estimated that a meaningful share of all Magento stores ended up with backdoors injected during that wave. Every one of those compromised stores had, functionally, nobody watching.
So in week one, get three answers: what patch level the store is on, what has shipped since, and whether there is any evidence of compromise. A malware and integrity scan is cheap relative to what it rules out. If the store takes payment cards, remember that PCI responsibility sits with the merchant, not with the agency that stopped showing up.
How do you get your code, database, and licenses back?
Start from what you can reach, not from what you are owed. If you have production access, you can recover almost everything without the agency’s cooperation: a full database dump, the media directory, the deployed codebase, and the list of installed extensions. A deployed codebase is not a substitute for the real repository with its history, but it is enough to keep the business running and to give a new team something honest to audit.
Then pursue the rest in parallel. Read your contract’s IP and work-product clauses before sending the first demand letter, because your leverage depends on what was actually signed. Most agency agreements assign work product to the client on payment, which means the repository, deployment configuration, and documentation are your property. A short, factual written request for specific deliverables, repo transfer, credentials list, environment documentation, sets up the legal path if it comes to that, and often shakes the assets loose without it.
Extension licensing deserves its own line item. Marketplace extensions, paid themes, and third-party modules are frequently purchased under the agency’s accounts. If those accounts go away, you lose update access precisely when a new team needs to bring everything current. Rebuying a handful of licenses is annoying but cheap. Discovering the problem during your next upgrade is not. We covered the full asset checklist in how to exit a Magento agency cleanly, and it applies double when the exit is not by choice.
Who keeps the store alive while you choose the next partner?
Put interim coverage on the store before you start the replacement search, because the search takes longer than the store can safely wait. A proper agency evaluation runs four to eight weeks. An unmanaged production store carrying a revenue stream should not sit exposed for that long: ITIC’s downtime research puts the hourly cost of downtime above $300,000 for 91 percent of mid-size and large enterprises, and for an eCommerce operation an outage is a 100 percent revenue stop for its duration.
Interim coverage is a narrow, defined engagement, and any competent Magento development team can quote it quickly: apply outstanding security patches, confirm backups actually restore, stand up uptime and error monitoring, verify cron and indexers are running, and document the environment as found. Deliberately exclude feature work. The goal is a stable, observable store and a written baseline, which also becomes the technical brief for whoever you hire permanently. In our own rescue intakes, this stabilization pass is the first 72 hours of work, and the as-found document it produces has settled more than one dispute about what the previous team did and did not leave behind.
How do you replace them without repeating the mistake?
Hire against the failure mode you just lived through, not against a feature wishlist. Merchants coming out of a ghosting tend to over-index on price or on personality, and both select for the wrong thing. What failed was accountability, so test for accountability.
Three mechanisms do most of the work. Structure the engagement so that you own everything from day one: repos in your organization, hosting in your name, credentials in your vault, licenses on your accounts. Any agency that resists that structure is telling you something. Set the communication contract in writing before signing, including named developers you can talk to directly, response-time expectations by severity, and a weekly commit-visible cadence, the absence of which was your earliest warning sign this time. And run a small paid trial project before committing to a retainer, scoped tightly enough that you see their real process, from ticket to code review to deploy, within a month.
The recovery itself is finite. Access secured in days, exposure measured in a week, interim coverage inside a month, replacement seated by the end of a quarter. Stores come through this. The merchants who come through it strongest are the ones who moved on the access audit the same week the silence became undeniable, instead of sending one more follow-up email into the void.
