Questions to ask before you cancel SAP support

A proposal to move Sybase off SAP vendor support usually leads with the saving. The saving is real, but it covers only one side of the decision, and the other side tends to surface later, during an incident, an audit or a regulatory review, when there is least time to deal with it. Before anything is cancelled, these five questions should be answered in writing. They apply to every provider, including us. Our answers come from an SAP-backed contractual model, which is why they will not match those of an independent provider with no SAP backing.

1. Which Sybase systems are critical, and what is their tolerance for downtime?

Not every Sybase database carries the same risk, and a single support decision across the estate hides that difference. A reporting replica can wait for a fix; the database behind a payments platform cannot. The answer should list each system, the business function it supports, its recovery objectives and the cost of an outage, because every other question depends on it. The systems with the least tolerance for downtime are the ones where losing a route to an engine-level fix costs most, which is why they are the strongest case for keeping vendor backing in place.

2. For a defect inside the engine, who can actually fix it, and how fast?

The answer should name who owns the incident in the middle of the night, how quickly they respond, and at what point the product’s own engineers get involved. An independent provider can offer advice or a workaround for an engine defect, but only SAP can deliver a corrected product. Under Insight, tdglobal’s 24/7 team responds to P1 incidents in under seven minutes, owns each one from start to finish and escalates to SAP through the back-to-back arrangement when the engine itself is at fault.

3. How will we identify new vulnerabilities, and how will we obtain and apply an authorised fix if SAP patch access has ended?

Once SAP maintenance ends, new corrective code stops arriving. Public vulnerability information remains available and compensating controls can reduce exposure, but neither closes the vulnerability. The answer has to name where a fix will come from and what rights allow it to be applied. Under Insight, SAP security notes, patches and emergency bug fixes continue to arrive through SAP’s own release process, so the question of rights does not arise.

4. How is our actual usage reported and covered contractually, what SAP backing is in place, and what obligations remain if there is an audit?

Licence obligations and audit exposure do not end when support changes. The way the estate is deployed, virtualised and grown still has to match its entitlement, and a vendor audit can arrive at any point. The answer should explain how usage is measured and reported, which contract covers it and who carries the risk if usage and entitlement diverge. With Insight, the SAP back-to-back arrangement provides contractual protection for the agreed, accurately reported usage. The client still needs to report its usage correctly, and SAP audit rights remain applicable.

5. What does our regulator expect for these systems, and have compliance signed off on the plan?

For a regulated firm, a support change alters the asset register, the risk assessment, the third-party register and potentially the contract terms a regulator expects to see. The answer should come from the compliance team, in writing, before the change is made. Under Insight, compliance has one answer for every system: SAP-backed through the back-to-back arrangement, with a named route for escalation.

If any of these answers is still “we’ll find out later”, reach out to the Insight team to work through all five against your own estate.

‍