Чем upgrade релиза отличается от update FPS/SPS, какие проверки нужны On-Premise и Private Edition, и как подготовить регрессию к управляемому обновлению Public Edition.
6 мин чтения·База знаний
Ревизия 1Сравнение контекстовЧастичное покрытиеКонтекст: CTX-S4-ONPREMКонтекст: CTX-S4-PRIVATEКонтекст: CTX-S4-PUBLICдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Обновление S/4HANA между продуктовыми релизами меняет не только номер версии: могут измениться бизнес-функции, объекты, данные, код, роли и эксплуатационные процедуры. Для качественного перехода нужно совместить план поставки и технических работ с проверками бизнес-процессов. Сначала зафиксируйте редакцию, исходный и целевой релизы, установленный стек и владельца работ.
В документации SAP переход, например, с одного продуктового релиза S/4HANA на следующий называется upgrade. Установка более высокого Feature Package Stack (FPS) или Support Package Stack (SPS) в пределах того же релиза называется update. Для On-Premise и Private Edition релизное обновление обычно требует более глубокой подготовки и тестирования, чем update стека. Конкретный объём всё равно определяйте по целевому релизу и изменениям, которые использует система.
Public Edition обновляется по графику поставки SAP. Клиент не выполняет программный upgrade через SUM и не выбирает собственную дату установки релиза. Команда готовится к опубликованным датам, проверяет тестовый tenant и решает, какие затронутые процессы и расширения требуют регрессии.
On-Premise и Private Edition: сначала техническая совместимость#
Для технического обновления SAP S/4HANA используйте руководство именно целевого релиза и редакции. SAP Upgrade Guide 2025 для On-Premise и отдельное руководство Private Edition задают шаги и требования своего контекста; не заменяйте их инструкцией от другого релиза.
В типовом маршруте подготовки:
Зафиксируйте поддерживаемые исходный и целевой релизы, платформенные требования, компоненты, add-ons и бизнес-функции.
Запустите SAP Readiness Check заранее, чтобы собрать проектные вопросы и ориентировочные проверки. Это обзор готовности, а не разрешение начинать переключение.
Проверьте систему через Maintenance Planner: совместимость компонентов и add-ons и формирование stack file для Software Update Manager (SUM). Конкретное применение зависит от целевого сценария и руководства.
Выполните Simplification Item-Check. В руководстве upgrade SAP он обязателен для технического процесса; его полезно запускать заранее, потому что некоторые сообщения требуют подготовительных работ до окна перехода.
Проанализируйте пользовательский ABAP-код с инструментами custom code migration/ATC по упрощениям целевого релиза. Разделите ошибки, требующие исправления, и находки, которые нужно оценить по фактическому использованию.
Сверьте SAP Notes, ограничения и release-specific шаги. Сформируйте план обновления, репетиции, заморозки изменений и поддержки после переключения.
Для Private Edition заранее согласуйте с оператором среды сроки, доступы, ответственность за инфраструктурные и SAP-операции, остановки, резервное копирование и восстановление. Наличие SUM или доступа к системе само по себе не доказывает, что конкретная команда может менять production по своему графику.
Public Edition: готовьтесь к окну тестирования и переносу контента#
В документации Public Edition 2608 SAP начинает поставку крупного релиза с обновления тестовой системы. Это даёт время проверить обновлённое ПО, существующую конфигурацию и developer extensibility перед последующими обновлениями других систем. Проверьте текущий Upgrade & Maintenance Schedule и информацию целевого релиза: календарь может меняться.
Сопоставьте актуальные What's New сведения с включённым и используемым scope. SAP Release Assessment and Scope Dependency (RASD) помогает отфильтровать релевантные изменения. В тестовом tenant выполните собственные регрессионные проверки. SAP Post-Upgrade Tests дают стандартные smoke tests и позволяют добавлять пользовательские процессы; один зелёный автоматизированный smoke test не доказывает корректность всех финансовых потоков.
Проверьте и план переноса конфигурации и разработки. В период, когда test уже на новом релизе, а development и production ещё на предыдущем, порядок импорта и допустимость отдельных типов transport зависят от состояния релизов и объектов. SAP отдельно предупреждает о зависимости следующего software upgrade от своевременного переноса обновлённого reference content во все системы. Сверяйте transport dependencies и инструкции конкретного релиза, не импортируйте пакет только потому, что он прошёл в другом ландшафте.
Для 2- и 3-системного ландшафта проверяйте соответствующие процедуры. Состав конфигурационной среды, тестовых tenants, developer extensibility и управления reference content различается. Если работает партнёр или управляемая служба, назначьте владельца каждой проверке и точке решения.
Регрессия должна следовать за финансовыми последствиями#
До начала перехода определите критичные end-to-end процессы и контрольные результаты. Для финансовой области могут потребоваться:
проводки разных типов, сторно и межфирменные операции;
закрытие периода, оценка, валютные пересчёты и распределения;
платежи и банковские выписки;
расчёты по основным средствам и управленческому учёту;
внешние интерфейсы, отчёты и извлечение данных в хранилища;
роли, формы, задания, пользовательские расширения и фоновые цепочки.
Сценарии и ожидаемые результаты должны отражать используемый scope и фактическую конфигурацию. Сравните контрольные итоги и выборки документов до и после обновления: суммы, валюты, ledger, периоды, статусы, связи исходного документа и результирующего объекта. Проверьте логи и очередь ошибок интеграций. Не используйте один технический health-check вместо функциональной регрессии.
Зафиксируйте тестовые данные, версию программ, конфигурацию, известные расхождения, владельцев проверки и критерии допуска. Если данные до перехода были изолированы, убедитесь, что тест после обновления всё ещё сравним и покрывает актуальные варианты процесса.
Upgrade меняет системное ПО и может требовать обновления данных, кода и конфигурации. Не считайте его простым действием с гарантированной кнопкой отмены. До рабочего окна согласуйте с владельцами систем и оператором проверяемую стратегию восстановления или продолжения обслуживания, условия принятия решения, необходимые резервные копии и проверку их пригодности. Срок и способ возврата зависят от выбранной архитектуры, точки фиксации и договорных обязанностей.
Сохраняйте прежние рабочие материалы как контекст, но отделяйте их от инструкций для целевого релиза. Храните ссылки и версию старой процедуры, отмечайте, какие пункты были перепроверены, заменены или сняты. Повторно используйте бизнес-сценарий и критерии, когда они всё ещё актуальны; технический шаг, роль, Fiori app, IMG path или API переносите только после проверки в новой версии.
S4-13 частично покрыт этим обзором. Руководства upgrade On-Premise и Private Edition относятся к SAP S/4HANA 2025; документация Public Edition относится к версии 2608. Источники зарегистрированы как metadata_only; клиентские релизы, инструменты, код, тесты, production-переход и восстановление не проверялись и не выполнялись.
An S/4HANA release upgrade changes more than a version number: business features, objects, data, code, roles, and operating procedures can change. A sound transition combines the delivery and technical plan with business-process validation. First record the edition, source and target releases, installed stack, and owners.
Distinguish a release upgrade from a stack update#
SAP calls a move from one S/4HANA product release to a higher release an upgrade. Installing a higher Feature Package Stack (FPS) or Support Package Stack (SPS) within the same release is an update. A release upgrade for On-Premise and Private Edition normally needs more preparation and testing than a stack update. Determine the actual scope from the target release and the changes used by your system.
Public Edition is updated on SAP's delivery schedule. Customers do not run a software upgrade using SUM or choose their own installation date. The team prepares for published dates, checks the test tenant, and decides which affected processes and extensions require regression tests.
On-Premise and Private Edition: establish technical compatibility first#
Use the upgrade guide for the target S/4HANA release and edition. SAP publishes separate 2025 guides for On-Premise and Private Edition; do not replace them with instructions for another release.
A typical preparation route includes:
Record the supported start and target releases, platform requirements, components, add-ons, and business functions.
Run SAP Readiness Check early to collect project questions and indicative checks. It is a readiness overview, not permission to start the cutover.
Check the system with Maintenance Planner for component and add-on compatibility and to create the stack file used by Software Update Manager (SUM). Follow the target scenario guide for exact applicability.
Run the Simplification Item-Check. SAP's upgrade guide makes it mandatory for the technical process; running it early helps identify preparation tasks before the change window.
Analyze customer ABAP code with custom code migration and ATC tools against target-release simplifications. Separate issues requiring correction from findings that need assessment based on actual usage.
Review SAP Notes, restrictions, and target-release-specific steps. Plan the upgrade, rehearsal, change freeze, and post-transition support.
For Private Edition, agree with the environment operator on timing, access, responsibilities for infrastructure and SAP operations, outages, backups, and recovery. Availability of SUM or system access does not by itself mean that a particular team can change production on its own schedule.
Public Edition: prepare for test and content delivery#
In SAP S/4HANA Cloud Public Edition 2608 documentation, SAP starts a major release with an update to the test system. This gives the team time to check upgraded software, existing configuration, and developer extensibility before subsequent system updates. Check the current Upgrade and Maintenance Schedule and target-release information because dates can change.
Compare current What's New information with the scope that is activated and used. SAP Release Assessment and Scope Dependency (RASD) helps filter relevant changes. Run your own regression checks in the test tenant. SAP Post-Upgrade Tests provide standard smoke tests and allow customer-defined processes; one green automated smoke test does not prove every finance flow works correctly.
Check the plan for configuration and development transports too. While test runs on the new release and development and production remain on the previous release, import sequence and eligibility depend on release state and object type. SAP also warns that the next software upgrade depends on timely distribution of upgraded reference content to all systems. Check transport dependencies and the target-release instructions; do not import a package merely because it worked in another landscape.
Confirm procedures for the two-system or three-system landscape. Configuration tools, test tenants, developer extensibility, and reference-content management differ. If a partner or managed service is involved, assign an owner to every check and decision point.
Before the transition, select critical end-to-end processes and control outcomes. Finance scenarios may include:
Different types of postings, reversals, and intercompany transactions.
Period close, valuation, currency conversion, and allocations.
Payments and bank statements.
Asset accounting and management accounting calculations.
External interfaces, reports, and data extraction to warehouses.
Roles, forms, jobs, customer extensions, and background chains.
Base scenarios and expected results on the scope and configuration actually used. Compare control totals and document samples before and after the upgrade: amounts, currencies, ledgers, periods, statuses, source-document links, and resulting objects. Check integration logs and error queues. Do not use a technical health check as a substitute for functional regression.
Record test data, program versions, configuration, known differences, test owners, and acceptance criteria. If data was isolated before the transition, ensure the post-upgrade test remains comparable and covers current process variants.
An upgrade changes system software and may require data, code, and configuration updates. Do not treat it as a simple action with a guaranteed undo button. Before the production window, agree on a verifiable recovery or continuity strategy, decision conditions, required backups, and how their usability will be checked. The timing and method depend on the architecture, restore point, and contractual responsibilities.
Keep previous working materials as context, but distinguish them from instructions for the target release. Retain the link and version of the old procedure and mark which steps were rechecked, replaced, or retired. Reuse business scenarios and criteria when still valid; carry forward a technical step, role, Fiori app, IMG path, or API only after checking it in the new version.
This partially covers S4-13. The On-Premise and Private Edition upgrade guides refer to SAP S/4HANA 2025; Public Edition sources refer to version 2608. Sources are registered as metadata_only; customer releases, tools, code, tests, production transition, and recovery were not inspected or performed.