Cutover SAP: последовательность перехода и контроль финансовых данных

Cutover - это согласованная смена рабочего состояния процессов и систем, а не одна команда загрузки. В плане должны совпасть границы данных, разрешённые изменения источника, зависимости объектов, техническое окно, финансовые контрольные точки и решение о допуске пользователей. Порядок и блокировки зависят от выбранного способа перехода.

Выберите план для конкретного сценария#

До составления расписания зафиксируйте тип перехода, исходный и целевой релизы, компании и области процесса, объём истории, интерфейсы и режим целевой системы. Системная конверсия, начальная загрузка Migration Cockpit и selective data transition не используют один и тот же механизм дельты или блокировок.

Для SAP S/4HANA Cloud Public Edition 2608 Migration Cockpit предназначен для начального набора данных: мастер-данных, открытых транзакций и остатков, с отдельными правилами для объектов. В документации сказано, что открытые документы нужно обработать в источнике до переноса; для некоторых мастер-данных могут понадобиться период блокировки изменений или двойное ведение. Частично поставленный заказ клиента закрывают в источнике, а частично открытый заказ на закупку закрывают или отменяют. Это ограничения конкретной редакции и версии, не универсальная инструкция для конверсии On-Premise.

При selective data transition через SAP Business Transformation Center таблицы источника записываются непосредственно в целевую базу в рамках выбранного подхода. Документация требует во время фактической миграции не менять данные ни в источнике, ни в цели и блокировать пользователей этих систем. Последующие действия могут выполняться после downtime, но порядок зависит от конкретной миграции. Не переносите эту блокировку на другие инструменты без их руководства.

Для конверсии через SUM 2.0 downtime-optimized procedure переносит часть конвертации в uptime и использует предусмотренные SUM механизмы записи, повтора и обработки изменений, включая техническую delta-фазу для соответствующих процедур. Это не общее обещание, что любой бизнес-объект можно менять до переключения без отдельного плана. Применимость, freeze, ограничения и точные фазы проверяйте по установленному SUM Support Package и целевому Conversion Guide.

Зафиксируйте границы и зависимости#

Для каждого потока определите четыре момента времени: последнюю разрешённую операцию в источнике, cutoff исходной выборки, момент переноса или конверсии и момент, после которого разрешены операции в цели. Отдельно обозначьте часы и часовой пояс, календарный день в SAP, posting date и правила для документов, введённых заранее или проведённых позднее.

Составьте граф зависимостей по бизнес-объектам. Сначала должны быть доступны базовые настройки и справочники, затем загружаются объекты, использующие их; порядок мастера и транзакционных объектов задаётся документированным migration object и сценарием. Не переводите это в универсальный порядок всех модулей без просмотра зависимостей целевых объектов.

Для финансового потока согласуйте, как окно затрагивает:

остановку или очередь бухгалтерских интерфейсов, job-ов, платежей и выписок;
открытые позиции AP/AR и документы, ожидающие последующих шагов;
остатки, ledger, валюты, период и поздние проводки;
активы, зависимые значения и ожидаемые операции закрытия;
CO-объекты, бюджеты и обязательства, если они входят в выбранный scope;
внешних потребителей, которым нужно сообщить о смене endpoint, версии или временной недоступности.

Запишите владельца решения, действие при ошибке, запрет параллельной двойной записи и способ возобновить каждый поток. Роли, задания, API и окна пакетной обработки подтверждайте на фактической конфигурации, а не выводите из общего расписания cutover.

Подготовьте freeze и обработку изменений#

Freeze должен называть именно то, что замораживается: проведение документов, изменения мастер-данных, конфигурация, transports, интерфейсы или конкретные таблицы в технической процедуре. Для каждого ограничения укажите начало, конец, ответственного, контролируемый признак и способ эскалации.

При конверсии FI/CO отдельно проверьте release-specific Customizing freeze. Руководство SUM 2.0 SP26 описывает freeze период для Finance Customizing между dress rehearsal и производственным go-live, а также отдельные ограничения downtime-optimized conversion. Содержание soft/hard freeze и исключения различаются по версии и сценарию. Не трактуйте эти указания как общий запрет на все изменения данных.

Определите судьбу операции, совершённой после cutoff:

входит ли она в поддерживаемую delta-механизмом часть выбранной технической процедуры;
будет ли она извлечена отдельным повторным отбором по документированным ключам и watermark;
должна ли она ожидать возобновления целевого процесса;
требуется ли ручное решение для уже начатого, но не завершённого бизнес-процесса.

Не называйте отдельную повторную выгрузку CDC. Если метод не сохраняет версию и порядок источника либо не имеет поддерживаемого механизма повторного отбора, установите явную паузу на изменения или согласуйте иной путь. Повторная загрузка и поздно проведённый документ должны быть связаны по идентификатору и не создавать ни пропуск, ни дубль.

Выполняйте cutover по контрольным точкам#

Практический порядок, который нужно адаптировать под сценарий:

