The notice period is a contract question
How much warning do we get before an SAP BTP service we have built on is withdrawn. That question comes out of steering meetings, and SAP's published platform documentation does not answer it. A full-text search across all 2,065 files in SAP's BTP documentation set returns zero hits for notice period, zero for end of maintenance, and zero for removed from the list of Eligible Cloud Services.
The number people repeat is six months. It traces to contract language in the BTP Enterprise Agreement and the Eligible Cloud Services List, and it reaches most readers through third-party sites rather than anything SAP publishes. A figure of twenty-four months turns up too, on one licensing consultancy site. Neither can be stated as SAP-documented policy.
That changes who owns the answer. The person who can tell your architecture board how much notice you are entitled to sits in procurement with a copy of the agreement, not on the platform team reading help pages. The commitment you can hold SAP to lives in a filed contract, which puts the question with whoever runs the renewal negotiation.
The cadence you can plan around
SAP describes BTP as a dynamic product with continuous production releases, and sorts those releases into three classes. Biweekly updates are the standard rhythm, and SAP describes them as aligned with its contractual obligations. Immediate updates cover urgent bug and security fixes. Major upgrades are the rare class, and SAP says they "happen rarely, in a bigger maintenance window, up to four times per year".
For those major upgrades SAP makes a specific commitment: "We let you know about these upgrades 4 weeks in advance." Four weeks of warning on something that happens at most four times a year is a rhythm most teams can absorb. It buys enough room to move a regression run, brief a business owner and freeze the week.
Finding the schedule is harder than finding the cadence. The What's New for SAP Business Technology Platform page is public, while the release schedules sit in SAP Notes 3430170, 3435435, 3459911 and 2888562, every one of which needs an SAP login. Cloud Foundry environment releases follow the regular biweekly cycle, and its release calendar sits behind another gated note. SAP's help portal, Discovery Center and Community pages all defeat automated retrieval, so everything confirmed here came from SAP's documentation repository and static knowledge base pages.
The three month promise is scoped to Kyma
There is a notice commitment in SAP's documentation and it is a good one. The wording reads: "For any changes that require user action, we notify users at least three months in advance in the 'What's New for SAP Business Technology Platform'." Three months of warning on work you are forced to do is a decent standard.
The catch is where that sentence lives. SAP documents it on a Kyma-scoped page rather than on a platform-wide policy page. Reading it across every subscribed service goes further than the source supports, and a risk register that records it that way will need correcting.
Use it for the runtime it covers and ask for the rest in writing. If the service holding up your integration layer sits outside Kyma, three months is an expectation rather than a documented promise, and the difference shows the first time a service team moves faster than your release calendar. Knowing what BTP actually is, a collection of separately owned services, makes the gap easier to accept.
Two channels and one change you cannot undo
The most useful piece of design here is the Kyma release channel split. There are two channels, regular and fast. A new module major or minor version is released first in the fast channel, and SAP's wording is that "After approximately two weeks, we promote the release to the regular channel." Release notes publish the same day in the fast channel with a Preview label, and the label comes off at promotion.
That two week gap is something you can buy. Put a non-production subaccount on the fast channel and module changes reach you a fortnight before the regular channel picks them up, which is enough time to run your own tests and open a ticket before production inherits the version. The price is the less settled build and another subaccount, so weigh it against the cost control conversation after the pilot. Hotfixes skip the timeline when a critical vulnerability needs closing.
One rule deserves its own line. Module versions can be upgraded but not downgraded. Whatever rollback plan you normally rely on does not apply, so the recovery path after a bad module version runs forward only. That pushes testing earlier by necessity, because the cheapest place to find the problem is the fast channel subaccount.
What the announced retirements actually show
The retirements SAP has announced say more about how it behaves than any policy page does. The Neo environment is the long-horizon example. SAP states that it "will sunset on December 31, 2028, subject to terms of customer or partner contracts." Years of lead time, a firm date, and a clause that hands the final answer back to your contract.
The SAP Application Logging Service shows a different shape. A knowledge base article says it "is scheduled to be removed from the list of Eligible Cloud Services as of July 30, 2025. It will be available until the end of the current subscription term. It will not be available for renewal terms that begin after the removal date." The mechanism there is renewal rather than shutdown, so the date that lands on your team is the start of your next term.
The cockpit warning on SAP Datasphere and SAP Analytics Cloud reads "This service will be deprecated on December 31, 2025. SAP strongly recommends that you use an alternative service that meets your business needs." SAP names SAP Business Data Cloud as the successor, existing tenants are preserved and no technical migration is required. The article carrying that guidance shows no publication date at all. Keep a retirement list with an owner beside each entry and the undated ones stop slipping out of view.
Dates that are predictions and dates that disagree
Kyma serverless function runtimes come with a published schedule. Node.js 20 shows deprecation in February 2026 and end of life in April 2026. Node.js 22 shows July 2026 and November 2026. Python 3.12 shows September 2026 and March 2027. Node.js 24 and Python 3.14 are listed as to be determined. SAP labels those dates as predictions based on current release cadence and subject to change, so they are not commitments. Lift them into a plan without the caveat and you will be explaining a slipped date you never controlled.
SAP Build Apps carries a genuine date conflict worth naming rather than resolving. March 23, 2026 is given for deprecation as a standalone product. September 30, 2026 is given for removal from the Eligible Cloud Services list. Neither could be independently verified and the two mean different things, so a plan quoting one of them as the answer is quoting half the story. If Build Apps sits in your estate, both dates belong in the same row of your register.
Get the agreement in front of someone who can read it
Two things are worth doing this quarter and the first one is not a platform task. Pull the BTP Enterprise Agreement and the Eligible Cloud Services List out of wherever procurement filed them, and have someone read the withdrawal and termination clauses with your subscribed service inventory open beside them. That is the only place a number you can hold SAP to is written down. The same habit covers reading a licensing change when one lands mid-term.
The second takes ten minutes. Subscribe to the What's New for SAP Business Technology Platform notifications and point the subscription at a distribution list rather than one person's mailbox, because the notice you care about will arrive during somebody's holiday. Pair it with a named owner for every subscribed service, the same inventory SAP's two maintenance calendars run on. Then ask your next architecture board who can say how much notice the contract owes you, and how long it would take them to find out.
