Adobe Experience Manager (AEM) is an enterprise platform, and keeping it reliable after launch requires more than simply hosting the application. This is where AEM managed services come into the picture. Managed services can cover infrastructure operations, monitoring, backups, upgrades, patches, incident management, technical support, and other operational responsibilities depending on the contract.

However, one of the biggest mistakes enterprises make is assuming that every activity performed by an AEM support team is automatically covered by the Service Level Agreement (SLA).

The reality is more nuanced.

An AEM SLA typically defines measurable commitments such as availability, support response targets, service coverage, and operational responsibilities. Custom development, new features, major migrations, content authoring, and application enhancements may fall outside the base SLA and require separate services.

This guide explains what organizations should actually look for when evaluating Adobe Experience Manager support, including availability, monitoring, incident response, maintenance, backups, upgrades, and AEM managed services cost.

What Are AEM Managed Services?

AEM managed services are operational and support services designed to help organizations run Adobe Experience Manager without managing every infrastructure and platform responsibility internally.

Depending on the agreement, managed services can include:

  • Infrastructure management
  • AEM environment monitoring
  • 24/7 support and monitoring
  • Patching and upgrades
  • Backup and restore
  • Disaster recovery
  • Incident management
  • Performance monitoring
  • Security and operational maintenance
  • Deployment assistance
  • Technical support
  • Go-live and upgrade support
  • Best-practice guidance

Adobe's published AEM Managed Services product description has historically included 24/7 user support and monitoring, patches and upgrades, backup, restore and disaster recovery, onboarding, and other operational services within its service tiers.

However, enterprises should always verify their specific contract rather than assuming these services are included in every package.

Important: AEM Managed Services vs AEM as a Cloud Service

The terminology can become confusing because Adobe has offered AEM through different deployment models.

Traditional AEM Managed Services was associated with managed AEM 6.5 environments where Adobe handled significant infrastructure and operational responsibilities.

AEM as a Cloud Service is a newer cloud-native architecture with Cloud Manager, automated deployment processes, scaling capabilities, monitoring, and guided updates. Adobe explicitly distinguishes AEM as a Cloud Service from earlier on-premise and Managed Services deployments.

This distinction matters when reviewing an SLA.

Adobe's current roadmap states that support for AEM 6.5 Managed Services customers ended by August 31, 2026, while AEM 6.5 LTS continues under the applicable support paths.

Therefore, organizations evaluating an AEM managed services contract today should first establish whether they are discussing legacy AEM Managed Services, AEM as a Cloud Service, or a third-party managed support arrangement around AEM.

What Is Usually Covered by an AEM SLA?

An SLA is not simply a promise that "AEM will work." It normally defines measurable service commitments.

Here are the major areas to examine.

1. Availability and Uptime

Availability is usually one of the most important SLA metrics.

For AEM as a Cloud Service, Adobe provides SLA reporting through Cloud Manager. The reporting tracks production Author and Publish tiers and compares actual performance against the contracted SLA.

Current AEM Cloud Service production programs can have different SLA options. Adobe documentation states that Sites and Forms offer a standard 99.9% SLA, while a 99.99% SLA option is available when the applicable requirements are met.

That difference is significant.

For example:

SLAApprox. maximum downtime per 30-day month
99.0%7.2 hours
99.9%43.2 minutes
99.99%4.3 minutes

These figures illustrate why enterprises should pay attention to the exact SLA percentage rather than simply asking whether the vendor provides "high availability."

2. Monitoring

Monitoring is another major component of managed AEM operations.

Adobe states that AEM as a Cloud Service uses extensive cloud-native monitoring across infrastructure, services, and user experience. Production availability monitoring can contribute to SLA calculations and trigger Adobe's on-call processes when an availability issue is detected.

A managed-service contract may therefore cover monitoring of:

  • Author environments
  • Publish environments
  • Dispatcher
  • Application availability
  • Infrastructure health
  • Replication
  • Storage
  • Performance indicators
  • Service failures

But monitoring your platform does not necessarily mean that every custom application problem is automatically fixed under the base contract.

That distinction should be clearly documented.

