SAP has published the 2027 maintenance dates. Your support scope, SLA basis and exit terms are still yours to design.
Altivate | Published 6 November 20261. Why re-tender now
What SAP buyers should do before re-tendering
A re-tender is not a calendar exercise. It is a chance to fix three things that most SAP support contracts leave vague: what is in scope, how service is measured, and what happens when the relationship ends. A service-level agreement (SLA) is the written schedule of response and recovery commitments inside the contract. A request for proposal (RFP) is the tender document that asks bidders to price and evidence those commitments. If either document is weak, the buyer carries the risk. For this guide, AMS means the ongoing managed support of SAP applications after go-live: functional and technical incident resolution, change requests, small enhancements, and the service management around them. This paper does not re-explain the category. It focuses on the buying decisions that decide whether the service is measurable, priced for the right risk, and exitable. The 2027 clock is now explicit in SAP’s own statements. SAP says it will provide mainstream maintenance for SAP Business Suite 7 core applications until the end of 2027, with optional extended maintenance available for three years from the beginning of 2028 until the end of 2030. SAP’s October 2026 news statement repeats the 2027 mainstream date and the 2030 optional extended date. SAP also states that mainstream maintenance for SAP Solution Manager ends on 31 December 2027 and recommends completing the transition to SAP Cloud ALM before that date. Check your own contract and your own signed schedules before you build a business case on any date. What to do now:- Put the 2027 and 2030 dates into your contract calendar, then reconcile them with your own SAP schedule and any third-party support arrangements. Do not assume the provider’s contract term matches SAP’s lifecycle dates.
- Separate SAP Product Support from the managed service you are buying. SAP Product Support handles SAP product defects under SAP’s schedule. Your provider handles the application service around your processes, changes and users.
- Rewrite the SLA before you rewrite the price. Define the measurement basis, exclusions, coverage windows and reporting source. A bidder can meet a target and still fail the service if the target measures the wrong thing.
- Test the proposed SLA against your last 12 months of incidents. If you cannot replay your own history against the target, you cannot evaluate the bid.
- Make exit a scored requirement, not an appendix. Knowledge transfer, tooling ownership, ticket history export, access hand-back and step-in rights belong in the main contract.
- Treat the ALM tooling decision as part of the tender. Solution Manager 7.2 mainstream maintenance ends on 31 December 2027, and Cloud ALM ownership has contract consequences.
2. Scope map: what AMS covers vs SAP Product Support vs Basis/hosting
Key checks when defining AMS scope
Buyers often blur three layers. SAP Product Support is the vendor support entitlement for SAP products. AMS is the managed application service you contract from a provider. Basis is the SAP technical administration layer: installation, patching, database and operating-system administration, transports, job scheduling, interface runtime and monitoring. Hosting is where the systems run. The table below separates them, but read the labels carefully. SAP’s standard schedule (edition we reviewed, Singapore 2022); terms differ by country and contract, check your own signed schedule. The SAP Product Support column uses only the schedule facts we reviewed. The AMS and Basis/hosting columns are Altivate’s framing, not SAP-sourced. The Basis/hosting column is a negotiable checklist, not a statement of what any provider must include.| Scope area | SAP Product Support | AMS (Altivate framing, not SAP-sourced) | Basis/hosting (negotiable checklist, not a fact) |
|---|---|---|---|
| Defect and incident handling | SAP Enterprise Support provides explicit service-level agreements for the two top priorities. For “very high” cases, SAP will respond within one hour. For “high” cases, SAP provides an initial response within four hours. | Triage business-process incidents, reproduce issues, prepare SAP cases, coordinate with SAP, and manage workarounds inside the customer’s process. | Monitor system health, jobs, interfaces, database and operating system. Escalate infrastructure faults. |
| Priority and schedule detail | In the schedule edition reviewed, P1 response is within one hour, 24×7; P1 corrective action is within four hours, 24×7; P2 response is within four hours during SAP Local Office Time. | Define a customer priority matrix, service desk hours, escalation paths, and reporting. Reconcile provider priorities with SAP case priorities. | Define infrastructure severity, uptime measurement, maintenance windows and escalation. |
| Measurement basis | SAP meets its SLA if it reacts within the allowed time frames in ninety-five percent (95%) of the aggregate cases per calendar quarter. | Define whether the provider measures per priority, per queue, per month or per quarter; define aggregate versus priority-level reporting. | Define availability, backup success, job success, interface uptime and patch compliance measures. |
| Exclusions | The root cause behind the incident may be missing functionality (“development request”) or a consulting request, which is not a product defect. | Separate incidents from requests, small enhancements and projects. Put request classification and approval in the SLA. | Separate planned maintenance, capacity changes and project work from incident support. |
| Custom code | For Licensee custom code built with the SAP development workbench, SAP provides mission-critical support root-cause analysis. Other customer-specific solutions are excluded from P1 SLAs in the schedule we reviewed. | Provide code triage, debugging support and change control for customer-specific objects, subject to agreed scope. | Maintain transport paths, version control and technical documentation. |
| Customer contact | A suitably skilled English-speaking primary contact must be available 24 hours a day, 7 days a week for P1 cases. | Staff the service desk and escalation contacts. State who is reachable 24×7 and how handoffs work. | Provide on-call for infrastructure P1s, access to systems and vendor escalation. |
| Submission channel | In the schedule edition reviewed, incidents are submitted by the licensee in English via SAP Solution Manager. | Provide a service portal, email or phone channel, with ticket history and audit trail. | Provide monitoring tools, integration with the service desk, and access controls. |
3. Service models: staff augmentation, ticket-based, capacity-pool, outcome-linked
Choosing the right model for your SAP landscape
The service model sets who carries which risk. A named-person model gives you control and flexibility, but it also leaves volume risk with you. A ticket model gives you a unit price, but it can reward ticket volume. A capacity pool gives you a drawdown of hours or story points, but it needs disciplined demand management. An outcome-linked model ties fees or service credits to defined outcomes, but only works when the outcome is measurable and the baseline is trusted.| Model | What the buyer buys | Best fit | Contract lever | Main risk |
|---|---|---|---|---|
| Staff augmentation | Named people, usually billed by time and materials, directed by the customer. | Teams with clear internal direction and fluctuating demand. | Named CVs, replacement rights, timesheet approval, knowledge-transfer obligations. | The customer carries volume and productivity risk. |
| Ticket-based | A catalogue of ticket types with defined handling. | Stable run operations with predictable incident types. | Ticket taxonomy, priority definitions, exclusions, volume bands or review triggers. | Ticket volume can become the provider’s revenue driver. |
| Capacity-pool | A pre-paid pool of hours, story points or service units, drawn down against demand. | Mixed support and small-change demand with uncertain timing. | Drawdown rules, expiry, rollover, burn-rate reporting, change approval. | The pool can hide scope creep or run out before the contract year ends. |
| Outcome-linked | Fees or service credits tied to defined outcomes, not ticket counts. | Buyers with reliable measurement and a provider willing to share risk. | Outcome definition, baseline, attribution rules, service credits, exclusions. | Poorly defined outcomes create disputes. Use outcomes instead of support tickets when you design this model. |
| Landscape profile | Change volume | Start with | Avoid | Contract test |
|---|---|---|---|---|
| Small: one production SAP landscape, compact module footprint, a support team that knows most users by name. | Low and mostly small fixes or questions. | Ticket-based or a small capacity pool with named backup. | A large fixed team that is underused. | Can the provider scale down without a penalty? |
| Medium: multiple modules, interfaces, a mixed project and support backlog, separate business and IT queues. | Moderate, with seasonal peaks and a steady small-change backlog. | Capacity pool plus a service desk. | A pure ticket catalogue that treats every change as an incident. | Who classifies requests versus incidents, and how are disputes resolved? |
| Large: multi-country or multi-entity template, high interface count, separate run and change organisations. | High, with cross-functional changes and release dependencies. | Hybrid model: service desk plus capacity pool plus outcome-linked service credits for critical processes. | A single fixed fee with no volume or scope review. | Are baselines, reporting sources and exit data ownership defined? |
For most buyers, a hybrid approach is the practical answer. A ticket-based service desk can handle incidents, while a capacity pool supports small changes. Outcome-linked service credits should apply only to a limited number of critical outcomes that both parties can measure using the same data. However, avoid making the entire contract outcome-linked when the provider’s contribution cannot be reliably established.
4. An ILLUSTRATIVE SLA schedule
Coverage models and regional considerations
The table below is ILLUSTRATIVE. It is authored by Altivate for contract design. It is not an industry benchmark, not a market standard and not a recommendation to copy without testing against your own incident history. P1 is the highest priority. Use the ranges to ask bidders how they would define, measure and report each commitment.| Priority | Example trigger (Altivate illustration) | Response target range (illustrative) | Workaround target range (illustrative) | Resolution target range (illustrative) | Coverage assumption |
|---|---|---|---|---|---|
| P1 | Production process stopped or severely degraded, no acceptable workaround, critical business impact. | 15-30 minutes | 2-4 hours | 8-24 hours | 24×7 |
| P2 | Major function impaired, workaround exists but is costly or manual, multiple users affected. | 1-2 business hours | 4-8 business hours | 2-5 business days | Extended business hours or 24×7 by contract |
| P3 | Limited impact, single user or small group, workaround available. | 4-8 business hours | 2-3 business days | 5-10 business days | Business hours |
| P4 | Cosmetic issue, question, small request or documentation gap. | 1-2 business days | 5-10 business days for handling plan | Next scheduled release or 10-20 business days | Business hours |
| Coverage mode | Staffed window | P1 handling | P2-P4 handling | Contract test |
|---|---|---|---|---|
| Business hours | Each entity’s own working calendar, excluding public holidays unless bought. | Routed to on-call only if the contract buys on-call. | Handled next business hours. | Ask for the holiday calendar and the handoff rule between shifts. |
| Extended business hours | Defined early and late hours, plus agreed Saturday coverage if required. | On-call path with named escalation. | Same-day handling for P2 where possible. | Test the shift overlap and the escalation contact. |
| 24×7 | All hours, including weekends and public holidays. | Immediate triage and escalation. | Handled by priority and staffing model. | Test the 24×7 contact route and the language coverage. |
| GCC working week and Ramadan | Each legal entity’s own weekend and public-holiday calendar, plus a published Ramadan operating schedule per entity and site. | Unchanged: P1 cover does not shorten in Ramadan or on a local weekend. | Business-hours clocks run on the entity’s reduced Ramadan hours; state whether targets pause or the provider adds shifts. | Ask the bidder to show the same P2 ticket timed on a normal week and a Ramadan week for one KSA and one UAE entity. |
- UAE private sector normal working hours are limited to 8 hours per day or 48 hours per week. During Ramadan, working hours are reduced by 2 hours every day.
- KSA standard working hours are 8 hours per day or 48 hours per week. KSA Labor Law Article 98 caps Muslims’ Ramadan hours so they do not exceed 6 hours per day or 36 hours per week.
- The UAE federal government weekend has been Saturday and Sunday since 1 January 2022, while the Sharjah government sector’s official weekend is Friday to Sunday. One country, two government calendars: that is why the SLA must name each entity’s calendar.
- Ramadan 2027 dates are not asserted here. Require the provider to publish a Ramadan operating schedule for each legal entity and site, and to confirm it against the official calendar when announced.
How to Measure and Validate SLA Performance
What SAP’s own schedule teaches. SAP measures at 95% of aggregate cases per calendar quarter: “reacting within the allowed time frames in ninety-five percent (95%) of the aggregate cases”. That is a measurement-basis lesson, not a target to copy. If a provider reports one aggregate number across all priorities, strong P1 performance can hide weak P4 performance, and high P4 volume can dilute P1 misses. Specify whether the target applies per priority, per queue, per month or per quarter. In addition, identify the reporting source and establish how aged and paused tickets will be treated. The same SAP schedule excludes development and consulting requests from P1 SLAs: the root cause may be “missing functionality (‘development request’)” or a consulting request. Your AMS contract needs the same boundary. A missing report, a new approval step or a process redesign is not an incident. If the contract does not classify requests and incidents, the provider will either absorb them and price the risk, or reject them and create a service dispute. P1 also requires a customer contact reachable 24×7: “A suitably skilled English-speaking contact person (Primary Contact) who is available 24 hours a day, 7 days a week”. Someone must staff that contact. It can be the customer, a shared service centre or the provider. The contract must say who, how the handoff works and what happens if the contact cannot be reached. Worksheet: test the SLA against your last 12 months of incidents.- Export 12 months of incident and request data from your service desk, SAP case history and any regional queues.
- Normalise timestamps to one time zone and one business calendar per legal entity.
- Reassign each record to the proposed P1-P4 definitions using the written trigger examples, not the old queue.
- Mark records that are development requests, consulting requests, standard changes or cancelled tickets, and apply the proposed exclusions.
- Calculate response, workaround and resolution elapsed time in both clock hours and business hours.
- Compare the results with each bidder’s target ranges by priority, month and entity.
- Interview the owners of the top recurring incident types and confirm whether the root cause was application, interface, data, infrastructure or user process.
- Use the gaps to rewrite the SLA schedule, the reporting clause and the transition plan.
| Incident ID | Priority assigned | Start timestamp | First response timestamp | Workaround timestamp | Resolution timestamp | Elapsed business hours | Within target | Root cause category | Contract gap |
|---|---|---|---|---|---|---|---|---|---|
5. Pricing structures: fixed fee, time and materials, pre-paid pool, outcome-linked
Pricing is risk allocation. A low price with an unclear scope is not a low price. A fixed fee with no volume review is not a fixed risk. The table below describes the structures and the risks each one moves. It contains no price figures, no savings percentages and no day rates.| Structure | Who carries volume risk | Who carries quality risk | Who carries scope-creep risk | What to watch |
|---|---|---|---|---|
| Fixed fee | Provider, within the defined scope and volume assumptions. | Provider for the defined service levels, subject to exclusions. | Shared, but usually the customer through change requests. | Scope assumptions, volume bands, exclusions, annual review mechanism. |
| Time and materials | Customer. | Shared, because the customer directs the work. | Customer. | Timesheet approval, named resources, productivity reporting, knowledge transfer. |
| Pre-paid pool | Customer, until the pool is exhausted. | Provider for the work it accepts. | Customer, unless drawdown rules require approval. | Expiry, rollover, burn-rate reporting, demand approval, unused balance treatment. |
| Outcome-linked | Shared, depending on the baseline and attribution rules. | Shared, through service credits or fee adjustment. | Shared, if the outcome definition is narrow. | Baseline credibility, data ownership, attribution, exclusions, credit cap. |
When volume is difficult to forecast, a fixed fee does not eliminate uncertainty. Similarly, an outcome-linked model cannot prevent disputes without reliable quality measurements. Without effective demand governance, a capacity pool may eventually become little more than a prepaid queue.
6. RFP evaluation scorecard
The weights below are a suggested starting point. They sum to 100. Tune them to your priorities before you issue the RFP. Do not let a bidder self-score. Ask for evidence and check it.| Criterion | Suggested starting weight | What evidence to ask for |
|---|---|---|
| SAP functional and technical depth | 20 | Named solution architects and their module or technical certifications, sample incident triage method, approach to custom code and interface analysis. |
| SLA design and measurement | 15 | Draft priority matrix, reporting formula, sample monthly service report, exclusions, escalation model and aged-ticket treatment. |
| Transition and exit | 15 | Transition plan, knowledge-transfer method, runbook inventory, access hand-back process, ticket history export format and step-in terms. |
| ALM tooling ownership and Cloud ALM path | 10 | Tenant ownership model, admin roles, Solution Manager 7.2 transition plan, Cloud ALM use, Focused Run use where relevant, exit data hand-back. |
| AI and automation with evidence | 10 | Specific use cases, human review model, data boundaries, audit trail, and evidence of how the tool changes service outcomes rather than only ticket routing. |
| Price and risk allocation | 15 | Price schedule by service line, volume assumptions, rate card for out-of-scope work, pass-through costs, service-credit mechanics. |
| GCC coverage, language and Ramadan scheduling | 8 | Coverage calendar per entity, Arabic and English service routes, Ramadan operating schedule, public holiday handling, on-call roster. |
| Governance, security and reporting | 7 | Governance cadence, security controls, access review, data residency, incident communication, service review pack. |
7. Transition-in and exit checklist
Exit requirements and service continuity
Transition-in and exit are not administrative bookends. They determine whether the service is portable. Use the checklists below as contract schedules. Mark each item as mandatory, optional or excluded.| Transition-in item | What to require | Evidence | Acceptance test |
|---|---|---|---|
| Knowledge transfer | Named shadowing and reverse shadowing by process area, with session logs. | Knowledge-transfer plan with dates and owners. | Customer process owner signs off each critical process. |
| Runbooks | Current runbook for each critical process, interface, job and recurring incident. | Runbook inventory with version and owner. | Provider can execute a tabletop incident using the runbook. |
| Access and roles | Least-privilege access, named accounts, admin role ownership, revocation process. | Access matrix and role list. | Access review completed before go-live. |
| Tooling ownership | Tenant owner, admin holder, integrations, licence holder and support model. | Tooling schedule in the contract. | Customer confirms admin path and data access. |
| Ticket history import | Export format, field mapping, attachments, retention and reconciliation. | Sample export and mapping file. | Imported count and open-ticket status reconcile. |
| Service readiness | Priority matrix, escalation, reporting, cutover and hypercare. | Service management plan. | First service review held within the agreed cadence. |
| Exit item | What to require | Evidence | Acceptance test |
|---|---|---|---|
| Notice and step-in | Notice period, step-in rights, exit plan and cooperation duty. | Exit schedule signed at contract start. | Customer can trigger step-in without breaching the contract. |
| Knowledge transfer out | Documentation, shadowing, reverse shadowing and closing report. | Exit knowledge-transfer plan. | Incoming provider or internal team can run a tabletop P1. |
| Access hand-back | Revoke provider accounts, transfer admin, return tokens and devices. | Access revocation checklist. | Customer confirms no provider-only admin path remains. |
| Tooling ownership | Tenant admin, data ownership, integration ownership and licence transfer. | Tooling exit schedule. | Customer can access and export tenant data after exit. |
| Data and ticket history export | Full export, schema, attachments, retention and deletion. | Export specification. | Customer validates a sample export before final payment. |
| Runbooks and process assets | Updated runbooks, configuration documents and change calendar. | Asset register. | Asset register reconciled with contract scope. |
| Final reconciliation | Open tickets, credits, invoices and disputed items. | Final account statement. | Both parties sign the closure statement. |
8. ALM tooling dependency: Solution Manager, Cloud ALM and the exit clause
Cloud ALM ownership and contractual responsibilities
SAP states that mainstream maintenance for SAP Solution Manager ends on 31 December 2027 and recommends completing the transition to SAP Cloud ALM before that date. SAP’s June 2026 news statement uses the same date. Extended maintenance for Solution Manager 7.2 is tied to Business Suite 7 extended maintenance and covers only a subset of functions: SAP lists requirements management, project management, process management and test suite, followed by areas including change control, IT service management and landscape management. After the mainstream end date, SAP states that Solution Manager 7.2 will be supported beyond 2027 and 2030 in customer-specific maintenance, and SAP states that customers with on-premise SAP maintenance agreements retain the perpetual licence for Solution Manager. The harder contract question is Cloud ALM. SAP states that Cloud ALM is not prepared from a technical and legal perspective for AMS partner business and recommends Focused Run as the platform for AMS providers. SAP’s FAQ is explicit about the mechanism: “you can’t run multiple customers in a SAP Cloud ALM tenant owned by the AMS partner.” That is SAP’s statement about provider multi-customer hosting. It is not a statement that every customer must use Focused Run. Altivate’s reading, not SAP’s words: because the provider cannot pool customers in a Cloud ALM tenant it owns, the customer should own its Cloud ALM tenant. The contract should state who owns the tenant, who holds admin, which integrations the provider may use, and what tenant data and history are handed back at exit. The contract should also ask whether the provider’s own platform, such as Focused Run, holds customer history that leaves with the provider. If the answer is yes, the exit plan must include an export or transition path. Put these clauses in the RFP, not in the final negotiation:- Tenant ownership and admin: customer-owned tenant, named customer admin, provider admin only by time-bound role.
- Data ownership: customer owns incident, change, test and process data.
- Export rights: full export at any time and at exit, in a usable format.
- Integration boundary: which systems the provider may connect, and how those connections are removed.
- Transition path: Solution Manager 7.2 to Cloud ALM, or provider platform to customer tenant, with dates and responsibilities.
- Exit hand-back: admin revocation, data export, retention and deletion evidence.
9. ECC / Business Suite 7 2027 re-tender trigger
The SAP lifecycle facts below are the ones to put in your tender calendar. They are from SAP’s strategy page and SAP’s October 2026 news statement. Check your own contract and your installed enhancement package.| Date | SAP lifecycle fact | What it means for the RFP |
|---|---|---|
| Through 31 December 2027 | SAP will provide mainstream maintenance until the end of 2027 for SAP Business Suite 7 core applications. SAP’s October 2026 news statement repeats maintenance through 31 December 2027. | Your contract term must have a decision gate at or before the 2027 date. Do not let a multi-year term bury the decision. |
| Beginning 2028 to end 2030 | Optional extended maintenance is available for three years from the beginning of 2028 until the end of 2030. | Ask bidders to separate SAP extended-maintenance costs from provider fees and to show how the decision is handled. |
| Commitment coverage | The commitment includes the latest three enhancement packages of SAP ERP 6.0, as listed by SAP. | Confirm your installed enhancement package is in SAP’s commitment. Do not infer coverage for older enhancement packages from this paper. |
- Term length versus 2027. If the board has not chosen move or stay, tender a term with a 2027 decision gate, a defined extension mechanism and an exit without penalty at the gate.
- Extended-maintenance cost handling. Ask bidders to identify any SAP extended-maintenance cost as a pass-through with evidence. It is an SAP charge, not a provider service fee. Do not let it disappear into a fixed fee.
- Decision ownership. State that the customer decides whether to use optional extended maintenance. The provider supplies evidence, planning and transition options.
- Exit at the gate. Make the 2027 gate a pre-agreed exit point with knowledge transfer, data export and access hand-back obligations.
10. A 30-60-90 day plan to run the tender
Run the tender as a decision process, not a document production line. The first decision is whether the SAP landscape stays on Business Suite 7 through optional extended maintenance or moves. Use the SAP modernisation decision tree in the first workshop. If your team needs the plain-language explainer of what the service should cover, read what AMS covers in 2026. For sector-specific operating models, see SAP managed services operating model for oil and gas. For the ALM dependency, see Solution Manager to Cloud ALM before 2027.| Window | Actions | Output | Owner |
|---|---|---|---|
| Days 1-30 | Confirm the 2027 and 2030 dates against your own contracts. Export 12 months of incidents. Run the modernisation decision workshop. Agree the service scope and the decision gate. | Scope map, incident baseline, decision memo. | CIO or SAP CoE lead with procurement. |
| Days 31-60 | Draft the RFP using the scope map, SLA schedule, pricing table, scorecard and exit checklist. Define the reporting source. Hold bidder clarifications. | Issued RFP and clarification log. | Procurement with SAP CoE. |
| Days 61-90 | Score written responses. Run incident walkthroughs. Negotiate SLA, pricing and exit schedules. Confirm ALM tenant ownership. Take the award and 2027 gate to the board. | Evaluation report, negotiated contract schedule, board decision. | CIO, procurement and legal. |
Before issuing the RFP, confirm that historical incidents can be evaluated against the proposed priority definitions. Next, establish which services are included, optional or excluded before assessing pricing. Finally, make sure the ALM clause clearly defines tenant ownership and exit arrangements before signing.
11. Closing next step
Download the RFP scorecard (CSV), then book an AMS scoping call. Altivate is an SAP Gold Partner. Bring your current contract, your last 12 months of incident data and your 2027 decision date. We will use them to test the scope map, the SLA measurement basis and the exit terms against the service you are about to tender.Sources and verification status
Checked 4 November 2026. SAP Help Portal and SAP support pages carry different publication and edition dates. Where SAP documents a behaviour for a specific edition or country, the qualifier is kept. The scope-map AMS and Basis/hosting columns, the illustrative SLA ranges, the pricing risk table, the scorecard weights, the transition and exit checklists and the 30-60-90 plan are Altivate’s synthesis, not SAP guidance. The contract-design reasoning about Cloud ALM tenant ownership is Altivate’s reading, not SAP’s words.- SAP, SAP strategy and maintenance commitments. Checked 4 November 2026. Used for mainstream maintenance through end 2027, optional extended maintenance 2028-2030, the latest three enhancement packages including SAP ERP 6.0. Quote fragments used: “mainstream maintenance until the end of 2027”; “three years from the beginning of 2028 until the end of 2030”; “including the latest three enhancement packages”.
- SAP News, Beyond 2030: SAP Business Suite 7, SAP NetWeaver, customers, third-party databases, Java. Checked 4 November 2026. Used for the repeat of 31 December 2027 mainstream maintenance and 31 December 2030 optional extended maintenance. Quote fragments used: “mainstream maintenance remains available through December 31, 2027”; “optional extended maintenance through December 31, 2030”.
- SAP, Transition to SAP Cloud ALM. Checked 4 November 2026. Used for the Solution Manager mainstream end date and SAP’s recommendation to complete the Cloud ALM transition before that date. Quote fragment used: “Mainstream maintenance for SAP Solution Manager ends on December 31st, 2027.”
- SAP News, Navigating the transition to SAP Cloud ALM. Checked 4 November 2026. Used for the same Solution Manager date. Quote fragment used: “end of mainstream maintenance for SAP Solution Manager on December 31, 2027”.
- SAP, SAP Solution Manager. Checked 4 November 2026. Used for the extended-maintenance subset. Quote fragment used: “Extended maintenance only includes requirements management, project management, process management, test suite”.
- SAP, SAP Solution Manager FAQ. Checked 4 November 2026. Used for customer-specific maintenance and the Cloud ALM and Focused Run statements. Quote fragments used: “customer specific maintenance”; “retain the perpetual license for SAP Solution Manager”; “you can’t run multiple customers in a SAP Cloud ALM tenant owned by the AMS partner”; “SAP Cloud ALM isn’t prepared from technical as well as legal perspective for AMS partner business”; “Our clear recommendation is SAP Focused Run as platform for AMS providers.”
- SAP, Mission-critical support. Checked 4 November 2026. Used for explicit SLAs and the Very High and High response commitments. Quote fragments used: “explicit service-level agreements”; “respond within one hour”; “initial response within four hours”.
- SAP, SAP Enterprise Support Schedule, Singapore English v8-2022. Checked 4 November 2026. Used for P1 and P2 schedule detail, the 95% aggregate measurement basis, P1 exclusions, custom-code root-cause analysis and English submission via Solution Manager. Quote fragments used: “within one (1) hour of SAP’s receipt (twenty-four hours a day, seven days a week)”; “within four (4) hours of SAP’s receipt during SAP’s Local Office Time”; “ninety-five percent (95%) of the aggregate cases”; “missing functionality (“development request”)”; “SAP development workbench”. Edition and country caveat: this is the Singapore 2022 edition we reviewed; terms differ by country and contract.
- SAP Support Portal help, Creating a case. Checked 4 November 2026. Used for the 24×7 primary-contact requirement. Quote fragment used: “available 24 hours a day, 7 days a week”.
- UAE, Working hours in the private sector. Checked 4 November 2026. Used for the 8 hours per day or 48 hours per week limit and the Ramadan reduction. Quote fragments used: “8 hours per day or 48 hours per week”; “reduced by 2 hours, every day”.
- UAE, Working hours in the public sector. Checked 4 November 2026. Used for the federal government weekend and the Sharjah government weekend. Quote fragments used: “Saturdays and Sundays are the official weekends for the federal government sector.”; “Official weekend in Sharjah is for three days: Friday, Saturday and Sunday.” (listed under the Sharjah government sector).
- KSA Human Resources and Social Development, Labor Law Article 98. Checked 4 November 2026. Used for Ramadan hours and standard working hours. Quote fragments used: “do not exceed (6) hours per day, or (36) hours per week”; “more than (8) hours per day”; “more than (48) hours per week”.
