The single largest source of agency surprise estimates is the merchant not knowing what shape their Magento codebase is actually in. Agencies quote conservatively because they have been burned by inheriting stores that looked fine at the sales pitch and turned out to be a year of cleanup work behind the front end. The merchant ends up paying for that conservatism, often two to three times what the work would cost on a healthy codebase. The fix is straightforward: audit your own codebase before you go shopping for an agency.
A merchant-led audit does not need to be exhaustive. It needs to surface the seven categories of risk that drive agency pricing decisions, so that the conversation with prospective partners starts from facts instead of estimates. Bemeir’s Magento development team has inherited enough mid-market stores from prior agencies to know that a one-week pre-audit pays for itself many times over in the quality of proposals you will receive afterward.
The seven audit categories that drive pricing
Agencies do not quote on lines of code. They quote on risk. The seven categories below cover roughly 90% of where that risk sits.
Platform and patch level. What version of Adobe Commerce or Magento Open Source is the store running? When was the last security patch applied? Are you on a supported release line, or behind by one or more major versions? The Adobe Commerce release schedule is public, and any agency will check this in their first hour of due diligence. Surface it yourself.
Custom module inventory. How many custom modules live in app/code, and what does each one do? A store with 8 well-named, well-scoped custom modules is in a completely different cost class from a store with 47 modules where nobody remembers what half of them are for. Make a list with a one-line description per module.
Third-party extension inventory and licensing. What commercial extensions are installed, where did they come from, and are the licenses current? Are any extensions patched or modified from their original release? Modifications inside vendor directories are a classic source of upgrade pain that prior agencies often leave undocumented.
Frontend status. Is the storefront on Luma, on Hyvä, on a custom theme, or on a partial migration that stalled mid-flight? Stalled migrations are particularly expensive to inherit; the new agency has to either finish the migration or unwind it.
Integration surface. Which external systems is the store talking to, by which mechanism (REST, GraphQL, file drop, webhook), and which of those integrations are critical to operations? An Adobe Commerce store that quietly depends on a 2018-era SOAP integration with an ERP nobody knows the credentials for is a different proposition from one with documented, modern API integrations.
Infrastructure and hosting. Where is the site hosted, who controls the infrastructure, what is the runtime environment, and what is the deployment process? Adobe Commerce Cloud, self-hosted on AWS, self-hosted on a VPS, and managed Magento hosting providers all carry different operational profiles.
Observability. What monitoring exists? What does the agency or in-house team look at when something breaks? A store with New Relic, Sentry, and proper logging is several times faster to stabilize than a store where the only monitoring is “the customer service team tells us when something breaks.”
What to actually produce
The output of your audit is a short document, two to four pages, that you hand to every agency you are evaluating. It should contain:
| Section | Contents |
|---|---|
| Platform snapshot | Magento version, patch level, last upgrade date, hosting environment |
| Custom code | Module count, list with one-line descriptions, framework lines (composer.json overview) |
| Extension list | Commercial extensions with vendor, version, license expiration |
| Frontend state | Theme name, framework (Luma/Hyvä/custom), migration status |
| Integration map | List of external systems and the mechanism connecting each |
| Known issues | Open bugs, performance complaints, security patches behind |
| Recent history | Last 12 months of major changes, current agency relationship status |
The document does not have to be polished. It has to be honest. Every agency that receives it will be able to scope more accurately, and the scoping conversations will be substantive instead of theatrical.
How to gather the data without breaking anything
You do not need engineering work to produce the audit. Most of it comes from read-only sources:
The Magento admin shows you the platform version and the installed extensions list. The composer.json and composer.lock files (your current team or hosting provider can email these) show you exactly what is installed and at what versions. A directory listing of app/code shows you the custom module inventory. The deployment logs or git history show you the change cadence. The hosting provider can pull a list of cron jobs and integration endpoints.
If your current team will not cooperate with even this level of read-only audit, you have already learned something important about why you are looking for a new agency.
Why agencies will price differently afterward
When Bemeir’s team receives an inquiry with a real audit attached, the proposal cycle is faster and the quote is tighter. The reason is simple: every assumption an agency would otherwise have to bake conservatively into the estimate becomes a known fact. You can see the same effect across every reputable agency you talk to. The agencies that refuse to engage with the audit document, or that produce wildly different quotes despite having identical information, are signaling something useful about how they operate.
A merchant who hands over a clean audit also signals that they are a sophisticated buyer. Agencies allocate their better engineers to clients who are clearly going to be good partners on their side of the relationship. The quality of the team you get assigned is partially determined by the quality of the brief you provide.
The categories merchants almost always forget
Two areas come up in 90% of inherited engagements but rarely appear in merchant-side audits:
Cron jobs. Magento depends on cron for indexing, queue processing, and scheduled tasks. If cron has been silently failing on some entries for months, the store has indexing issues, abandoned cart emails are not firing, and reindex backlogs are growing. The Adobe Commerce cron documentation describes what should be running; cross-check against what actually is.
Backup verification. Almost every store has some form of backup. Almost no store has actually tested a restore. When the new agency asks “what is your recovery posture,” the honest answer for most merchants is “we have backups, we have not verified them.” Run a test restore before you switch agencies, ideally while the outgoing team is still under contract to help if something is wrong.
When the audit reveals you need more than a new agency
Sometimes a thorough self-audit reveals that the right answer is not just “new agency for the existing codebase” but “new agency to do a structural reset.” A store with 47 modules of unknown function, three stalled prior migrations, and a Magento patch level 18 months behind is closer to a rebuild candidate than a tune-up candidate.
This is a useful thing to discover before you start agency conversations rather than three months in. Bemeir advises Magento merchants honestly about which bucket they fall into; the agencies that pretend a rebuild is a tune-up are the ones merchants regret hiring six months later.
A clean pre-engagement audit gives every prospective partner the same starting point. It compresses the proposal cycle, reduces surprise estimates, and lets you compare agencies on what they will do rather than on what they have assumed about your code. It is the single highest-leverage week a Magento merchant can spend before signing the next contract.
