Understanding Restrictions and Freeze Triggers

There are two types of database triggers:

• Recording triggers
• Freeze triggers

Recording Triggers are needed to track changes on the source database, which will be replayed into the target database at a later point in time. These triggers are mainly set on large application tables in order to migrate them already during uptime. More details are available in Checking Database Triggers.

Freeze triggers are needed to ensure the system consistency prior and after the conversion to SAP S/4HANA. These triggers are mainly set on finance customizing tables, which will be „frozen" against any changes. This means, if a transaction tries to change one of those tables, the freeze trigger will prevent the change and the transaction will either dump or throw an error.

A freeze refers to a period in time in which restrictions apply. We distinguish two types of freezes:

• Hard freeze
• Soft / Customizing freeze

The main difference is the way the freeze is enforced: Hard freeze is enforced via database triggers and therefore any violation against the freeze are technically prevented. Soft freeze or Customizing freeze on the other hand is not technically enforced, but needs to be ensured via project governance.

The (reduced) image above shows the downtime-optimized conversion project progression as introduced in unit 1. Here, only the last two runs are displayed: (6) the last downtime-optimized conversion run before production (in this example on the quality assurance (QAS) system) and (8) the final downtime-optimized conversion on production (PRD). With the start of the QAS conversion, the customer buffer needs to be finalized to be able to verify the content in this run. One exception is the potential adaption of Customizing on the temporary instance. This may happen during the last run before production and is added to the final buffer.

Additionally, with the final finance (FIN) customizing created in the temporary instance, the (FIN) customizing on production may not change anymore to ensure that the changes in the buffer match the production state (soft freeze). If the whole buffer is planned to be verified without additional changes on temporary instance (either to minimize risk or because the conversion is done without Database Migration Option), the soft freeze starts with the finalization of the customer buffer before starting the last run before production.

The hard freeze starts during uptime execution of Software Update Manager. After the freeze triggers have been activated, restrictions apply. The restrictions are listed in the downtime-optimized conversion guide, section "Downtime and Business Restrictions". Some examples fore restrictions include:

• Specific transactions are locked, for example SARA.
• Archiving in general needs to be avoided.
• Do not change Material Ledger (ML) costing runs.
• Do not execute material management - material inventory (MM-IM) inconsistency check reports.
• No change of exchange rates for date of conversion when triggers are active.

Those are business impacts that need to be communicated in the project.

Concerning the exchange rates: It needs to be made sure that all migration runs of FINS_MIG_STATUS step M10 (no matter if first run in uptime or final run in downtime) are using the same exchange rates for the date of conversion. So changing of exchange rates for date of conversion (see table CKMLV-MLBWI_TRANS_DATE = "Date of currency translation") needs to be avoided when triggers are active.

In the following exercise, you will explore how restrictions affect transactions.