Guides
The Complete Magento Maintenance Guide for 2026: Monthly, Quarterly, Annual
September 1, 2026 - Alexandru-Manuel Carabus
Magento maintenance is not hosting and it is not luck. It is a fixed set of tasks on a fixed cadence. Here is the complete 2026 checklist, monthly, quarterly and annual, with the one story that shows what skipping a single month actually costs.
Ask five providers what Magento maintenance means and you will get five different invoices for five different things. One sells you hosting with the word maintenance printed on it. One sells you a phone number to call when something breaks. One sells you a retainer whose contents nobody can list. The word has been stretched until it means everything, which in practice means nothing.
Maintenance is not hosting, and it is not incident response. It is a fixed set of tasks on a fixed cadence that keeps a store patched, fast and recoverable, done before anything is on fire. This guide is that list, the one we run internally, organized the only way maintenance makes sense: by how often each task has to happen. If you want the two-minute version first, we published three tests you can run on your own store before Monday. This is the full version those tests are sampled from.
What Magento maintenance actually covers
Every real maintenance program, whatever the provider calls it, breaks down into six workstreams:
- Security patching. Applying Adobe's security releases, and the out-of-band hotfixes, within days of publication, not quarters.
- Module and dependency updates. Keeping third-party extensions and Composer dependencies current and compatible with each other.
- Monitoring and log triage. Reading what the store is already telling you in its logs before customers tell you louder.
- Backups and recovery. Not having backups. Having restores, proven by testing.
- Performance. Watching Core Web Vitals and server response drift before rankings and conversion pay the price.
- Upgrade planning. Staying close enough to current that upgrades are routine instead of projects.
If a maintenance offer cannot show you activity in all six, it is one of the five invoices from the opening paragraph, not a maintenance program.
The monthly checklist
Monthly is the heartbeat. Miss a month and nothing visibly happens, which is exactly what makes it dangerous.
- Review and apply security patches. Adobe ships scheduled security releases on a roughly quarterly cadence, but the dangerous ones do not wait for the calendar. SessionReaper (CVE-2025-54236, CVSS 9.1) arrived as an out-of-band emergency patch in October 2025. A monthly patch review means you are never more than a few weeks behind anything; a good provider applies critical patches in days, not at the next monthly window.
- Update modules and dependencies on staging first. Run `composer outdated`, review changelogs, update on staging, run the test suite, then promote. The stores that get hurt by updates are the ones that do them annually in one terrifying batch.
- Triage the error logs. `var/log/exception.log` and `var/log/system.log` growing week over week is the store whispering before it screams. Fifteen minutes of reading, once a month, catches integration failures, payment gateway errors and dying cron jobs while they are still invisible to customers.
- Test a backup restore. Not "check the backup ran." Restore it, on an isolated environment, and confirm the store comes up. A backup nobody has ever restored is a hope, not a plan.
- Check Core Web Vitals in Search Console. One glance at the CWV report catches a regression introduced by last month's module update while it is still a graph, not a ranking drop.
- Audit admin access. Review admin accounts and API integrations. Remove what no longer needs to exist. Most compromised stores were opened with a key, not a crowbar.
The quarterly checklist
Quarterly work is about debt: finding it, measuring it, paying it down before it compounds.
- Plan the next version step. Where are you against the current Magento patch release, and what is the path to it? Stores more than two patch releases behind are doing archaeology, not upgrades, and the cost curve bends sharply upward.
- Audit the module list, and actually remove things. Every installed module is update surface, conflict surface and attack surface. When we took over the Vitacom store, we removed roughly 180 modules; that single cleanup is a large part of how a store goes from PageSpeed 12 to 100 and stays there. Ask of every extension: what would break if this were gone? If the answer is nothing, it is not an asset, it is a liability with a licence fee.
- Run a performance regression pass. Compare TTFB, LCP and server load against last quarter's baseline. Performance never falls off a cliff; it erodes one "small" module and one unoptimized image at a time.
- Verify staging still matches production. Configuration drift between environments is why "it worked on staging" is a sentence everyone in ecommerce has said. A quarterly sync check keeps staging honest.
The annual checklist
- Map the end-of-life calendar. Magento versions, PHP versions, Elasticsearch or OpenSearch, Redis, the operating system underneath. Every one of these has a support horizon, and the expensive upgrades are the ones discovered late. One planning session a year turns EOL surprises into scheduled work.
- Right-size the infrastructure. Load changes, catalogs grow, code improves. Vitacom ended the year on one eighth of its previous hardware, 64 cores down to 8, because the code stopped needing brute force. The opposite direction happens too. Either way, the bill should follow reality once a year.
- Review module licences and contracts. Renewals for extensions nobody uses anymore hide comfortably in annual invoices.
- Run a full security review. Beyond patches: admin URL exposure, TLS configuration, CSP headers, integration credentials, the works. Once a year, look at the store the way an attacker would.
What skipping it costs, with a date on it
This is not a hypothetical section. On a Thursday in October 2025, Adobe published an emergency patch for SessionReaper, one of the most severe Magento vulnerabilities ever disclosed. Within six weeks, an estimated 81 percent of Magento stores had seen attack traffic probing for it, and an estimated 16 to 18 percent of stores were backdoored. The patch existed on day one. Every backdoored store was a store where nobody owned the monthly patching cadence.
The difference between the stores that shrugged and the stores that spent November rebuilding customer trust was not budget or luck. It was whether "apply security patches" was somebody's scheduled job. We wrote up the full incident and its lessons in SessionReaper and the real cost of owning a Magento store.
Doing it yourself versus paying someone to own it
Everything above is doable in-house. None of it requires an agency. What it requires is that someone specific owns the calendar, has staging to work on, and does not skip the boring months, which is precisely where self-managed maintenance usually dies. The checklist is free; the discipline is the product.
The honest trade is this: a retainer buys you the discipline plus a guarantee. Ours puts response times in writing, two working hours on critical incidents, because "we will get to it" is not a commitment you can run a business on. What a program like that costs depends mostly on your module count and complexity, which is a topic big enough that we are giving it its own teardown next. In the meantime, the support and development service page lists what the program includes, and our development cost teardown covers the wider budget picture.
Where to go from here
Run the monthly checklist against your store this week. Not the whole guide, just the monthly section. If every box ticks, you are in better shape than most of the market and you should simply put the cadence in a calendar. If two or more boxes fail, especially the patch review and the restore test, that is worth a conversation before it becomes an incident. Book a free strategy call and bring your patch status; we will tell you honestly whether you need a retainer or just a calendar.