Lesson 3 of 5
Delta and freeze
9 min
Two problems collide on go-live weekend. The old system keeps changing until the moment it is switched off, and the new system cannot absorb everything in one short window. The answer is a combination of freezes, which stop or limit change, and deltas, which carry across what changed after an earlier load.
Kinds of freeze
| Freeze | What stops | Typical timing | Contoso example |
|---|---|---|---|
| Design and rule freeze | Changes to mapping and transformation rules | Before the final rehearsals (Mock 3) | Payment terms mapping locked after Mock 2 |
| Configuration and transport freeze | Non-critical transports to the target landscape | Weeks before go-live | Only cutover-critical fixes may be imported to production |
| Master data freeze | Creation and change of master data in the source, or changes tracked for delta | Days to weeks before cutover | New customers only by exception, logged for re-entry |
| Transactional freeze (business blackout) | Posting in the source system | Start of the cutover window | Last legacy ERP shipments Friday 6 p.m.; legacy ERP locked for postings |
The main freezes. Each needs a date, an owner and an exception process.
Pre-load plus delta
Master data changes slowly and there is a lot of it. Loading it during the cutover window wastes precious hours. Many programs therefore pre-load master data into production before the window, often a week or two before go-live, and then load only the delta: records created or changed since the pre-load extract. Open items and balances, which change every day and must be exact at the cutover date, are loaded during the window after the transactional freeze.
How deltas are handled
There is no single delta mechanism; the right one depends on the object and the tool. The common options are:
- Reload changed records: extract records created or changed since the pre-load (using change dates or change logs in the source) and load them as new or changes. Needs a tool path that can update as well as create.
- Dual maintenance: during the master data freeze, any essential change is made by hand in both systems and logged. Practical only for small numbers.
- Freeze and log: changes are forbidden except by exception; each exception is logged and re-entered in the new system after go-live.
Whichever option you choose, rehearse it. A delta that has never been tested in a mock is the most common gap in migration plans, because the mocks usually load everything from scratch and the delta path is only exercised on the real weekend. Plan at least one rehearsal, ideally Mock 3 or the dress rehearsal, that runs exactly as go-live will: pre-load, a period of change, then delta plus open items.
- T-14 daysMaster data extractBusiness partners, products and dependent master data extracted from the legacy ERP
- T-12 daysPre-loadLoaded into production SAP S/4HANA (CMP) for company code 1910 and validated by owners
- T-12 to T-1Master data freezeChanges by exception only, each logged for the delta
- T-0 Friday 6 p.m.Transactional freezeLast postings in the legacy ERP; system locked
- T-0 to T+2Delta and open itemsMaster data delta, then open orders, stock, open items and balances; reconciliation and sign-off
What would you do?
During the Alternadores del Norte master data freeze, its sales operations need to set up a new fleet customer urgently to accept a large order. What should happen?
- Freezes limit change: rules, transports, master data and finally postings.
- Pre-load large, stable master data before the window; load only deltas at cutover.
- Load open items and balances after the transactional freeze so they are exact at the cutover date.
- Every freeze needs an exception process; every delta path must be rehearsed.
Check your understanding · not graded
Lesson check
1. Why pre-load master data before the cutover window?
2. Which data is normally loaded after the transactional freeze?
3. What is a common gap in migration plans regarding deltas?
4. What should every freeze have besides a date?