Two websites can use the same CMS and need completely different maintenance plans.
A five-page company site that changes twice a year does not need the same coverage as an eCommerce store running daily orders, paid campaigns, several payment methods, product feeds, shipping integrations, and weekly releases.
The right maintenance plan depends less on the platform name and more on what can break, how much a failure would affect the business, and how quickly you need someone to respond.
That gives you a much better way to compare maintenance providers than simply asking how many support hours are included.
Start with risk, not package names
Most maintenance providers divide their services into packages: Basic, Business, Growth, Premium, Enterprise, or something similar.
Those names do not tell you much.
Before looking at a package, answer a few practical questions:
- What happens to the business if an important part of the site stops working?
- How many external systems does the website depend on?
- How often does the site change?
- How much data could you afford to lose?
- How long could an important service remain unavailable?
- Do you need support outside normal business hours?
The answers define the maintenance requirement. The package should come afterwards.
What a maintenance plan should actually promise
A useful maintenance agreement defines responsibilities rather than simply saying “support included.”
You should be able to determine:
- What gets monitored
- What gets updated
- What the provider is responsible for fixing
- How incidents are prioritised
- How quickly somebody responds
- How changes are tested before production
- What gets backed up
- How recovery works
- What work is included in the monthly fee
- What happens when a request falls outside the agreed scope
If those details are missing, two maintenance plans with similar prices may provide very different levels of protection.
1. Work out how business-critical the website is
Start with the consequences of failure.
If a brochure site becomes unavailable for an hour, the business may miss a few visits or enquiries. If checkout stops working on a store during a campaign, customers may be unable to place orders while advertising continues sending traffic.
Ask what happens if:
- The entire site is unavailable
- Checkout stops working
- One payment method fails
- A product feed stops updating
- Tracking stops recording purchases
- Order data cannot reach another business system
You do not need to attach a precise financial number to every scenario.
The purpose is to classify what is critical, what is important but tolerable for a few hours, and what can wait until the next business day.
That classification should influence monitoring, escalation, and response targets.
2. Count dependencies, not just pages
A 20-page website can be operationally more complex than a 2,000-page website.
What matters is what those pages depend on.
An eCommerce site might rely on:
- A CMS or commerce platform
- A custom frontend
- Payment providers
- Shipping or courier integrations
- ERP, PIM, CRM, or accounting systems
- Product feeds
- Email services
- Analytics and advertising tags
- Consent management
- Search services
- Third-party apps or plugins
Each dependency introduces another place where behaviour can change without anybody editing the homepage.
A payment provider can modify an API. An app can release an update. A tracking implementation can break after a checkout change. A shipping integration can return an error for one particular market.
More dependencies do not automatically mean the website is unreliable. They do mean that monitoring and change management become more important.
3. Define how much data you can afford to lose
“We have backups” is not enough information to evaluate a maintenance plan.
You need to know what is backed up, how often, how long copies are retained, and whether those backups can actually be restored.
One useful question is:
If the system failed now, how far back could we restore without creating an unacceptable business problem?
This is the idea behind a Recovery Point Objective (RPO).
For example, a website that changes once a month might tolerate losing several hours of recent changes. An active store processing orders continuously may need a much smaller recovery window.
The maintenance plan should therefore define backup frequency based on the data that actually changes.
Ask what the backup includes
Depending on the website, recovery may require more than a copy of the public files.
Check whether the backup scope includes the relevant:
- Database
- Media and uploads
- Application files
- Configuration
- Infrastructure configuration where applicable
- Other data required to recreate the working system
Ask whether restores are tested
A successful backup notification proves that a backup job ran. It does not prove that the complete system can be restored from it.
Restore testing is therefore more useful than simply asking whether backups exist.
4. Decide how long recovery can take
The second recovery question is:
How long can this service remain unavailable before the impact becomes unacceptable?
This is the principle behind a Recovery Time Objective (RTO).
The answer can be different for different systems.
A store might decide that checkout needs immediate escalation, while an internal reporting screen can wait until the next working day.
That is more useful than asking for the same response level for every ticket.
5. Understand response time before signing an SLA
One of the easiest maintenance terms to misunderstand is response time.
If an agreement promises a one-hour response, that normally means somebody will acknowledge or begin investigating the incident within that period.
It does not necessarily mean the problem will be fixed within one hour.
There are several useful time measurements:
| Term | What it tells you |
|---|---|
| Detection time | How quickly the problem is noticed after it starts |
| Response time | How quickly somebody begins responding after the incident is detected or reported |
| Recovery or resolution time | How long it takes to restore the affected service or resolve the issue |
A maintenance provider can control response processes much more directly than resolution time. A problem involving an external payment provider, for example, may not be completely under the agency's control.
This is why the plan should also explain escalation and communication rather than promising an unrealistic fix time for every possible incident.
6. Match support hours to when the business operates
Business-hours support can be perfectly reasonable for many websites.
It becomes a different decision when a store generates a meaningful share of its revenue during evenings, weekends, international trading hours, or scheduled campaign launches.
Look at when failures would actually matter.
If Saturday afternoon is one of your busiest periods, Monday-morning incident response may not match your risk profile.
That does not automatically mean you need 24/7 engineering coverage. It may mean you need 24/7 monitoring with an agreed escalation process for specific critical failures.
Those are different services, and the plan should make the distinction clear.
7. Consider how often you change the site
A stable website that receives a handful of changes each year has a different maintenance profile from one where marketing, development, and eCommerce teams deploy continuously.
Look at how frequently you:
- Launch campaigns
- Create landing pages
- Change tracking
- Add integrations
- Modify checkout
- Change themes or frontend components
- Install or remove plugins or apps
- Release new functionality
Frequent changes increase the importance of staging, testing, release checks, rollback procedures, and change history.
The maintenance plan should match the pace of the website.
What should actually be included?
Once you understand the risk profile, compare what each provider actually delivers.
Security updates and patching
The scope should explain which layers the provider maintains.
Depending on the project, that might include:
- CMS or application updates
- Plugins or dependencies
- Theme or frontend dependencies
- Server packages
- Security patches
- Vulnerability reviews
- Access and permission reviews
Do not assume that “website maintenance” includes infrastructure maintenance unless the agreement says so.
Monitoring
A homepage returning HTTP 200 does not prove that an eCommerce store is functioning.
For revenue-generating sites, monitoring may also need to cover:
- Important category and product pages
- Cart
- Checkout
- Important APIs
- Error rates
- Payment or integration failures where they can be monitored
- Performance degradation
The appropriate checks depend on how the site is built.
Update and release process
Updates should have an appropriate route to production.
For some sites, that might be a simple backup followed by an update and functional check. For more complex projects, changes may first move through development, testing, or staging.
Ask:
- Where are updates tested?
- Who approves production changes?
- What is checked after release?
- Can the change be rolled back?
- Are risky releases avoided during major campaigns?
Performance monitoring
Maintenance does not need to include continuous performance optimisation, but it should be clear who notices when performance starts getting worse.
Useful monitoring might include page performance trends, slow application requests, error rates, server resource pressure, database behaviour, or Core Web Vitals depending on the architecture.
The plan should distinguish monitoring a performance problem from development work required to fix it.
Support and small changes
“Support included” needs a boundary.
Check:
- Which requests are included
- Whether the plan includes a set number of development hours
- Whether unused hours carry over
- How larger changes are estimated
- Which communication channel should be used
- What happens outside the included scope
Clear scope is better for both sides. The client knows what the monthly fee covers, and the maintenance team can prioritise incidents without every feature request being treated as an emergency.
For eCommerce, monitor the buying path
eCommerce maintenance needs to reflect how customers actually place an order.
A technically online store can still have a commercially serious incident if one part of that path breaks.
Cart and checkout
Check whether monitoring or routine testing covers the critical steps from adding a product to completing an order.
That can include shipping calculation, discounts, checkout, payment methods, confirmation pages, and downstream order creation.
Tracking
Tracking failures deserve their own checks because they can affect marketing decisions without preventing customers from ordering.
Depending on the implementation, maintenance might verify important events such as:
- add_to_cart
- begin_checkout
- purchase
- Advertising conversion tags
- Consent behaviour
This does not mean the maintenance provider needs to manage the advertising campaigns. It means somebody should know when the data those campaigns depend on has stopped being collected correctly.
Product data and feeds
Stores running Google Shopping, Meta catalogues, marketplaces, or other feeds should define who monitors feed errors and failed exports.
A feed problem can affect acquisition while the storefront itself continues working normally.
Third-party integrations
Payment gateways, couriers, ERPs, CRMs, email providers, search services, and other integrations introduce dependencies outside the main website.
The maintenance agreement should identify which of those systems the provider monitors and where its responsibility ends.
Three practical levels of maintenance
You do not need to use these exact package names, but they illustrate how risk should influence coverage.
| Basic coverage | Active eCommerce coverage | Business-critical coverage |
|---|---|---|
Usually suitable when:
|
Usually suitable when:
|
Usually suitable when:
|
The important difference is not the label. It is the level of risk each plan is designed to cover.
Compare specifics, not maintenance adjectives
Plan descriptions become useful when they contain details you can verify.
| A specific plan might say | A vague plan might say |
|---|---|
| Daily backups with documented retention | Regular backups |
| Restore testing performed on an agreed schedule | Your data is protected |
| Checkout and storefront availability monitoring | Website monitoring |
| Critical incidents acknowledged within the agreed response window | Fast support |
| Production updates tested in staging where required | Safe updates |
| Monthly report covering incidents, updates, backup status, risks, and next actions | Monthly maintenance |
The provider does not necessarily need to offer every item in the left column. The point is that you should know exactly what you are buying.
Maintenance plan red flags
Some gaps deserve a closer look before signing an agreement.
I Backups with no recovery process
Ask how restoration works, who performs it, what data is included, and whether you've tested the process.
II Response times with no severity definitions
A broken checkout and a request to change footer text should not enter the same queue with the same priority.
III “24/7 monitoring” with no escalation process
Automated monitoring has limited value if nobody is responsible for acting on the alert.
IV Unlimited support with undefined scope
Find out what “unlimited” actually covers. Development projects, redesigns, new integrations, and routine maintenance are different types of work.
V No release or rollback process
If updates are applied directly to production, ask what happens when one causes a regression.
VI No ownership map
You should know who is responsible for the application, infrastructure, DNS, domains, integrations, payment providers, analytics, backups, and other important services.
Otherwise, the first part of an incident can become a discussion about whose problem it is.
How we approach maintenance at Creative Brackets
We usually begin by understanding the current system and its business risk before deciding what ongoing coverage should look like.
Step 1: Understand the current risk
The initial review can cover areas such as:
- Current update process
- Backup and recovery readiness
- Monitoring gaps
- Performance problems
- Important eCommerce journeys
- Critical integrations
- Tracking reliability where relevant
This tells us which maintenance requirements are actually important for the project.
Step 2: Stabilise what needs attention first
There is little value in putting a recurring maintenance plan around known unresolved risks.
Where necessary, the first stage is therefore to address the fundamentals: monitoring, backups, update workflow, security issues, known errors, or other problems found during the review.
Step 3: Define the ongoing rhythm
After that, recurring work can be planned around what the website actually needs.
That may include scheduled updates, monitoring, small fixes, release checks, reporting, and recommendations when we identify a recurring issue.
The goal is not to create more maintenance work every month. It is to make responsibilities predictable.
What changes when the project uses ReadyCMS?
The same maintenance principles apply to ReadyCMS projects: define critical services, monitor the right journeys, test changes, plan recovery, and agree on incident responsibilities.
One useful architectural difference is that ReadyCMS supports separate development, testing, staging, and production environments through its Multi-environment manager.
Each environment is isolated with its own database, configuration, and API credentials. For projects using this setup, teams can test work outside production instead of making unfinished changes directly on the live environment.
That is useful for maintenance because it gives updates and fixes a clearer path toward production.
It does not remove the need for maintenance. Frontends, custom code, integrations, tracking, payment providers, and other project-specific services still need their own monitoring and change processes.
ReadyCMS also does not promise uninterrupted availability by default; specific service-level commitments depend on the applicable agreement. That is another reason to define the operational requirements of the actual project rather than assuming the platform name answers every maintenance question.
Buy the coverage your website can justify
The right maintenance plan is not necessarily the plan with the most hours, the fastest advertised response, or the longest checklist.
It is the one that matches the way your website operates.
If the site changes rarely and a few hours of downtime would have limited impact, simple coverage may be enough.
If the store processes revenue around the clock, depends on several integrations, and changes every week, monitoring, recovery, release management, and incident response become much more important.
Before choosing a plan, make sure you can answer:
- What are our critical services?
- What does the provider monitor?
- How are incidents classified?
- How fast will somebody respond?
- How much data could we lose?
- How would we restore it?
- How are changes tested?
- What is included in the monthly scope?
If the answers are clear, comparing plans becomes much easier.
Not sure what level of maintenance your site needs?
Creative Brackets can review the current setup, identify the areas with the highest operational risk, and recommend coverage based on the website rather than a generic package.
Because the cheapest plan is not always the least expensive one, and the biggest plan is not automatically the right one.
FAQ
1. How much does website maintenance cost?
There is no useful universal price because the scope can differ substantially. Cost usually depends on the complexity of the website, number of integrations, monitoring requirements, support coverage, response targets, update frequency, recovery requirements, and whether development time is included. Compare the deliverables before comparing monthly prices.
2. Do I still need maintenance if my store uses Shopify?
Shopify manages much of the underlying commerce platform and infrastructure, but that does not remove all project-level maintenance. Themes, custom code, third-party apps, tracking, feeds, integrations, and storefront changes still need attention. Shopify itself notes that third-party apps and theme customisations can create issues outside the core platform.
3. What is the difference between website support and maintenance?
Support usually starts with a request or incident: something happened and somebody needs help. Maintenance includes planned work intended to keep the system healthy, such as updates, monitoring, backup checks, release procedures, and recurring technical reviews. A maintenance agreement can include support, but the two are not identical.
4. How fast should a maintenance provider respond to an eCommerce outage?
The appropriate target depends on business impact and coverage hours. A store where checkout downtime quickly affects meaningful revenue may need immediate escalation, while a smaller site may accept business-hours response. More importantly, the agreement should distinguish response time from actual resolution time.
5. Is 24/7 monitoring the same as 24/7 support?
No. Monitoring means a system can check availability or errors continuously. Support means a person is available to respond. A plan can provide 24/7 monitoring while incidents are handled only during defined support hours, unless an escalation arrangement says otherwise.
6. How often should website backups run?
The frequency should reflect how much data the business can afford to lose. A mostly static site may not need the same backup interval as a store receiving orders throughout the day. The more important questions are what is backed up, how recent the recovery point needs to be, and whether restoration has been tested.
7. Do all updates need to be tested in staging?
Not necessarily. The process should match the change's risk. A complex checkout update deserves more testing than a low-risk content change. For projects with frequent development or important integrations, a separate staging or testing environment makes it easier to verify changes before production.