3. Incident Management and Support Response

Your AEM SLA should define what happens when something breaks.

A strong SLA should specify:

  • Priority levels
  • What qualifies as a critical incident
  • Initial response time
  • Escalation process
  • Support hours
  • Communication frequency
  • Resolution targets, if applicable
  • Customer responsibilities
  • Vendor responsibilities

Adobe's current support documentation, for example, defines different initial-response targets based on support level and priority. Enterprise and Elite support plans provide faster response targets for critical issues than standard online support.

This is an important distinction:

Response time is not necessarily resolution time.

If your contract says P1 incidents receive a 30-minute response, it does not automatically mean the issue will be completely fixed within 30 minutes.

Enterprises should therefore look for separate definitions of response, workaround, restoration, and resolution.

4. Patching and Upgrades

AEM requires ongoing maintenance.

Managed services may include:

  • Security patches
  • Platform updates
  • Service packs
  • Maintenance activities
  • Upgrade planning
  • Upgrade execution
  • Regression testing support

Adobe's AEM Managed Services product documentation lists patches and upgrades among service-tier capabilities.

However, there is a crucial difference between maintaining the platform and upgrading a heavily customized implementation.

For example:

Usually operational:

Apply an approved platform patch according to the supported maintenance process.

Potentially additional project work:

Refactor 40 custom components because a major platform upgrade breaks compatibility.

That distinction can have a major impact on your support budget.

5. Backup, Restore and Disaster Recovery

Backup and disaster recovery should be explicitly addressed in the SLA.

Questions to ask include:

  • How frequently are backups taken?
  • How long are backups retained?
  • Which environments are backed up?
  • Are databases and assets included?
  • Who initiates restoration?
  • What is the Recovery Point Objective (RPO)?
  • What is the Recovery Time Objective (RTO)?
  • Is disaster recovery testing included?
  • Are restoration activities chargeable?

Adobe's AEM Managed Services documentation identifies backup, restore, and disaster recovery among its managed-service capabilities.

Do not assume that "backup included" means "unlimited disaster recovery."

The contract should define exactly what happens during a serious outage.

6. Performance Monitoring

AEM support may also involve application and infrastructure performance.

Typical areas include:

  • Page response time
  • Publish performance
  • Dispatcher performance
  • Replication delays
  • Storage utilization
  • Application errors
  • Traffic patterns
  • Resource consumption

Cloud Manager and AEM provide monitoring capabilities for production environments. Adobe's documentation includes metrics such as replication-agent performance and Dispatcher flush activity within environment monitoring.

However, performance optimization caused by inefficient custom code may fall outside routine managed operations.

For example, fixing a poorly designed custom servlet could be development work rather than standard infrastructure support.

7. Security and Operational Maintenance

Security responsibilities should also be clearly defined.

Depending on the arrangement, managed services may cover platform-level maintenance and security updates, while the customer remains responsible for areas such as:

  • Application code
  • Custom integrations
  • User permissions
  • Content governance
  • Business configuration
  • Third-party applications
  • API credentials
  • Security policies

This is why an SLA should contain a clear responsibility matrix.

A simple RACI matrix can prevent many disputes:

ActivityManaged Service ProviderCustomer
Infrastructure monitoringResponsibleInformed
Platform patchingResponsibleConsulted
Custom code changesUsually Customer/ProjectResponsible
Content publishingUsually CustomerResponsible
Incident responseResponsibleConsulted
User accessSharedResponsible
Backup operationsResponsibleInformed
Business requirementsConsultedResponsible

The exact responsibility split depends on the contract.

What Is Usually NOT Included?

This is where organizations often discover unexpected costs.

An AEM managed services contract may not automatically include:

  • New website development
  • New AEM components
  • Major UX redesigns
  • Content migration
  • Large-scale refactoring
  • New third-party integrations
  • Marketing campaign creation
  • SEO implementation
  • Custom application development
  • Major architecture changes
  • Extensive performance engineering
  • Large-scale cloud migration projects

These activities are often treated as professional services or separate project work.

