The core moves on a plan and BTP does not
SAP hands you two maintenance rhythms and most teams staff only one. The core runs on a schedule you can put on a calendar a year ahead: an annual S/4HANA release, feature package stacks on top, support package stacks through the year, and SAP Notes landing continuously underneath. BTP has no such schedule. The services in your subaccounts change when their service teams ship, and you tend to find out because an integration flow behaved differently on a Tuesday.
Last spring I sat through a four hour maintenance planning meeting at a chemicals manufacturer on S/4HANA private edition. Eleven people, one basis lead holding a note list north of a thousand entries, and four module owners who had never opened it. The meeting produced a window date in November and nothing else, so the reading happened the week before the window, by one person, at speed.
What I run instead starts with a split of the reading and ends with a record that outlives the people who did the reading. Setting it up costs about three hours. Each cycle after that costs well under an hour.
Split the reading by consequence, not by note category
The split that works is not the one printed in the note header. Basis gets everything whose worst outcome is a system that will not start. Functional owners get everything whose worst outcome is a number that comes out different. Kernel patches, database and operating system prerequisites, and the stack update itself sit with basis. A change to how a pricing condition resolves or a tax code posts sits with whoever owns that process, by name.
That second half needs names, not a distribution list. On the last cycle I ran, the functional list went to four people: the controller who owns period close, the order to cash lead, the procurement manager, and the developer who owns the custom output determination nobody wants to touch. One deadline, set two weeks before the window opens.
A third pile catches people out. Anything touching custom code or a modification goes to the extension owner, because a stack that corrects standard behavior can change what a modification was quietly compensating for. I watched a corrected rounding routine collide with a Z include that had been fixing the same rounding since 2014, and the pair moved eleven cents onto nine thousand documents. That collision is why the clean core decision comes first.
Three note categories earn a human decision
Notes with a manual activity are the first category. If a note carries a pre-implementation or post-implementation step, somebody has to perform it, confirm it, and say what breaks when it gets skipped. These never batch. Each gets a name and a test case before the window is approved, and a manual step with no owner is a reason to hold the note.
Consulting notes that change a recommended behavior are the second, and they get filed under background reading more often than anything else. A note saying a standard calculation now resolves differently is a decision with a business owner, even when nothing is transported. Choosing not to apply it and writing down why beats finding the note during an audit.
Security notes are the third, and they follow their own order. The severity printed on the note is the vendor's rating of the flaw, not your exposure to it, so I sort by what an unauthenticated user can already reach before anything else. That is the same ordering I use for a bulletin where everything claims top severity.
Everything else batches, and the batch is most of the list. Notes for components you never installed. Notes for a database or operating system you do not run. Corrections already contained in the target stack. On that chemicals cycle, 1,140 candidate notes came down to 38 that needed a name beside them, and 9 changed a configuration value someone could see in a transaction.
Write the behavior register while you still remember why
Every cycle produces a short set of behavior changes and a long set of skipped items, and both belong somewhere that is not a chat thread. I keep six columns: note number or stack level, component, one sentence on what changed, who decided, the test that covered it, and the production date. It lives beside the transport record, because that is where the next person looks.
The reason is February. Finance says the credit check started blocking orders it used to release, and the question arrives as what changed. Without the register, answering means two days of reading transport logs and guessing which stack carried it. With it, the answer is a note number, a date, an owner, and the test somebody ran.
The skipped list earns its keep too. When a consultant proposes a note next year that was already reviewed and rejected, the register names who rejected it and why, and the conversation takes ten minutes. The same record habit carries across any vendor whose notes arrive faster than anyone can read them, and it matters more once support has changed hands after go live.
BTP moves while your window is still being planned
The core plan covers none of the platform services, and pretending otherwise is where estates get caught. Integration Suite, HANA Cloud, and whatever else sits in your subaccounts update on their own schedules. No window you approved, and no stack level that describes what you are running today.
Start with a subscription inventory, because most estates cannot produce one. Every subscribed service in every subaccount, with a named owner and one line on which business process stops if the service does. The estates I review carry somewhere between eight and sixteen subscribed services and can confidently name an owner for two or three. The rest belong to whoever set them up.
Then run a thirty minute review every month against that inventory only, never the whole catalogue. Deprecation announcements carry real dates and belong in the same register as the core items, with an owner and a target month. An adapter version going out of support is a project with a deadline, and it will never appear on a stack plan.
The seam between the two calendars is where I put the testing effort. After a core stack update, and after any change to an integration service, run the same short set of end to end checks. A purchase order through to a posted invoice. A master data record created on one side and read correctly on the other. Same five checks every time, same two people running them. For that to mean anything the interfaces have to be small enough to test, which is the argument for narrow integration contracts.
What to bring to the next maintenance planning meeting
Three things get decided in that meeting and none require opening a system. The names first, meaning which basis person and which functional owners read which part, with a deadline two weeks ahead of the window. Then where the register lives, agreed out loud so nobody starts a second one in a personal spreadsheet. Then who owns each BTP subscription, which takes longest because it exposes how many have nobody.
The cost deserves saying out loud. Reading properly runs to roughly eight person hours per cycle across five people, and skipping it costs a multiple of that the first time a behavior change reaches period close undiagnosed. If you need to argue the time upward, the budget framing around clean core is the version finance accepts.
Before the next window gets approved, ask one question around the table. Who can say, without opening a system, which support package stack changed the way the credit check behaved last year. The length of the pause tells you whether the register starts this cycle or after the next incident.
