Many organisations still run Oracle E-Business Suite (EBS) as their core ERP. Oracle continues to offer Premier Support for EBS 12.2 and reviews the end date each year. So for many teams the question is not whether to keep EBS running, but how to run it well with fewer in-house staff.
Application managed services (AMS) is the usual answer. A provider takes on day-to-day support, patching and small changes under a contract. This guide covers how to set that up and run it: contract scope, service levels, pricing, transition and governance. It does not cover how to shortlist a provider.
What an EBS AMS contract should cover
Write the scope as a list of services, not a list of modules. For each service, state who does it, how often and what "done" means.
Incident management
Users report something broken. The provider logs it, sets a priority, restores service and closes the ticket. Agree the hours of cover and the channels: portal, email, phone.
Problem management
Incidents that repeat point to a root cause. The provider should find it and fix it, not just close tickets. Ask for a monthly list of open problems with an owner and target date.
Change and enhancement requests
Small changes include new reports, personalisations, value set changes and workflow tweaks. Set a size limit, for example a number of hours per request. Anything larger becomes a project with its own estimate.
Patching and Critical Patch Updates
Oracle releases Critical Patch Updates (CPUs) on the third Tuesday of January, April, July and October. It can also issue Security Alerts between those dates for fixes that cannot wait. Oracle publishes an EBS-specific CPU document each quarter and advises customers to apply CPU patches promptly after checking prerequisites. The contract should say who reviews each CPU, who tests it and how many weeks after release it goes to production.
EBS 12.2 online patching cycles
EBS 12.2 uses online patching through the adop utility. It keeps two application file systems: a run file system that users work on and a patch file system that receives patches. A cycle runs through prepare, apply, finalize, cutover and cleanup. Only cutover needs a short outage. The contract should name who runs each phase, who approves the cutover window and who handles an abort if a cycle fails.
Period-close support
Month-end, quarter-end and year-end are when EBS matters most. Agree extended cover on close days, named contacts and a freeze on non-urgent changes.
DBA, OCI and on-premises infrastructure boundaries
This is where most disputes start. Decide who owns the database, the operating system, backups, cloning, storage and network. If EBS runs on Oracle Cloud Infrastructure (OCI), state whether the AMS provider or a separate cloud team manages the tenancy. If it runs on-premises, state who deals with your hardware or hosting supplier.
An example service level framework
The table below is an example to help you start a discussion. It is not a standard, and it is not an Egisedge commitment. Set your own figures based on business impact and budget.
| Priority | Example definition | Example response | Example resolution or workaround |
|---|---|---|---|
| P1 Critical | Production down or close blocked for many users | 30 minutes | 4 hours |
| P2 High | Key process degraded, workaround hard | 2 hours | 1 business day |
| P3 Medium | Single user or non-urgent process affected | 1 business day | 5 business days |
| P4 Low | Question, cosmetic issue or minor request | 2 business days | Agreed in backlog review |
Define when the clock starts and stops. Agree whether time waiting for Oracle Support or for the user counts. Measure resolution and workaround separately.
Pricing models compared
| Model | How it works | Suits | Watch out for |
|---|---|---|---|
| Fixed capacity | A set number of hours or people each month | Steady ticket volume and a regular change backlog | Unused hours, and unclear rules for carrying them forward |
| Time and materials | Pay for hours used at agreed rates | Short-term cover, uncertain scope, early months after go-live | Costs are hard to forecast, little incentive to reduce tickets |
| Ticket-based | A price per ticket, often by priority or type | Mature estates with stable, well-classified tickets | Arguments over ticket type, and tickets split to raise count |
Many contracts mix models: fixed capacity for run support, with a separate rate card for enhancements.
Knowledge transition in eight steps
- Collect documents. Gather the module list, customisation inventory, integration list, patch history, runbooks and open tickets.
- Hold walkthroughs. Business and IT owners explain each process, especially period close and key interfaces.
- Review the technical estate. Check environments, cloning steps, the adop history and outstanding CPUs.
- Shadow. The new provider watches the current team handle live tickets.
- Reverse shadow. The new provider handles tickets while the current team watches and corrects.
- Sign off readiness. Agree exit criteria: documents updated, access granted, runbooks tested.
- Stabilise. Run a period with relaxed service levels and close daily contact.
- Apply full service levels. Move to the agreed SLAs and start formal monthly reporting.
Plan the first period close and the first CPU cycle inside the stabilisation period. Both test the new team quickly.
Governance: monthly reviews and KPIs
Hold a monthly service review with a fixed agenda. Track a small set of measures:
- SLA performance by priority
- Ticket backlog size and backlog age
- Repeat incidents and open problem records
- CPU status: released, tested, applied
- Enhancement delivery against estimate
- Close-day incidents
- User satisfaction from short ticket surveys
Look at trends, not single months. Backlog age and repeat incidents tell you more than ticket counts. Hold a quarterly review with senior sponsors to agree priorities and contract changes.
Contract checklist
- Services listed with owner, frequency and definition of done
- Hours of cover, including close days and public holidays
- Priority definitions and SLA clock rules
- CPU review, test and apply window agreed
- 12.2 online patching roles, including cutover approval and abort
- DBA, OS, OCI or on-premises ownership written down
- Enhancement size limit and approval route
- Pricing model, rate card and carry-forward rules
- Knowledge transition plan and exit criteria
- Monthly KPIs and reporting format agreed
- Access, data protection and audit requirements
- Exit and handover terms for the end of the contract
Using AMS to prepare for a later Fusion move
AMS can make a future move to Oracle Fusion Cloud ERP easier. Ask the provider to keep the customisation and integration inventories current. Retire unused reports and customisations as tickets show they are no longer needed. Clean master data steadily, not in a rush before migration. Record which processes cause the most tickets, as these are candidates for redesign. If you move in phases, EBS and Fusion can run side by side, so your AMS scope may need to cover coexistence. See our EBS to Fusion migration checklist and Oracle's coexistence reference architecture.
How Egisedge helps
Egisedge Technologies is an Oracle Partner, founded in 2019, with offices in India. Our directors bring 20+ and 16+ years of hands-on Oracle EBS and Fusion experience in finance and supply chain. We have delivered multiple Oracle projects, and we help EBS customers plan the move to Fusion, rebuild integrations on Oracle Integration Cloud and test with structured playbooks. Our teams deliver offshore across GCC, UK/Europe, US and Australia/NZ working hours.
Useful starting points are our EBS AMS transition and governance playbook, Oracle's Critical Patch Updates and Security Alerts page and our system integration testing playbook.
Want to talk through your EBS support model or a later move to Fusion? Email info@egisedge.com.
Frequently asked questions
What should an Oracle EBS AMS contract cover?
At minimum: incident and problem management, small changes and enhancements, patching including the quarterly Critical Patch Updates, 12.2 online patching cycles, period-close support and a clear line between application support and DBA or infrastructure work.
How often does Oracle release Critical Patch Updates for EBS?
Oracle releases Critical Patch Updates four times a year, on the third Tuesday of January, April, July and October. It can also issue Security Alerts between those dates for urgent fixes.
Which AMS pricing model is best for Oracle EBS?
It depends on how stable your ticket volume is. Fixed capacity suits steady, predictable demand. Time and materials suits short or uncertain work. Ticket-based pricing suits mature estates with well-understood ticket types.
How long should knowledge transition to a new EBS AMS provider take?
Plan for several weeks, not days. Allow time for document review, shadowing, reverse shadowing and a stabilisation period before full service levels apply. The exact length depends on the number of modules, customisations and integrations.
Talk to Egisedge about Support
Tell us where you are and we'll reply within one working day with next steps.