SAP Application Support
SAP application support, often called AMS, is the ongoing operation of a live SAP estate: resolving incidents to agreed service levels, removing recurring causes, delivering small enhancements, and controlling transports into production. It begins where an implementation ends.
Keeping a live SAP estate dependable
Application support is the work that begins the day after go-live and continues for as long as the system runs. It covers incidents, the small changes that keep configuration aligned with a changing business, and the controlled movement of those changes into production.
Support is often measured only by response time. Response time describes how quickly someone replies, not whether the same issue returns next month. A support function that closes tickets quickly and never removes their causes becomes steadily more expensive while appearing to perform well.
OMAV runs support with problem management built in. Recurring incidents are traced to configuration, data or code, and the fix is scheduled rather than repeated. Volume is expected to fall, and it is reported against.
What support covers
Six areas, run to agreed service levels and reported monthly.
Incident resolution
Diagnosis and correction when something in SAP is not working, prioritised by business impact, with escalation paths agreed before they are needed.
Service requests
Authorisation changes, master data corrections, report variants, output configuration and the routine requests that keep users productive.
Problem management
Analysis of recurring incidents to find the underlying cause in configuration, data or custom code, and a scheduled fix so that the ticket stops returning.
Minor enhancements
Small changes that are too minor for a project and too real to ignore, delivered inside the support cycle with proper testing and transport control.
Transport and release control
Managed movement of changes through development, quality and production, with release windows and a rollback position for anything that touches finance or logistics.
Monitoring and period close
Watching background jobs, interfaces and failed IDocs, and providing extra capacity around month end, quarter end and year end when the cost of delay is highest.
How an engagement starts
Discover
Review of the estate, custom objects, interfaces and the last twelve months of tickets to establish where volume actually comes from.
Agree service levels
Priority definitions written in business terms, response and resolution targets attached, and reporting agreed before the first ticket is taken.
Transition
Documented walkthroughs, access provisioning and a shadowing period, so that knowledge moves deliberately rather than by accident.
Operate
Support runs to the agreed levels, with transports controlled and period close treated as a planned peak.
Reduce
Recurring causes removed and volume tracked downward, with the saved capacity redirected to enhancements the business asked for.
Support models next to each other
Common SAP support arrangements and what each suits.
| Dimension | In-house only | Fully outsourced | Shared model |
|---|---|---|---|
| Process knowledge | Strong | Built during transition | Retained in-house |
| Module depth | Limited by headcount | Broad | Broad where needed |
| Out-of-hours cover | Difficult | Included | Included |
| Cost profile | Fixed salaries | Contracted and predictable | Mixed |
| Key person risk | High | Low | Reduced |
| Best suited to | Small, stable estates | Lean IT functions | Organisations keeping process ownership |
What support cannot absorb
Support is not a substitute for a project. A new legal entity, a country rollout, a warehouse redesign or a version upgrade needs planning, testing and business time that a support agreement is not staffed to provide. Attempting them inside support capacity is how service levels quietly fail.
Support also cannot compensate for undocumented custom code indefinitely. Where a critical process depends on objects nobody can explain, every incident against them takes longer and carries more risk. Documenting or retiring that code is a piece of work with a beginning and an end, and it belongs on a plan.
- Service levels are only meaningful when priority definitions are written in business terms, not technical ones.
- Problem management is the part that reduces cost. Without it, support volume never falls.
- Period close needs support capacity planned around it rather than absorbed by it.
- Knowledge transfer at the start of an engagement determines the quality of support six months later.
Questions buyers ask about this
What does application support actually cover?
Incident resolution when something in SAP is not working, service requests such as authorisations and master data corrections, minor enhancements that are too small to be projects, transport and release management into production, and monitoring of interfaces and background jobs. Larger changes are handled as projects alongside, not inside, the support agreement.
How are priorities and response times set?
Priority is agreed in business terms. A stopped production line or a blocked payment run is a different order of urgency from a report that formats incorrectly, and the definitions should say so explicitly. Response and resolution targets are then attached to those priorities, measured, and reported. Definitions written only in technical terms produce disputes at the worst moment.
Can support work alongside our internal SAP team?
Yes, and it commonly does. A frequent arrangement is that internal staff hold process knowledge and business relationships while the support partner provides depth across modules, out-of-hours cover and surge capacity. What matters is that ownership boundaries are explicit, so that no ticket sits between two teams.
How is knowledge transferred at the start?
Through documented process walkthroughs, access to configuration and custom code, a review of the last six to twelve months of tickets, and a shadowing period alongside the outgoing team where one exists. Transition quality is the single largest determinant of how well support performs later.
Does support include upgrades and patches?
Routine patches, notes and support package application are normally in scope. Major upgrades and version changes are usually run as separate projects because they need planning, regression testing and business validation beyond day-to-day support capacity.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.