For example, if your AEM website suddenly needs a new personalization engine, that is not necessarily an "incident."

It is a development project.

Understanding AEM Managed Services Cost

AEM managed services cost varies considerably because enterprise contracts are usually influenced by factors such as:

  • Number of environments
  • Production architecture
  • Traffic
  • Availability requirements
  • Support tier
  • Number of applications
  • Custom integrations
  • Geographic coverage
  • Monitoring requirements
  • Disaster recovery requirements
  • Development and maintenance scope
  • Number of support users
  • SLA requirements

There is no reliable universal price tag for AEM managed services.

Instead of comparing vendors purely on monthly price, organizations should compare the cost of coverage.

For example:

Cost AreaQuestion to Ask
Platform supportIs AEM platform support included?
MonitoringIs 24/7 monitoring included?
Incident responseWhat are P1/P2 response targets?
MaintenanceAre patches and upgrades included?
BackupWhat backup frequency and retention apply?
DRIs disaster recovery included?
DevelopmentAre custom code fixes included?
EnhancementsAre new features charged separately?
ReportingAre SLA reports and service reviews included?
Technical resourcesIs a named engineer included?

This produces a much more realistic picture of the total cost.

What Should You Look for in an AEM SLA?

Before signing an AEM support agreement, ask for specific answers to these questions:

  1. What uptime percentage is guaranteed?
  2. Does the SLA cover Author, Publish, Dispatcher, or all three?
  3. What happens during a P1 incident?
  4. What is the initial response time?
  5. Is 24/7 support included?
  6. Are patches and upgrades included?
  7. Are backups included?
  8. What are the RPO and RTO?
  9. Who handles disaster recovery?
  10. Are custom-code defects covered?
  11. Are performance issues covered?
  12. Are third-party integrations covered?
  13. What activities are billed separately?
  14. Are service reviews included?
  15. Is a named technical contact provided?
  16. What happens when the SLA is missed?

The final question is particularly important.

A real SLA should explain the remedy when service commitments are not met, such as service credits or other contractual remedies where applicable.

Adobe Experience Manager Support: SLA vs Support Plan

Another important distinction is between an SLA and a support plan.

An SLA generally defines measurable service commitments, such as availability.

A support plan can define access to technical assistance, escalation, service reviews, named engineers, and response targets.

Adobe's support documentation describes Enterprise Support as providing enhanced service-level targets, technical expertise, a Named Support Engineer, escalation management, service reviews, and other services.

Therefore, an enterprise should not evaluate AEM support by looking at uptime alone.

A strong support model combines:

Availability + Monitoring + Incident Response + Maintenance + Recovery + Technical Expertise

Final Checklist for Evaluating AEM Managed Services

Before signing or renewing an AEM managed-services agreement, make sure the SLA clearly documents:

  •  Guaranteed uptime
  • Covered environments
  • Support hours
  • P1/P2/P3/P4 definitions
  • Initial response targets
  • Escalation procedure
  • Monitoring responsibilities
  • Patch responsibilities
  • Upgrade responsibilities
  • Backup frequency
  • Backup retention
  • RPO and RTO
  • Disaster recovery responsibilities
  • Performance monitoring
  • Security responsibilities
  • Custom-code support
  • Third-party integration support
  • Out-of-scope activities
  • Additional development rates
  • SLA reporting
  • Service credits or contractual remedies

Final Takeaway

AEM managed services are much more than keeping an AEM server online. A well-designed service agreement can cover monitoring, incident response, maintenance, patches, upgrades, backups, disaster recovery, and technical support, but the exact scope depends on the product, support tier, and contract.

The biggest lesson is simple: never evaluate an AEM SLA using the uptime percentage alone.

Look at the entire operational model. Understand who monitors the environment, who responds to incidents, who performs upgrades, who owns backups, who fixes custom code, and which activities become additional project costs.

For organizations moving toward AEM as a Cloud Service, the distinction is even more important because Adobe's cloud-native model changes how infrastructure, deployment, monitoring, scaling, and operations are handled.

A good AEM SLA should leave very little room for the dreaded enterprise phrase: "That's not included in the contract."