Lesson 5 of 5
Governing rule changes
9 min
Rules change. A mock shows a mapping was wrong, the business reorganizes its customer groups, finance decides a different reconciliation account. Change is normal; uncontrolled change is what breaks migrations. A rule that changes without anyone updating the tests, the reconciliation reports and the cutover plan produces data nobody can explain in the final load. Governance makes rule changes deliberate, visible and tested.
Baselines and versions
Once a data owner approves a mapping specification or a cleansing rule, it becomes a baseline with a version number, for example business partner specification v1.3. From then on, changes go through a change request rather than an email or a quiet edit. Tests, reconciliation scripts and mock results all record which version they used. When a rule changes, that link tells you exactly what must be rerun.
- Change requestWhat, why, which object and rule, who asks
- Impact analysisTests, reconciliation scripts, cockpit mappings, configuration, cutover timing
- Owner decisionApprove, reject or defer; record the reason
- Build and versionSpecification and rule updated; new version number
- RetestLinked targeted tests rerun; reconciliation scripts adjusted
- Confirm in next mockEffect checked in the next extract and load
Impact analysis
The person asking for a change rarely sees all its consequences. A new value mapping for customer groups may need new configuration in the target, a change to the cockpit mapping task, new targeted test records, an updated reconciliation report that groups by customer group, and retraining for the users who read those reports. The migration specialist and the test lead do the impact analysis together, and the result goes to the owner with the request.
| Area | Question to ask | Contoso example: new customer group mapping |
|---|---|---|
| Specification | Which rules and tables change? | Value mapping table VM-CG moves to v2.0 |
| Configuration | Does the target need new values? | Two new customer groups must be configured in CMD and transported |
| Migration Cockpit | Do mapping tasks or fixed values change? | Customer group mapping task updated in the project |
| Tests | Which targeted tests rerun or are added? | Six new test records, one per changed group |
| Reconciliation | Do reports change dimensions? | Customer count by group report updated |
| Cutover | Does timing or sequence change? | No change in timing |
Freeze points
Changes get more expensive as go-live approaches. Agree freeze points in the migration plan: rules are baselined before Mock 1, changes are batched between mocks, and the rules are frozen before the final rehearsals so that the dress rehearsal tests exactly what will run in production. After the freeze, only changes that fix a critical defect are allowed, through an emergency route with the program lead's approval.
- Before Mock 1BaselineSpecifications and cleansing rules approved at version 1.x
- Between mocksChange windowBatched changes with impact analysis, retest and new versions
- Before Mock 3Soft freezeOnly changes with an owner decision and full retest
- Before dress rehearsalHard freezeEmergency changes only, approved by Grace as PMO lead and the owner
- After go-liveHand-overRules become ongoing data quality checks in master data governance
- Is the change needed to fix a critical defect in the final load?Yes → emergency route: owner and PMO approve, full retest · No → next question
- Are we before the hard freeze?Yes → normal change request with impact analysis · No → defer to a post-go-live mass change
- Can it wait until after go-live without business harm?Yes → defer and record it · No → escalate to the owner and the PMO lead
After go-live
Migration rules describe what good data looks like. Do not throw them away after cutover. Hand them to the team that runs master data, so they become ongoing checks: validations in data entry, data quality rules in SAP Master Data Governance where it is used, or regular reports. Otherwise the clean data you migrated slowly degrades, and the next project profiles the same problems again.
What would you do?
Two days before the Wave 2 dress rehearsal, after the hard freeze, the sales director asks to change the customer group mapping so that a new fleet segment appears in reporting from day one. No defect is involved. What should happen?
- Approved rules become versioned baselines; changes go through change requests.
- Impact analysis covers specification, configuration, cockpit mappings, tests, reconciliation and cutover.
- Agree freeze points; after the hard freeze only critical fixes through an emergency route.
- Hand migration rules over as ongoing data quality checks after go-live.
Check your understanding · not graded
Lesson check
1. Why do tests and reconciliation scripts record the specification version they used?
2. What is allowed after the hard freeze before the dress rehearsal?
3. Which belongs in the impact analysis of a value mapping change?
4. What should happen to migration rules after go-live?