Готовность: закрыты решения по scope, target configuration, доступам, mapping, зависимостям, тестам, владельцам и откату. Dress rehearsal выполнен с максимально сопоставимым входом и настройками.
Объявление окна: участникам и внешним системам переданы начало, ограничения, каналы связи, ожидаемое окончание и критерии остановки.
Заморозка потока: применены только согласованные блокировки; очередь новых операций контролируется и журналируется.
Финальная граница: выполнены необходимые обработки источника и закрытия периодов, сняты исходные контрольные величины, зафиксированы cutoff, watermark и идентификаторы выгрузок.
Перенос или конверсия: выполняются шаги выбранного SAP-механизма в согласованном порядке. Технические сообщения, ошибки и повторы записываются для каждого объекта.
Финансовая сверка: сравниваются source baseline и target state на совпадающем scope; ожидаемые отличия проверяются по заранее утверждённому реестру.
Go/no-go: владельцы финансового результата, приложений и эксплуатации принимают решение по заранее заданным порогам. Незакрытое блокирующее расхождение или неизвестная граница данных останавливает открытие целевого потока.
Открытие и стабилизация: интерфейсы и задания включаются по одному после проверки ключевых путей; контролируются первые проводки, платежи, выписки, статусы очередей и повторная обработка.

Конкретные действия, ответственные и временные оценки заполните в runbook проекта. Этот порядок не является SAP-runbook и не заменяет SUM Guide, Migration Cockpit documentation или план, согласованный с владельцами конкретного ландшафта.

Сверьте обе стороны cutoff#

Итоговую сверку считайте по одному и тому же правилу отбора и измерения. Сопоставляйте документы по идентификаторам и состояниям, а агрегаты - как минимум по компании, ledger, периоду, валюте и валютному виду. Включайте количество и суммы, а не только чистый итог: разнонаправленные пропуски могут взаимно компенсироваться.

Отдельно сверяйте статусы открытых позиций, сроки, клиринг, балансовые счета и остатки, если они входят в scope. Сохраняйте список источниковых документов, попавших после cutoff, их решение и целевые следы. Для каждого исключения укажите владельца, допустимое действие и доказательство; не переносите объяснение с предыдущей репетиции без проверки нового снимка.

Правило приёма должно быть записано до производственного окна: точные допустимые отличия, величины или условия, блокирующие go-live, и лицо с правом принять остаточный риск. Любой используемый допуск по округлению относится к заранее определённой валюте и уровню расчёта.

Определите остановку и возврат#

Сформулируйте checkpoint до начала работ: какие технические признаки показывают, что путь ещё можно безопасно прекратить, и какой момент начинает возврат к прежнему процессу или требует отдельного восстановления. Для каждого этапа определите, кто принимает решение и как будут учтены операции, поступившие после cutoff.

Не объявляйте rollback простым восстановлением backup: после записи в целевую систему, изменения источника или включения внешних интерфейсов может понадобиться согласовать данные двух сторон. Репетиция должна проверить действия по возврату или альтернативное решение, включая обработку поздних платежей, файлов и проводок. Порядок и возможность технического возврата зависят от конкретного метода, поэтому подтвердите их у владельцев SAP и ландшафта.

Материал частично покрывает MIG-13. SAP-источники разделяют Public Edition 2608, selective data transition в SAP Business Transformation Center и downtime-optimized conversion в SUM 2.0 SP26. Все записи имеют статус metadata_only; локальный сценарий, граф зависимостей, окна, блокировки, дельты и план возврата не проверялись. SAP runtime и cutover не выполнялись. Представленный порядок - шаблон подготовки, а не руководство для выполнения перехода в продуктивной системе.

Связанные материалы#

Cutover is an agreed change in the operating state of processes and systems, not a single load command. The plan must align data boundaries, permitted source changes, object dependencies, the technical window, financial checkpoints, and the decision to admit users. The sequence and locks depend on the chosen transition method.

Choose a plan for the specific scenario#

Before scheduling, record the transition type, source and target releases, companies and process areas, history scope, interfaces, and target-system operating mode. System conversion, Migration Cockpit initial load, and selective data transition do not use the same delta or freeze mechanism.

For SAP S/4HANA Cloud Public Edition 2608, Migration Cockpit is intended for initial data: master data, open transactions, and balances, with object-specific rules. Its documentation says open documents must be processed in the source before transfer; a freeze period or dual maintenance may be needed for some master data. A partially delivered sales order must be closed in the source, while a partially open purchase order must be closed or cancelled. These are boundaries for this edition and release, not universal steps for an On-Premise conversion.

For selective data transition through SAP Business Transformation Center, source database tables are written directly to the target database within the selected approach. The documentation requires that data not be changed in either source or target during the actual migration, so users of both systems must be locked. Follow-on activities may occur after downtime, but the sequence depends on the migration. Do not apply this lock automatically to other tools.

For a conversion using SUM 2.0's downtime-optimized procedure, some conversion work is moved into uptime and the supported SUM procedure uses change recording, replay, and a technical downtime delta. This does not promise that every business object can change until switch-over without a separate plan. Check applicability, freezes, restrictions, and exact phases for the installed SUM Support Package and target Conversion Guide.

