You're interviewing a new agency to take over your Magento 2 store. Or you just bought the business and inherited the store from a founder who did everything themselves. Or your current agency is transitioning you to a new account lead and you want to know what you're actually dealing with. Three different starting points, same question: what does a good tech partner find on day one that I should be asking about today?
The answer is the eight-item list below. None of these are emergencies, none of them mean anyone did anything wrong; they're the fingerprint every Magento 2 store picks up over years of patched-on decisions, departing developers, and emergency launches. A good agency looks at each one on day one, tells you which ones are normal and which ones are load-bearing technical debt, and gives you a sense of what a remediation roadmap would cost.
Key takeaway: Every inherited Magento 2 store has some of these. That's not a failure; it's the nature of a six-year-old platform with a lot of moving parts and years of commercial pressure. The question a good agency answers on day one isn't "is it clean?" It's "which of these matter, and what would it take to fix?"
How to use this list
Two modes.
If you're inheriting a store (new owner, new account lead, migration from an internal team), work through the list with your new tech partner in your first week. Each red flag has a concrete artifact they can show you: a file count, a log snippet, a command output. If they can't produce the artifact, that's the first red flag above everything else on the list.
If you're shopping for a new agency, ask during the proposal phase: "Will you run through these eight things on day one and tell us what you find?" Any competent Magento 2 specialist will say yes without hesitation. The ones who hedge, or who say "that sounds like it's for later", are the ones who are planning to not look.
The 8 red flags
-
How many custom modules are installed, and who built them?
Magento 2 is assembled from modules: packages of code that add features to the store. The count on its own isn't the red flag. A store with dozens of modules built by the same agency over several years of structured work can be perfectly maintainable — that's just a complex store, not a broken one. The red flag is a high count from many different vendors: extensions from five different agencies, a handful from Marketplace, a few abandoned experiments from contractors who left three years ago. That combination creates dependency conflicts, unclear ownership, and upgrade headaches. Ask your agency: how many different vendors contributed modules, which ones are actively maintained, and which ones can you trace back to someone who would still pick up the phone?
-
Is anything writing debug output to production error logs?
Debug log lines ("it reached this point", "the value is X") belong in development, not in production. They slow the site down and they often leak data. Every request to a slow store we audit shows some of this. Ask your agency to pull an hour of production error logs and circle any entries that look like debug output rather than real errors. The shorter that list, the cleaner the codebase.
-
Are there test or developer files left in your public webroot?
When developers debug a problem, they sometimes drop a small PHP file into the store's public folder to test something. The file is supposed to come out after the debug session ends. It often doesn't. Ask your agency to walk the public webroot and list every PHP file that isn't part of standard Magento. Anything test-shaped, backup-shaped, or database-tool-shaped gets removed immediately.
-
Is there a CI pipeline, and are there automated tests?
CI (Continuous Integration) is the practice of running automated checks every time code changes, before it goes live. Ask your new agency to look for CI config files in the project (things like a .github/workflows folder, a .gitlab-ci.yml file, or a Bitbucket pipeline config). Then ask: are there any automated tests? Unit tests check individual functions in isolation. Integration tests check whether the store's components work correctly together. End-to-end tests simulate real customer behavior from a browser. As a bonus: code coverage reports and complexity checks mean someone set up tooling to understand quality over time, not just whether the site loads. A codebase with no tests isn't automatically bad, but it means every change carries more risk and every refactor is manual. A codebase with tests and a CI pipeline is meaningfully safer to take over and work on.
-
Are your platform versions still supported?
Magento, PHP, and the search engine (Elasticsearch or OpenSearch) all have end-of-life dates. Past those dates, you stop getting security patches. A good agency tells you the current versions on your store, when each one reaches end of life, and what the upgrade path looks like. We've covered Magento's release cycles in more detail at /magento-kb/general/magento2-release-cycles-and-eol if you want the background. For this check, the answer you want is: "Everything we run is currently supported, and here's the upgrade calendar for the next 18 months."
-
Is cron running and catching up?
Magento uses a background process called "cron" for most things that aren't directly clicked by a customer: emails, price updates, stock syncs, abandoned-cart recovery. When cron breaks, the store keeps loading and looking normal for a while, then features quietly stop working. Emails don't send. Prices don't update. Stock doesn't sync. Ask your agency to show you the cron status and when the oldest unprocessed job was queued. "All caught up, running every minute" is the answer you want.
-
Are the indexers healthy?
Magento uses "indexers" to keep catalog, price, and search data up to date. When an indexer is stuck, the customer sees stale data: outdated prices, products that show as in stock when they aren't, category pages that don't update when you publish a new product. Ask your agency for a screenshot of the Indexer Management page. Every indexer should say "Ready" and "Update on save". Anything stuck in "Processing" for more than a few hours is a problem.
-
Does the codebase look like someone is still maintaining it?
You won't see this one yourself, but your new tech lead will. Is there version control with clean commits, or a zipped backup with no history? Are class files full of commented-out blocks that nobody knows whether to delete? Ask your developer to run
composer outdated -D— it lists every direct dependency that's behind its current released version. A long list is a reliable signal that nobody has touched the project in a meaningful way for a while. None of these are single-point failures. Together, they tell you whether the codebase has been actively cared for or passively survived. A good agency will give you a blunt read after a few hours of looking.
What the answers tell you
Some red flags on their own are noise. Two or three together are a pattern.
One or two findings from this list is normal. Every inherited Magento 2 store we've ever looked at has a couple of these. The fixes are in the course of normal maintenance, fitting into the first quarter of work with the new team.
Four or five findings puts you in territory that warrants a proper discovery phase before any new feature work. The technical debt is load-bearing. Adding new features on top of it without addressing the base first means each new feature costs two or three times what it should. A one-to-two-week discovery audit with the new agency produces a prioritised plan.
Six or more findings, especially if #2 (debug logs), #3 (test files), and #5 (EOL versions) are all true, is a signal that the previous team had stopped caring. Not an accusation. Sometimes teams get overloaded, or the account winds down, or the business changed and the tech didn't get the attention. Either way, the new agency's first quarter is a remediation quarter, and that needs to be budgeted openly.
Your new agency should be comfortable giving you this read in plain English, without hedging and without gloom. Panicking doesn't help you. Pretending the issues don't exist also doesn't help you. The middle ground is what a good partner provides.
Related reading
- Why Your Magento 2 Store Feels Slow Even With Varnish and Redis. If your inherited store feels slow, this covers the three most common real causes.
- Is My Magento 2 Store Actually Safe? A 10-Minute Self-Check for Merchants. The security-focused companion to this list. Some of the same red flags, different framing.
- Magento 2 Release Cycles and End of Life. Background on red flag #5.
FAQ
Inheriting a Magento 2 store? Let's walk the list together.
We offer a free 30-minute discovery call for merchants taking over a Magento 2 store. You get an honest read on where the technical debt sits, what a full audit would uncover, and whether the next six months need a remediation quarter or just normal maintenance.