What Magento Support and Maintenance Should Include

If you run a Magento store, you already know the feeling: nothing is “wrong,” orders are coming in, and you are still one bad update away from a Saturday you did not plan for.

That is what support is for. Not a helpdesk. Not a rebuild. Someone who already knows your store, keeps the boring work current, and picks up the phone when checkout actually dies.

What you are actually paying for

A useful monthly plan does four jobs. If a vendor cannot point to all four, you are buying office hours with a nicer name.

• Keep the platform current. Security patches and extension updates, tested on a staging copy before they touch the live store.
• Watch the store. Uptime, errors, checkout, payments, shipping. You should not learn about a failure from a customer.
• Fix what is already annoying. A set number of hours each month for bugs, admin headaches, and small improvements so those never become a separate project.
• Show up when it is on fire. A person who can log in. A number you can call. Not a ticket that waits until Monday.

That is the list we put in our Magento support plans.

Monthly help vs calling when it breaks

Calling someone after a white screen, a payment method that stopped capturing, or a suspected hack is the right buy once. You pay for the incident. Then you are done. It costs more per hour because they have no history with your store, and the same kind of problem often comes back.

A monthly plan is the right buy when the store is live and taking money. Patches get applied before attackers do. The team already has staging, access, and a record of what changed. Emergencies still happen. They just cost less and end faster.

A simple rule: if you have needed Magento help more than once in a year, the next emergency invoice will probably cost more than a month of coverage. That is usually when Magento support plans cost less than another emergency invoice.

What a decent plan includes

Use this as a sniff test. Ask them to show it in writing.

Patches that go through staging. “We’ll patch when you open a ticket” is not a patch program. Adobe ships Magento security fixes on a rolling basis. They get applied on a copy of the store first, checkout and payments get checked, then production. You should get a note of what shipped.

Updates that will not surprise you. PHP versions go out of support on a public calendar. Third-party modules drift. If the shopper-facing site is Hyvä, the agency has to have actually shipped Hyvä — the frontend is not the old Magento one, and a module bump can break things the admin screen will never show.

Someone watching checkout, not just “the server.” If the first alert is a shopper email, that is not monitoring.

Hours you can actually use. Four hours a month covers patches and a few bugs. Eight hours covers that plus a real look at speed and checkout. “Unlimited” only means something if they have named the person doing the work and defined what counts as minor.

A report you can read. What got patched. What broke. How many hours got used. What’s next. No report means you cannot tell work from an invoice.

A phone number for production. Email is fine for “can we change this label.” It is the wrong tool when orders stop. If a vendor cannot show those items in writing, they do not have Magento support plans — they have a helpdesk.

What the first month should look like

If month one is a vague “onboarding,” you will still be the person who knows the store. A first month that is real looks more like this:

• Access: admin, hosting, repo, and a staging environment. If you do not have staging, that is the first conversation — not a surprise during a patch.
• A pass over what is already overdue: unapplied security patches, PHP version, extensions that have not been touched in a year.
• Monitoring actually turned on, with alerts going to a person who can log in.
• A written list of what they will do this month vs what is a separate project.

You should still be able to work in the admin the whole time. A patch window should not mean taking the store down for the afternoon if staging is real.

What you still own

Magento support plans are not a store manager. You still own merchandising, ads, content, catalog, and the business decisions. They own the platform staying current, the emergencies, and the small technical work inside the hours you bought.

Keep the code in a repository you control. Month-to-month should mean you can leave without a hostage situation. If an agency will only work in a repo they own, that is a problem regardless of the monthly price.

What a plan is not

It is not a Magento 1 to Magento 2 migration, a full Hyvä rebuild, a new checkout, or an ERP project. Those need their own scope. Stuffing them into “unlimited hours” is how retainers blow up and everyone gets angry.

If you are still on Magento 1, or you are several versions behind and cannot take the next security release, fix that first. Patching a store that cannot be patched is wasted money. See Magento 1 to Magento 2 migration if that is you.

How we do it

We have been on Magento since 2008, in Chicago. The same people who write our extensions support the stores. We work on Magento Open Source, Adobe Commerce, and Hyvä. Plans are month-to-month: Starter from $500, Growth from $900, Enterprise from $1,800. The $900 plan is the one most live stores actually need.

Numbers and what’s in each tier are on our Magento support plans. Read that when you are choosing coverage — not while the store is down.

When to call

Call when checkout is failing, orders are not capturing, the site is throwing errors, or you think someone is in the store who should not be. That is (773) 466-2454. If we can take it today, we start today.

If the store is fine and you want someone on the monthly work, use the form on our Magento support plans. We reply within a business day. Same number is there if you would rather talk it through.