Define boundaries and dependencies#

For each flow, define four times: the last permitted source operation, source-selection cutoff, transfer or conversion time, and the point after which target operations are permitted. Specify timezone, SAP business date, posting date, and rules for documents entered earlier or posted later.

Create a dependency graph for business objects. Basic settings and reference data must be available before dependent objects are loaded; the order of master and transactional data depends on the documented migration object and scenario. Do not turn this into one universal module sequence without reviewing the target objects' dependencies.

For the finance flow, agree how the window affects:

stopping or queueing accounting interfaces, jobs, payments, and statements;
AP/AR open items and documents waiting for follow-on steps;
balances, ledgers, currencies, periods, and late postings;
assets, dependent values, and planned closing operations;
CO objects, budgets, and commitments when they are in scope;
external consumers that need endpoint, version, or outage information.

Record the decision owner, error action, prohibition on parallel duplicate entry, and how each flow will resume. Confirm roles, jobs, APIs, and batch windows in the actual configuration rather than inferring them from a generic cutover schedule.

Prepare the freeze and change handling#

A freeze must name exactly what is frozen: document posting, master-data changes, configuration, transports, interfaces, or tables in a specific technical procedure. For each restriction, define its start and end, owner, monitored signal, and escalation action.

For conversion, check the release-specific FI/CO Customizing freeze separately. The SUM 2.0 SP26 guide describes a Finance Customizing freeze between dress rehearsal and production go-live, along with separate restrictions for downtime-optimized conversion. Soft/hard freeze content and exceptions vary by version and scenario. Do not treat these instructions as a universal ban on all data changes.

Decide what happens to an operation after cutoff:

Is it part of the supported delta mechanism for the selected technical procedure?
Will it be extracted through a separate rerun using documented keys and a watermark?
Must it wait for the target process to resume?
Does an in-progress business process need a manual decision?

Do not call a separate re-extract CDC. If a method does not preserve source version/order or provide a supported re-selection method, impose an explicit pause on changes or agree another path. A retry and a late-posted document must be linked by identifier so that neither a gap nor a duplicate is created.

Execute cutover by checkpoints#

A practical sequence to adapt to the selected scenario is:

Readiness: decisions on scope, target configuration, access, mapping, dependencies, tests, owners, and rollback are closed. A dress rehearsal used inputs and settings as comparable as possible to production.
Window notice: participants and external systems receive the start time, restrictions, communication channels, expected duration, and stop criteria.
Freeze the flow: apply only agreed locks; monitor and log queued new operations.
Final boundary: complete source processing and period closing where required, capture source control totals, and record cutoff, watermark, and extract identifiers.
Transfer or conversion: execute the selected SAP method in the agreed sequence. Record technical messages, errors, and retries by object.
Finance reconciliation: compare source baseline and target state for the same scope; validate expected differences against the approved register.
Go/no-go: finance-result, application, and operations owners decide against pre-agreed thresholds. An unresolved blocking difference or unknown data boundary stops the target flow from opening.
Open and stabilize: enable interfaces and jobs one at a time after key paths are checked; monitor the first postings, payments, statements, queue states, and retries.

Fill in concrete tasks, owners, and time estimates in the project runbook. This sequence is not an SAP runbook and does not replace the SUM Guide, Migration Cockpit documentation, or a plan approved by the owners of the actual landscape.

Reconcile both sides of the cutoff#

Calculate the final reconciliation using the same selection and measurement rules. Compare documents by identifier and state, and aggregates at least by company, ledger, period, currency, and currency type. Include counts and amounts, not just net totals: omissions in opposite directions can cancel out.

Separately reconcile open-item status, due dates, clearing, balance-sheet accounts, and balances when in scope. Retain a list of source documents that appeared after cutoff, their disposition, and target trace. For each exception, record its owner, permitted action, and evidence; do not reuse an explanation from a previous rehearsal without checking the new snapshot.

Define acceptance rules before the production window: exact permitted differences, values or conditions that block go-live, and the person authorized to accept residual risk. Any rounding allowance applies to a currency and calculation level defined in advance.

Define the stop and rollback point#

Set a checkpoint before work starts: technical signals that mean the path can still be safely stopped, and the point at which returning to the previous process or performing a separate recovery is required. For every stage, name the decision-maker and how post-cutoff operations will be accounted for.

Do not describe rollback as simply restoring a backup: after writes to the target, source changes, or external interfaces are enabled, reconciling both sides may be necessary. Rehearsal should exercise the return procedure or alternative, including late payments, files, and postings. Technical reversibility depends on the method; confirm it with SAP and landscape owners.

This material partially covers MIG-13. SAP sources distinguish Public Edition 2608, selective data transition using SAP Business Transformation Center, and downtime-optimized conversion in SUM 2.0 SP26. All source records are metadata_only; the local scenario, dependency graph, windows, locks, deltas, and rollback plan were not checked. No SAP runtime or cutover was performed. This sequence is a preparation template, not instructions to execute a production transition.