Lesson 3 of 5
Freeze
11 min
Listen to this lesson
A conversion needs the system to stand still in stages. Development stops changing it, configuration stops changing, master data settles, and finally business transactions stop. Each of these is a freeze, and each has a date, an owner, rules for exceptions and a message to the people affected. Freezes that are vague, late or ignored are among the most common causes of a messy cutover.
Layers of freeze
- About 6 weeks beforeDevelopment freezeNo new development to ECC except emergency fixes, which are retrofitted to the project
- After the dress rehearsalConfiguration and runbook freezeTransports for production fixed; runbook changes only through Luis
- The week beforeMaster data slow-downOnly urgent master data changes; CVI and SI-Check re-run on production
- Friday 18:00Business transaction freezeUsers locked; interfaces and jobs stopped; the before picture taken
- Monday 06:00ReleaseUsers unlocked on SAP S/4HANA after go/no-go 2
The development freeze matters because every change in ECC after the last mock is a change the mocks did not test. The ECC support team runs ChaRM on SAP Solution Manager 7.2, while the S/4HANA program runs in SAP Cloud ALM. Any emergency fix made in ECC during the freeze must be retrofitted into the project landscape, or it will be lost or will conflict at conversion. The cutover manager should see every such fix.
Not every change is an emergency. Contoso's freeze exception process decides quickly: only legal, safety and production-down issues qualify, everything else waits until after go-live. Luis sees every request, because each one changes what the next rehearsal has to prove.
Master data needs its own rule. Business partners, materials and prices keep changing until the weekend, and every change must pass the business partner checks and the Simplification Item-Check consistency rules that the mocks proved. Contoso slows master data changes in the last week to urgent ones only, approved by the data owner, and re-runs the SI-Check and a business partner consistency check on production in the days before Friday, so that a new data error does not stop SUM in uptime.
Ramp-down: stopping the business cleanly
- Finance: period close timed so the conversion starts right after it; depreciation posted; reconciliations done; the before picture taken.
- Logistics: shipments staged before Friday 18:00; goods receipts from Lakeside Components scheduled around the window; physical stock matched to the system.
- Sales: orders for Great Lakes Fleet Services and other key customers entered before the freeze; a manual order log for urgent orders during the window.
- Interfaces: inbound queues drained or held; outbound files sent; partners told when sending resumes.
- Batch: long-running jobs finished before the lock; the job schedule suspended and its restart order documented.
| Ramp-down step (Friday evening) | How, in ECC EP1 | Owner |
|---|---|---|
| Warn logged-on users | System message in SM02; check who is still logged on in SM04 | Luis |
| Drain interfaces | Inbound and outbound queues empty or held (SMQ1, SMQ2), no hanging tRFC calls (SM58), IDocs processed (WE02, BD87); PO channels on XP1 stopped | Theo |
| Suspend the job schedule | Report BTCTRNS1 suspends released jobs; BTCTRNS2 releases them again after go-live, in the documented order | Sam |
| Lock users | Mass lock in EWZ5, leaving out the cutover team and required technical users | Nadia |
| Take the before picture | Balances, open items and stock values by company code and plant, with saved report variants | Dan |
| Back up EP1 | Full backup verified before SUM enters downtime | Sam |
Contoso's ramp-down with the ECC transactions and reports each owner uses.
If Contoso used downtime-optimized conversion, the freeze plan would change shape: some restrictions would start days before, during SUM uptime, such as a short-term lock for asset accounting postings and controlled changes to finance Customizing. Those restrictions must appear in the freeze plan and in user communications, because users will feel them before the weekend starts.
Communications
| Audience | What they need to know | When |
|---|---|---|
| All users | Freeze times, what to finish before Friday, how to log on on Monday | Four weeks, one week and one day before |
| Key users and process owners | Their weekend tasks, validation slots and sign-off times | With the dress rehearsal plan |
| Customers and suppliers | Order and delivery cut-offs, EDI pauses, contacts for urgent needs | Two to four weeks before |
| Executives | Go/no-go times, what each decision means, how they will be informed | Before the final readiness review |
| Support desk | Known issues, workarounds, escalation paths for Monday | The week before |
What would you do?
Two weeks into the development freeze, a tax rate change requires an urgent fix in EP1. Kenji's team can make it in a day. What should happen?
- Freeze in layers: development, configuration and runbook, master data, business transactions.
- Retrofit every emergency fix in ECC into the project landscape and test it.
- Ramp-down covers finance close, logistics staging, sales orders, interfaces and batch jobs.
- Plan communications by audience and pre-write every message the weekend may need.
- Ramp-down uses real tools: SM02, SMQ1/SMQ2, SM58, BTCTRNS1, EWZ5, a saved before picture and a verified backup.
Check your understanding · not graded
Lesson check
1. Why does the development freeze matter for a conversion?
2. An emergency fix is made in ECC during the freeze. What must follow?
3. When does Contoso's business transaction freeze begin?
4. Why pre-write cutover messages?
5. Which ECC report suspends released background jobs before the downtime, so they can be released again in order later?