01
Security & Support
Which Magento and PHP versions are running in production?
Check deployment records or run bin/magento --version. Use the version that is live now, not the version planned for the next release.
Both versions and their support status are currently verified
We know the versions but have not checked current support dates
Supported, but upgrade or patch work is due
The installed platform or PHP version is unsupported
We are not sure
02
Security & Support
How recently did someone confirm the Magento security patch level running in production?
Use the patch level that was verified after deployment. An approved ticket or a completed staging test does not confirm what is live.
Within the last 30 days
One to three months ago
Three to six months ago
More than six months ago
We have never verified a production security update
We do not know
03
Security & Support
How does your team check for signs that the store has been compromised?
Think about admin access, unexpected file changes, checkout scripts, integrations, and other indicators your team reviews on purpose.
We actively monitor and review compromise indicators
A focused review was completed recently
Nothing looks wrong, but we have never performed a focused check
We had an incident and believe it is resolved
We suspect something is wrong now
We are not sure what evidence to review
04
Checkout & Revenue Flow
How does your team find out when checkout or payment fails?
Choose the answer that best describes production visibility today, including failures customers never report.
Checkout and payment failures are monitored and currently stable
Rare failures occur, and we can trace them
We mainly learn about failures from customer reports
We see several unexplained failures each month
Checkout or payment failures are a recurring production problem
We have no reliable visibility
05
Performance & Infrastructure
How does your team measure storefront and Magento Admin performance?
Use production measurements and repeatable workflows, not a one-time speed test or a general impression that the site feels fine.
Measured with production data and reviewed against targets
Measured, with known performance work still open
It feels acceptable, but we do not measure it consistently
Customers or staff regularly experience slow pages
We do not have a dependable measurement
06
Operations & Observability
How does your team catch failed cron jobs or indexer backlogs?
A running cron service does not prove that Magento jobs are completing or that scheduled index work is keeping up.
Failures and backlog conditions generate actionable alerts
They are checked manually on a defined schedule
They are assumed healthy unless a business user reports a problem
Missed jobs, backlog, or invalid indexers are a known problem
We do not know
07
Upgrade & Change Readiness
Can your team reproduce production from version control and documented configuration?
Include code, environment configuration, deployment steps, and any hotfixes made directly in production.
Deployments are repeatable and parity is checked automatically
Changes are documented and parity is checked manually
Production hotfixes happen and are reconciled later
Production contains changes that are not represented elsewhere
We cannot verify environment parity
08
Custom Code & Ownership
Can your team explain and maintain every custom module and third-party extension in use?
For each module, the team should know why it exists, who maintains it, which version is installed, and whether it is still supported.
Every module has a documented purpose, maintainer, version, and support status
Most modules are understood, current, and assigned to someone
Some modules have no clear purpose, maintainer, or update history
Known abandoned or unsupported modules remain in use
No reliable inventory exists
09
Upgrade & Change Readiness
How prepared is the store for its next Magento upgrade?
Consider the target Magento and PHP versions, extension compatibility, custom code, testing, deployment, and rollback.
The next supported target and tested upgrade path are documented
A recent upgrade succeeded, but the next one is not planned
More than a year has passed without a successful version upgrade
An upgrade failed, stalled, or was abandoned
We do not have an upgrade plan
10
Recovery Readiness
When did your team last restore a complete backup and verify the recovered store?
A successful backup job confirms that files were written. A restore test confirms that the store can actually be recovered.
Restore tests run on a documented schedule
A complete restore has succeeded at least once
Backups run, but a complete restore has never been tested
We are not certain a complete recovery is possible
11
Operations & Observability
Which Magento failures does your production monitoring detect automatically?
Consider checkout and payment errors, cron failures, indexer backlog, queue growth, integrations, resource pressure, and application exceptions.
Customer paths, background work, resources, and service failures are monitored
Application errors and selected logs generate alerts
Monitoring mainly confirms that the site responds
The team reviews logs after a customer or staff member reports a problem
We do not know what is monitored
12
Custom Code & Ownership
How does your team confirm that completed development work reached production and achieved the expected result?
Look for a clear link between the request, code change, tests, deployment record, and the result someone can verify.
Requests, code changes, tests, deployments, and results can be matched
Work is itemized, but the production result is not always checked
Status updates or invoices are usually accepted without technical verification
An internal technical owner reviews and accepts completed work
The team has no consistent way to verify completed work
13
Operations & Observability
When a production problem starts, how quickly can the team identify what changed and where it failed?
Consider release records, timestamps, application logs, infrastructure signals, and whether one person can trace the request across systems.
Changes and failures can be correlated quickly from shared evidence
The evidence exists, but someone must assemble it manually
Evidence is split across vendors, servers, or individual accounts
Incidents often take hours or days to narrow down
We have not tested how quickly an incident can be traced
14
Performance & Infrastructure
How does your team review database growth before it affects performance or storage?
Think about quote, report, session, log, import, and integration tables that can grow quietly on a busy store.
Table growth is measured, trended, and reviewed against retention rules
Database size and large tables are reviewed on a schedule
The team watches total storage but not table-level growth
Growth is investigated after storage or performance becomes a problem
We do not know which tables are growing fastest
15
Upgrade & Change Readiness
What must be verified before and after a production release is accepted?
Include checkout, payments, search, cron, indexing, integrations, cache behavior, and a documented rollback path.
Every release has defined checks, evidence, approval, and rollback criteria
A release checklist is used, but evidence or approval varies
The team performs a few smoke tests after deployment
A release is accepted unless someone reports a problem
There is no consistent release acceptance process
Your answers are calculated in this page and are not stored or submitted as a sales lead. See the Privacy Policy .
