SAP AMS transition: switch partners without disruption
A practical SAP AMS transition guide for manufacturers: fix-or-switch signs, exit clauses, RFP, pricing, shadow phases and a one-page checklist.
Changing your SAP support vendor can hold up invoicing, dispatch or month-end close if it goes wrong. The outgoing team holds years of fixes that were never written down, and the incoming team does not yet know your month-end. The risk sits in that gap, more than in the new vendor's skills.
This SAP AMS transition guide is for IT heads, CFOs and procurement teams at manufacturers on ECC or S/4HANA. It covers whether to fix or switch your SAP support partner and what to secure before going to market. It then covers how to select a new SAP AMS provider and run the handover, ending with a one-page checklist.
A note on interest: LogicMotive provides SAP AMS and support, so we bid for this work. Everything below works whichever vendor you choose, including your current one.
Fix or switch: read your ticket data first
Switch when the problem is the vendor's operating model. Fix when it is the contract, the scope or your own processes. Switching costs management time, a period of paying two vendors, and weeks where support depends on a team still learning your system.
The clearest warning sign is green SLA reports alongside unhappy users. Many AMS contracts measure response and closure, not whether the fault went away. ITIL treats problem management as a practice of its own, aimed at reducing the likelihood and impact of incidents by identifying their actual and potential causes. If nobody does it, closure numbers look fine while the same faults return every month-end.
Use your own ticket export, not the vendor's summary.
- SLAs met, users unhappy. Check in your data: Reopen rate; tickets closed for "no user response"; repeat incidents. Fixable if: Vendor adds resolution and reopen measures, and they improve. Points to a switch if: Vendor resists measuring resolution, or nothing moves
- Rising backlog. Check in your data: Open tickets by age and module, month on month. Fixable if: Rise ties to a known event, with a clearing plan. Points to a switch if: Growth without cause; old tickets re-prioritised to stay inside SLA
- Consultant churn. Check in your data: Names in the proposal against names on tickets. Fixable if: One-off exits, replaced with a proper handover. Points to a switch if: Repeated churn, junior replacements, your users doing the briefing
- Everything becomes a change request. Check in your data: Change requests per incident; estimates on routine fixes. Fixable if: Scope wording is unclear and can be amended. Points to a switch if: In-scope fixes keep returning as paid change requests
- No root-cause work. Check in your data: Problem records opened and closed. Fixable if: Vendor starts monthly problem reviews. Points to a switch if: No problem records, same incidents every close
- Knowledge in one head. Check in your data: Documentation by module; who fixes P1s. Fixable if: The documentation gap can be scheduled. Points to a switch if: One absence means an outage; vendor will not document
For illustration, take a typical ₹600 Cr auto-components maker where one interface failure closes within SLA every month-end but never gets a problem record. Only a change in how the vendor works fixes that.
Before you go to market
Pull your own data
Get the data out while the relationship still works; it drives the decision, the RFP and the handover.
- Ticket export, 12 to 24 months, covering a full financial year: module, priority, category, dates, reopen flag, assignee and linked change request.
- SLA reports as the vendor reported them. Recalculate a sample from raw tickets.
- Change-request register: count, estimate against actual, approved and rejected.
- Custom objects: names start with Y or Z unless a registered prefix namespace is used, so the list is easy to pull.
- Interfaces: RFC destinations in transaction SM59, plus IDoc and file interfaces, middleware, e-invoicing connectors, banks and plant systems.
- Batch jobs from the Job Overview (SM37), with the user ID each job runs under.
- Access list: every dialog, technical, RFC and emergency ID the vendor uses.
- Documentation: what exists, where, and who owns the tool it sits in.
Check the exit terms in your current contract
Read the exit clauses before you tell the vendor anything. These are questions for your legal team, not legal advice.
For a model of thorough exit terms, see the UK government's Model Services Contract. Its exit schedule covers an exit plan agreed early, services continued during the exit period and a parallel run. It also requires handover of problem records and work volumes for the previous 12 months.
- Notice. How much notice, from which date, and is there a fee for terminating for convenience?
- Transition assistance. Must the vendor keep meeting SLAs during notice, deliver knowledge transfer and support a parallel run? At what charge?
- Documentation. Which documents (specifications, runbooks, knowledge base, ticket history), in what format, by when?
- Ownership of custom code. Under the Copyright Act, 1957, computer programmes are literary works (Section 2(o)). The author, or the author's employer, is generally the first owner (Section 17), and an assignment is valid only if it is in writing and signed (Section 19(1)). For code your AMS vendor's staff wrote, that employer is usually the vendor, not you. Does our contract assign code and documentation to us in writing?
- Access. Must the vendor list and hand over every ID, technical password and tool account, and confirm deletion of our data?
- Knowledge-transfer hours. How many, from which named people, and can they be substituted?
- Non-solicitation. Does a clause stop us or the new vendor from hiring a consultant who holds critical knowledge?
Selecting the new SAP AMS provider
What to put in the RFP
Give bidders your real data so they price your workload, not a guess.
- Ticket profile: monthly volumes by module and priority, showing month-end and year-end peaks.
- Systems: ECC or S/4HANA release, clients, add-ons, interfaces and non-SAP systems. On ECC with enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027; on EHP 5 or lower it ended on 31 December 2025. Ask how bidders fit your SAP support strategy before 2027.
- Coverage: hours in IST, plant shifts, weekend month-end work and P1 on-call.
- Module mix: for example FI/CO, MM, SD, PP, QM and PM, plus ABAP, Basis and security.
- Processes: incident, problem, change and knowledge management, with sample monthly reports.
- Tools: the ITSM tool, who owns it, and how ticket data returns to you at exit.
- Transition: plan, team, exit criteria and the bidder's own exit terms.
Pricing models and their trade-offs
- Time and materials. How you pay: Hours at agreed rates. Works when: Volumes are unpredictable and you want control. Watch for: No built-in reason to reduce tickets
- Fixed monthly fee with ticket bands. How you pay: Fixed fee per ticket band, plus overage rates. Works when: Your ticket profile is stable and known. Watch for: Band definitions, ticket splitting, what counts as a change request
- Dedicated team. How you pay: Monthly fee for named consultants. Works when: Steady demand in core modules; continuity matters. Watch for: Substitution, leave cover, no view of utilisation
- Outcome-based. How you pay: Part of the fee tied to results such as backlog age. Works when: You have clean baseline data and trusted measures. Watch for: Gamed measures; risk priced into the fee
The UK government's Sourcing Playbook is written for public buyers, but two of its points apply here. Time and materials suits a buyer that wants control over how work is done. Fixed prices should be avoided where scope is not fixed.
Comparing bids fairly
- Price one scenario. Give every bidder the same 12-month ticket profile and ask for total annual cost, including expected change requests.
- Read SLA definitions side by side: response or resolution, business or calendar hours, clock-stop rules, priority definitions.
- Separate transition cost from run cost, so a cheap run price cannot hide a costly handover.
- Ask for named people, their allocation and substitution rules.
- List exclusions: enhancements, upgrades, SAP Note implementation, Basis, security, non-SAP interfaces.
Reference checks
Ask for a client that switched to the bidder from another vendor. Ask how knowledge transfer went, whether the bid team turned up, and how a month-end P1 was handled.
The transition plan, phase by phase
Run the SAP AMS transition on exit criteria, not calendar dates. Each phase ends when your module owners sign off its criteria.
- 1. Planning. What happens: Transition managers named on both sides; knowledge-transfer plan by module; access requested; dates checked. Exit criteria (examples): Signed plan with named owners; access approved through your normal process
- 2. Knowledge transfer. What happens: Recorded sessions by module and interface; gaps logged. Exit criteria (examples): Documentation signed off; runbooks for month-end, quarter-end and GST filing dates; interfaces and jobs checked in SM59 and SM37
- 3. Shadow support. What happens: Outgoing team works live tickets; incoming team observes. Exit criteria (examples): Agreed ticket types observed, including one month-end close
- 4. Reverse shadow. What happens: Incoming team works live tickets; outgoing team backs up. Exit criteria (examples): Agreed tickets resolved without escalation, including a month-end close; open issues closed or accepted
- 5. Steady state and hypercare. What happens: Incoming team owns support, with daily check-ins. Exit criteria (examples): SLAs met for an agreed period; backlog stable; old vendor IDs removed
Keep the outgoing vendor contracted until reverse shadow passes, so you have a fallback if it fails. At least one AMS vendor describes reverse shadow support as optional; make it mandatory in your plan. The Sourcing Playbook likewise recommends an exit plan that links the outgoing supplier's exit to the incoming supplier's mobilisation, and terms that keep the incumbent motivated until the end.
Dates to keep clear
Do not start reverse shadow, or let the outgoing team step back, during:
- Financial year-end close and the statutory audit fieldwork after it.
- Quarter-end close, and the results window if you are listed.
- GST return dates. Monthly filers file GSTR-1 by the 11th of the following month and GSTR-3B by the 20th. Invoice and tax-code issues surface in the days before each. Check the GST portal for extensions.
- Planned plant shutdowns, when maintenance and stores activity run high.
- Internal audit or ITGC testing visits, and any go-live, upgrade or support-pack import.
Governance and controls during the handover
Support changes hands; control ownership does not. Auditors test the whole year, so controls must run without a gap.
Access hand-off
- Start from the access list you pulled earlier, including firefighter IDs.
- Lock IDs on the agreed date rather than deleting them; transaction SU10 locks users in bulk. Check SM37 first for jobs running under those IDs and move them.
- Change passwords on technical users and on RFC destinations that store logon data, if the outgoing team knew them.
- With SAP Access Control, reassign firefighter ID owners and controllers, and have the controller review the Consolidated Log Report for handover sessions. With a manual process, someone on your side reviews every emergency session.
- Give the incoming team access through your normal approval process.
Transport and change freeze
- Agree a freeze window around the step-back date: emergency changes only, approved by your change owner.
- SAP's documentation recommends closing the import queue in STMS before an import so late requests are not imported by accident.
- List open transport requests owned by outgoing vendor users. Release, reassign or delete each, and record the decision.
Keep ITGC evidence continuous
A support vendor runs change management day to day, but the controls are yours, and our SAP ITGC and audit trail checklist covers them. For the handover, the point is continuity: approvals, transport logs and reviews carry on without a gap, with evidence in your systems, not a vendor's mailbox.
Own the knowledge base
Keep runbooks, the knowledge base and ticket history in a tool you own; export history from the old vendor's tool before notice ends.
Where AMS transitions go wrong
- SAP support knowledge transfer as slide decks. Transfer on live tickets and tested runbooks.
- The key person leaves early. Name them in the exit terms until reverse shadow ends.
- Cutover lands in close week. Check the business calendar during planning.
- The bid team is not the delivery team. Name consultants in the contract.
- Old access left open. Give every ID an owner and a removal date.
- SLA penalties from day one. Agree a stabilisation period, but measure from the start.
- Scope gaps at the edges. Middleware, EDI, e-invoicing connectors and plant systems fall between vendors unless the RFP lists them.
One-page SAP AMS transition checklist
Decide
- Tickets analysed by module, priority, age and reopen rate
- Fix-or-switch decision recorded
Current contract
- Notice period, fee and date confirmed
- Transition assistance and named knowledge-transfer people confirmed
- Documentation, ticket history, access and code ownership checked with legal
Selection
- RFP covers tickets, systems, IST coverage, modules, processes and tools
- Bids priced on one scenario; SLA definitions compared
- Named team in the contract; references called
Transition
- Exit criteria signed by module owners
- Runbooks for month-end, quarter-end and GST dates
- Reverse shadow covers a month-end close; outgoing vendor retained until it passes
- Dates checked against close, GST, audit and shutdowns
Controls
- Old IDs locked; jobs moved; passwords changed; firefighter logs reviewed
- Transport freeze and open-request decisions recorded
- ITGC evidence and knowledge base held in your systems
Frequently asked questions
How long does an SAP AMS transition take?
It depends on the number of modules, interfaces and custom objects, and on how much documentation exists. Plan by exit criteria rather than a fixed number of weeks, and make sure reverse shadow covers at least one month-end close.
Should we keep paying the outgoing vendor during the transition?
In most cases, yes. Those fees buy knowledge transfer, the shadow period and a fallback if reverse shadow fails. Check what your contract already obliges the vendor to do during notice before negotiating extras.
What should an SAP AMS SLA measure?
Response and resolution times by priority are the minimum. Add reopen rate, backlog age, repeat incidents and problem records closed with a root cause, so the SLA rewards fixing causes, not only closing tickets. Define IST support hours and clock-stop rules in writing.
Can we switch AMS vendors during an S/4HANA move or upgrade?
You can, but it adds risk, because the outgoing team holds knowledge the project needs. Either keep the outgoing vendor on project support until go-live and move run support first, or wait until hypercare ends.
Who should own SAP support documentation?
Your company should. Keep specifications, runbooks, the knowledge base and ticket history in tools you own, and put ownership of documentation and custom code in writing in the contract.
Get an AMS health check
An AMS health check is an independent review of how your SAP is supported today: ticket data and SLAs, backlog, documentation, and the change, access, logging and backup practices that auditors test as ITGCs. You get a written view of what to fix and whether to fix the current arrangement or go to market. If you decide to switch, the same findings feed your RFP and exit plan.
What you provide: a ticket export (ideally 12 months), your current contract and SLA schedule, an overview of your SAP systems and interfaces, and your last audit observations where relevant.
Sources
- ITIL 4 Practitioner: Problem Management, PeopleCert, peoplecert.org (accessed Oct 2026)
- Names of Repository Objects, ABAP Keyword Documentation 7.50, SAP Help Portal, help.sap.com (accessed Oct 2026)
- Displaying, Maintaining, and Testing Destinations (SM59), SAP Help Portal, help.sap.com (accessed Oct 2026)
- Managing Jobs from the Job Overview (SM37), SAP Help Portal, help.sap.com (accessed Oct 2026)
- The Model Services Contract: Combined Schedules (England & Wales) v2.2A, Schedule 21 (Exit Management) and Annex 1, Cabinet Office and Government Legal Department, GOV.UK, gov.uk (accessed Oct 2026)
- The Copyright Act, 1957 (Sections 2(o), 17 and 19), Copyright Office, Government of India, copyright.gov.in (accessed Oct 2026)
- Maintenance Timelines for SAP ERP 6.0 (ECC), SAP Community (blog post by SAP), community.sap.com (accessed Oct 2026)
- SAP Extends Its Innovation Commitment for SAP S/4HANA, Provides Clarity and Choice on SAP Business Suite 7, SAP News (4 Feb 2020), news.sap.com (accessed Oct 2026)
- The Sourcing Playbook (sections on payment mechanisms and on expiry, extension, transition and termination), Government Commercial Function, GOV.UK, gov.uk (accessed Oct 2026)
- Four Key Phases of SAP Application Management Services (vendor blog), Accely, accely.com (accessed Oct 2026)
- Notification No. 83/2020 – Central Tax (GSTR-1 due dates), CBIC, hosted by the GST Council, gstcouncil.gov.in (accessed Oct 2026)
- Rule 61, Central Goods and Services Tax Rules, 2017 (GSTR-3B due dates), CBIC Tax Information Portal, taxinformation.cbic.gov.in (accessed Oct 2026)
- Mass Changes (SU10), SAP Help Portal, help.sap.com (accessed Oct 2026)
- User Guide, SAP Access Control 12.0 SP31 (Emergency Access Management), SAP SE, help.sap.com (accessed Oct 2026)
- Starting the Import of All Requests in an Import Queue (STMS), SAP Help Portal, help.sap.com (accessed Oct 2026)
