What maintaining a Magento shop involves
Magento 2 is software you have to keep updating. It runs your checkout, your product catalogue and often hundreds of extensions (modules) from different makers. Each part gets its own updates, and they all have to keep working together.
- Security patches: small updates from Magento that close known holes. Without them your shop is open to attacks that have already been described in public.
- Upgrades: the step to a newer version of Magento or of PHP, the language Magento runs on.
- Monitoring: keeping an eye on load times, error messages and scheduled tasks, so you hear about a problem before a customer reports it.
- Backups: a copy of your shop that you can actually restore.
- Fending off attacks: scrapers and bots that put heavy load on your shop or try to get in.
- Releasing: putting changes live without the shop stalling for a moment.
I do this work myself, on a Magento 2.4.7 shop with 328 active modules. What I write here comes from that work, not from a brochure.
Security patches and upgrades
A patch can clash with a module that changes the same parts of Magento. Then the checkout stops working or something goes missing in the admin panel. That is why you never install patches blindly.
- First I read which parts the patch touches and which modules also touch them.
- I apply the patch on a test environment and walk through the main paths: search, cart, checkout and the admin panel.
- I resolve conflicts between modules in the code, so the update can go through.
- Only then does the same change go to production.
That is how I have carried out patch upgrades on a production shop, from one patch version to the next, including resolving conflicts between modules. A bigger version jump works the same way, with more testing. You can read more on the page about Magento 2 upgrades.
Releasing without taking your shop down
After a change Magento rebuilds a lot, and one wrong action at the wrong moment can stall the shop. On a shop with traffic, that means revenue walking away.
So on production I refresh the cache (the temporary memory that makes pages fast) in a targeted way and never all at once. A full flush resets every page to cold at the same time. The server then has to rebuild all of them while visitors are on the site.
I prepare a change on a test environment first, check it, and then take it live in an order that keeps the shop running. I know beforehand which step I would roll back if something turns out badly.
Monitoring and backups
I watch three things: load times, error messages and scheduled tasks (cron jobs, the tasks Magento runs by itself at set moments, such as indexing and sending emails). If one of the three drifts, I get a notification.
- Load times: a shop that gets slower often shows a problem before an error message does.
- Error messages: an error in the log that keeps repeating is usually a module that is not working properly.
- Scheduled tasks: when they stop, stock, search index and emails fall behind without anyone seeing it.
An admin panel that threw errors turned out to be caused by an expired licence of an external module. I tracked that down and fixed it. You only find something like that when you follow the error message all the way into the code.
A backup is only worth something if you can restore it. I check that they run and that your shop can be brought back from them.
Fending off attacks
A shop also gets traffic that is not a customer. Some bots read out your whole catalogue, others look for a vulnerability.
Search is a well-known target, because every search query makes the server work and often does not come from the cache. I shielded that function and filtered the traffic, so real visitors could keep searching and ordering.
A later attempt to run code on the server through a vulnerability I stopped and then investigated, so I knew how the attempt was put together.
From practice
A Magento 2.4.7 shop with 3,400 products, looked after every day
I work daily on a Magento 2 production shop (version 2.4.7) with more than 3,400 products, about 13,600 product pages across four language versions and 328 active modules. Patch upgrades, monitoring, fending off attacks and releasing all belong to that.
A scraper sent 2.3 million search queries from 600,000 IP addresses to the search function. The shop stayed up because I shielded the search function and filtered the traffic.
The same shop reaches an LCP (the time until the largest element is on screen) of 2.14 seconds on mobile for real visitors, down from 14 to 16 seconds. All Core Web Vitals are green. Custom modules are part of the upkeep too: security headers (rules that tell the browser which scripts may run, CSP with SRI hashes), a canonical fix for CMS pages (which tells search engines which version of a page counts), deferred loading of third-party scripts and a warehouse module in development.
How I work, and who you talk to
First I read how the existing code fits together. Then I change things on a test environment, and only after that on production. That is how a shop stays in one piece.
You have one point of contact: the person who writes the code. So you talk to whoever makes the change. What maintenance costs depends on your shop. We talk about that after an introduction.