Migration readiness

How to Define Exit Criteria for SAP Migration Model Risks

By Dzmitryi Kharlanau · Published · 23 min read

The programme has completed the remediation task.

Contents

Reviewed: 14 July 2026

The programme has completed the remediation task.

A missing Supplier Classification was added to the migration file. The mapping ticket is closed. The SAP validation passed in the latest test. The risk register now shows:

Status:
Resolved

Two weeks later, the same gap appears in a new extract.

The source system was never corrected. The migration team fixed only the current file. New records still arrive without classification. The temporary default remains available, and nobody has confirmed whether downstream systems interpret it correctly.

The task was completed.

The risk was not removed.

This happens frequently in SAP migration and MDG programmes because teams use delivery activity as evidence of risk closure.

They ask:

These are useful milestones.

They do not necessarily prove that the underlying exposure has ended.

A model risk should leave the active register only when predefined evidence shows that its cause, affected population, model dependencies and residual exposure have reached an approved state.

That evidence is the risk’s exit criteria.

Without explicit exit criteria, risks tend to close when the programme becomes tired of discussing them.

Completion and risk closure are different events

A backlog item can be complete while the parent risk remains open.

Consider this sequence:

Risk:
Supplier Classification is unavailable for ERP_B records.

Task:
Add classifications to the Wave 2 migration file.

Task result:
Completed.

Remaining condition:
The next ERP_B extract will still omit the field.

The task reduced immediate migration exposure.

It did not resolve the source-model risk.

A better status would be:

Risk status:
Mitigated for Wave 2

Residual risk:
New and changed ERP_B suppliers remain unsupported

Next exit condition:
Operational source or controlled enrichment process implemented

This distinction prevents temporary success from being reported as permanent resolution.

Exit criteria define the state that must be true

Acceptance criteria usually describe what a delivery item must produce.

Exit criteria describe what must be true before a risk can leave a defined lifecycle stage.

For example:

Task acceptance criterion

Update the mapping so source value STRAT converts to STRATEGIC.

Risk exit criterion

Every source value observed in the agreed population has an approved target treatment, and the mapping remains valid against the current source dataset.

The first proves that one change was made.

The second proves that the mapping risk has reached an acceptable state.

Exit criteria should be agreed when the risk is opened

Teams often define closure evidence at the end.

This creates a conflict of interest.

By then:

Define exit criteria when the risk is assessed and the treatment is selected.

At that point, reviewers should answer:

What evidence would convince us that this risk is no longer active—or has been reduced to an explicitly accepted residual level?

This makes the expected outcome visible before work begins.

Not every risk exits by becoming zero

Many enterprise risks cannot be eliminated completely.

A risk may leave active treatment through several valid outcomes.

Resolved

The cause and material exposure have been removed.

Example:

Reduced to an accepted residual level

Some exposure remains, but responsible authorities approve it.

Example:

Transferred into an operational control

The risk becomes part of a stable process.

Example:

Superseded

The affected scope or model is no longer relevant.

Example:

Converted into a known issue or model debt

The programme cannot resolve the exposure before handover.

It remains visible with:

This is not the same as resolution.

The exit is from one programme process into another explicitly governed process.

Exit criteria must match the risk type

A generic criterion such as:

Owner confirms resolution.

is weak.

Different risks require different evidence.

Source risk

Example risk:

The source system does not reliably provide Tax Registration Identifier.

Possible exit criteria:

A one-time corrected file is insufficient when the source process remains unchanged.

Mapping risk

Example risk:

Several source values have no approved target treatment.

Possible exit criteria:

Rule risk

Example risk:

A mandatory validation applies too broadly.

Possible exit criteria:

Value-list risk

Example risk:

Temporary value MIGRATION_REVIEW is being treated as a normal classification.

Possible exit criteria:

Ownership risk

Example risk:

No accountable owner exists for Supplier Risk values.

Possible exit criteria:

Naming a person in a spreadsheet is not enough if the role and authority remain unclear.

Context risk

Example risk:

A German validation is represented as a global rule.

Possible exit criteria:

Implementation-alignment risk

Example risk:

SAP configuration does not match the approved model.

Possible exit criteria:

Traceability risk

Example risk:

A critical target field cannot be traced to its source and decision.

Possible exit criteria:

Exit criteria should cover five dimensions

For material model risks, we recommend checking five dimensions.

1. Model state

Has the approved model been corrected or clarified?

Evidence may include:

2. Data state

Does the affected population now satisfy the approved treatment?

Evidence may include:

3. Implementation state

Do SAP and connected systems implement the approved model?

Evidence may include:

4. Control state

Can the problem reappear without detection?

Evidence may include:

5. Residual-risk state

What exposure remains, and who has accepted it?

Evidence may include:

A risk should not be called resolved when only one dimension has changed.

Use measurable population criteria

Many risks concern a population of records.

Exit criteria should state:

Weak criterion:

Data quality improved.

Stronger criterion:

All active German supplier organisations in the approved Wave 3 extract contain either a valid Tax Registration Identifier or an approved exemption code.

Another:

At least 99% of applicable records map to approved target values, and every remaining record is listed in a signed exception register.

Thresholds should be programme policies, not universal industry rules.

The critical point is that the population and allowed exceptions are explicit.

Do not use percentages without materiality

A 99.9% result can still hide a serious problem.

The remaining 0.1% may contain:

Exit criteria should therefore combine percentage and material checks.

For example:

Completeness:
At least 99%

And:

No missing values for suppliers with active purchase orders
or regulated supplier status

This prevents averages from hiding critical exceptions.

Define the relevant baseline

Evidence has meaning only relative to a known state.

A risk exit should identify:

For example:

Model baseline:
supplier-model-v2.7

Dataset:
ERP_B_supplier_extract_2026-09-01

Implementation release:
MDG-R4

Test cycle:
UAT-2

Without baseline alignment, teams may close a risk using:

Require current evidence

A risk discovered from a July dataset should not necessarily close based on the same July dataset after a manual correction.

Ask whether evidence reflects the current process.

Useful rules include:

The evidence does not need to be generated on the day of closure.

It should be current enough to prove the new state rather than the old problem.

Distinguish one-time remediation from recurring prevention

Suppose 8,000 records are corrected manually.

The current population is now clean.

If the source continues producing bad values, the risk remains.

Exit criteria should distinguish:

Remediation evidence

Existing affected records corrected.

Prevention evidence

New or changed records cannot reproduce the same uncontrolled condition—or the condition will be detected and routed.

A complete exit may require both.

Existing population:
Reconciled

Future prevention:
Source validation active and monitored

Verify that temporary controls have been removed or formalised

Risks often accumulate temporary treatments:

Before closure, ask:

A risk should not close while an unmanaged workaround remains active.

Use negative evidence

Positive evidence shows that expected behaviour works.

Negative evidence shows that invalid behaviour is prevented.

For a mandatory-rule risk, test:

Positive

A valid applicable record succeeds.

Negative

An invalid applicable record fails.

Exception

An approved exempt record succeeds.

Out-of-scope

A record outside the rule’s context is not blocked.

This is more reliable than showing only one successful test case.

Test dependencies, not only the changed component

A value-list risk is not closed merely because the new value appears in SAP MDG.

Check:

A source-field replacement is not closed merely because the extract contains the new column.

Check:

Impact analysis should define which dependencies require evidence.

The current Martenweave core supports canonical model validation, trace, impact analysis, dataset profiling and gap detection, which can help identify the objects that should be included in closure evidence.

Exit criteria should be binary where possible

A criterion should allow a reviewer to decide whether it is met.

Weak:

Mapping quality acceptable.

Stronger:

Some judgements will remain qualitative.

Even then, record the responsible decision.

For example:

The Global Customer Data Owner confirms that the remaining difference between source and target definitions is understood and acceptable for the stated context.

Avoid criteria that depend only on status fields

Weak exit evidence includes:

These may be part of the evidence.

They do not prove the underlying state.

A transport can be imported with incorrect configuration.

A workbook can be updated with an unsupported mapping.

A workshop can end without a durable decision.

Assign an exit-criteria owner

The risk owner remains accountable for closure.

Different people may provide evidence:

The risk record should state who confirms each dimension.

Example:

Exit dimensionEvidence owner
Business meaningSupplier Data Owner
Source availabilityERP_B Owner
Dataset stateMigration Data Lead
SAP implementationMDG Architect
Regression evidenceTest Lead
Residual-risk acceptanceProgramme Data Owner

This prevents the person completing the last technical task from closing the entire risk unilaterally.

Use independent verification for high-risk items

For critical risks, the person implementing the treatment should not be the only person verifying closure.

Independent review may include:

This is especially important for changes involving:

Independent verification does not mean recreating the whole analysis.

It confirms that the agreed evidence supports closure.

Define hard blockers to closure

Some conditions should prevent closure automatically.

Examples:

These blockers should be programme policy.

They should not be waived informally during status meetings.

Allow conditional exit

Sometimes a risk can leave one stage with conditions.

For example:

Exit from migration-design risk:
Approved

Conditions:
- ERP_B enrichment complete before Mock Load 3
- blocking validation remains disabled until coverage reaches the approved level
- weekly gap report continues

This is not full resolution.

It is a controlled transition.

Useful statuses include:

This provides more precision than one final Closed status.

Define exit criteria for migration gates

Exit from model design

Possible criteria:

Exit from mapping design

Possible criteria:

Exit from remediation

Possible criteria:

Exit from testing

Possible criteria:

Exit for cutover

Possible criteria:

Exit from hypercare

Possible criteria:

A risk should not close because the milestone passed

A programme may reach cutover while risks remain.

The risk register should not be cleaned up merely because the migration phase ends.

Possible outcomes are:

Preserve the continuity.

Otherwise, post-go-live support inherits the exposure without the original rationale or evidence.

Transfer criteria are as important as closure criteria

When a risk moves from project to AMS, define what must be transferred.

Possible criteria include:

The receiving team should confirm that it can operate the control.

A risk is not transferred merely because the project document was uploaded.

Reopen risks when the evidence changes

Closure should not make a risk invisible forever.

Reopening triggers may include:

For example:

Risk closed:
ERP_A mapping covers all approved values.

Reopening trigger:
New source value observed without approved treatment.

The trigger can become a deterministic or monitoring rule.

Connect exit criteria to deterministic validation

Some criteria can be checked automatically.

Examples:

Martenweave’s current principles place deterministic validation before indexing and treat generated indexes as rebuildable from canonical files.

This supports repeatable structural exit checks.

Automation should not approve semantic or business-risk criteria.

It can show whether the model meets the rules the programme has already defined.

Connect exit criteria to dataset readiness

For data-related risks, current profiling is often essential.

The current Martenweave core documents dataset profiling, model-to-dataset gap detection and a dataset-readiness workflow.

A data-risk exit might require:

Expected column:
Present

Applicable completeness:
Meets approved programme threshold

Value coverage:
All material observed values treated

Key integrity:
No unresolved critical failures

Remaining exceptions:
Listed with owners

The report should reference the same model baseline and population used for approval.

Connect exit criteria to impact analysis

Before closing a change-related risk, confirm that affected dependencies were reviewed.

For example:

Changed object:
VLIST-SUPPLIER-RISK

Reviewed dependencies:
- mappings;
- rules;
- workflows;
- interfaces;
- tests;
- reports.

The current Martenweave CLI includes trace and impact commands over the canonical model.

The impact result does not prove every external dependency exists in the registry.

It proves that the dependencies represented in the approved model were considered.

Known coverage limits should be stated.

A conceptual exit record

risk_id: MRISK-0048
status: ready_for_closure

model_baseline: supplier-model-v2.8
dataset_baseline: ERP_B_supplier_extract_2026-09-01

exit_criteria:
  - criterion: Unrestricted default removed
    status: met
    evidence: CHANGE-SUPPLIER-RISK-021

  - criterion: Current active population has approved treatment
    status: met
    evidence: READINESS-ERP-B-2026-09-01

  - criterion: Future source process is controlled
    status: met
    evidence: SOURCE-CONTROL-ERP-B-17

  - criterion: SAP rule matches approved context
    status: met
    evidence: TEST-MDG-R4-118

  - criterion: Residual records accepted
    status: met
    evidence: DEC-ERP-B-EXCEPTIONS-04

residual_population: 42
residual_risk: low
accepted_by: ROLE-GLOBAL-SUPPLIER-DATA-OWNER
review_date: 2026-12-01

This is a conceptual representation rather than a statement of one mandatory Martenweave schema.

The value lies in the explicit evidence chain.

A worked example: missing source attribute

Risk

ERP_B cannot provide Supplier Classification.

Weak closure

The Wave 2 file was manually enriched and loaded successfully.

Remaining exposure

Better exit criteria

Possible outcome

Risk is not fully resolved at Wave 2.

It is marked:

Mitigated for migration and transferred to operational data stewardship.

That is more honest and more useful.

A worked example: incorrect mandatory rule

Risk

Customer Group validation blocks inactive customers and countries where the attribute is not used.

Treatment

Introduce contextual applicability.

Exit criteria

Closure evidence

A worked example: retired target endpoint

Risk

Active mappings reference a target endpoint scheduled for retirement.

Weak closure

A replacement field was added to the mapping workbook.

Better exit criteria

The risk closes only after the old dependency has been removed from the applicable model state.

A worked example: temporary migration value

Risk

MIGRATION_REVIEW is treated as a normal Supplier Classification.

Exit criteria

If 20 records remain under an approved legal hold, the risk may close with a documented residual population rather than requiring artificial zero.

A worked example: unclear ownership

Risk

No accountable owner exists for Customer Group mappings.

Weak closure

A consultant is assigned to review the current workbook.

Better exit criteria

The consultant may perform the analysis.

They should not become the permanent governance model by default.

Use a closure review, not an administrative status update

For material risks, conduct a short closure review.

The reviewer should see:

  1. Original risk statement.
  2. Approved treatment.
  3. Exit criteria.
  4. Evidence for each criterion.
  5. Current residual exposure.
  6. Remaining assumptions.
  7. Required monitoring or reopening trigger.
  8. Proposed final status.

The review should answer:

Has the exposure changed enough to justify the proposed status?

It should not become a general project presentation.

Record unmet criteria explicitly

A risk may be close to resolution.

Do not hide the remaining gap.

Example:

CriterionStatus
Current population remediatedMet
Uncontrolled default removedMet
Future source process correctedNot met
Operational owner assignedMet
Monitoring activePartial

Proposed status:

Mitigated, not resolved.

This gives management a truthful decision surface.

Use waivers sparingly

Sometimes the programme needs to close or transfer a risk with an unmet criterion.

The waiver should identify:

Example:

Unmet criterion:
ERP_B source process corrected

Waiver:
Accepted for cutover because affected records remain blocked
and source correction is scheduled for the first post-go-live release.

Expiry:
30 November 2026

A waiver without expiry is usually permanent acceptance disguised as temporary relief.

AI can help assemble closure evidence

AI may assist with:

AI should not decide that a risk is closed.

It cannot independently determine:

The safe boundary is:

AI assembles and challenges evidence.
Validators check deterministic criteria.
Accountable owners approve the final status.

Where Martenweave fits

The current Martenweave Core README describes an open-source, backend-first model-governance and evidence layer for SAP migration, MDM, data governance and AMS. It turns spreadsheets, datasets, tickets, validation reports, decisions and SAP context into canonical model files, deterministic validation, dataset-gap reports, lineage, impact analysis and human-approved patch proposals.

Its operating pipeline is:

evidence
→ proposal
→ validation
→ gaps and impact
→ review
→ GitHub issue or pull request

For model-risk exit, Martenweave can help preserve:

Martenweave should not become a general enterprise risk-management platform.

Its role is to make model-risk evidence traceable to the model state that created or resolved the exposure.

A Martenweave risk-exit flow

Model risk
        ↓
Approved treatment
        ↓
Exit criteria attached to affected objects
        ↓
Model, data and implementation work completed
        ↓
Deterministic validation
        ↓
Dataset readiness and impact evidence
        ↓
Residual-risk assessment
        ↓
Human closure or transfer decision
        ↓
Current baseline and monitoring updated

The core principle is:

Closing the ticket records completed work. Closing the risk records proven change in exposure.

A minimum exit-criteria template

Risk identification

Approved treatment

Required model state

Required data state

Required implementation state

Required control state

Required evidence

Residual risk

Reopening triggers

Final decision

What management should ask

  1. What exact state must be true before this risk closes?
  2. Were exit criteria agreed before treatment began?
  3. Does the evidence use the current model and dataset baseline?
  4. Was the underlying cause corrected, or only the current population?
  5. Can the condition reappear?
  6. Were affected dependencies tested?
  7. Have temporary controls been removed or formalised?
  8. What residual population remains?
  9. Who accepted the residual risk?
  10. Does the risk need transfer rather than closure?
  11. What event should reopen it?
  12. Has AMS received any remaining control?
  13. Are deterministic and semantic criteria clearly separated?
  14. Can another reviewer reproduce the closure conclusion?

If the only evidence is a closed ticket or successful load, the exit criteria are probably incomplete.

Common mistakes

Closing risk when the mitigation task closes

Activity completion does not prove changed exposure.

Using one successful migration load as permanent evidence

The next source extract may reproduce the problem.

Requiring zero defects without defining materiality

Teams may hide or reclassify legitimate residual exceptions.

Using percentages without examining critical records

Small residual populations can still carry high risk.

Ignoring prevention

Corrected records do not guarantee future control.

Leaving temporary workarounds active

The original risk may be replaced by model debt.

Closing before implementation alignment is verified

The model may be correct while SAP remains different.

Treating transfer to AMS as resolution

Transferred risks need owners, controls and review dates.

Allowing the implementer to self-certify every criterion

High-risk closure benefits from independent review.

Letting AI infer final closure

Residual-risk acceptance remains a human governance decision.

When a lightweight approach is sufficient

A small programme may manage exit criteria in a controlled spreadsheet.

Useful fields include:

This may be sufficient when:

A registry-based approach becomes more useful when:

Our conclusion

A risk is not closed because the programme has done something.

It is closed—or consciously transferred or accepted—because evidence shows that the relevant exposure has reached an approved state.

Good exit criteria connect:

The practical test is:

Could another qualified reviewer examine the stated criteria and evidence and reach the same conclusion about whether the risk is resolved?

When the answer is yes, closure is evidence-based.

When the answer depends on the risk owner saying “the task is done,” the programme has recorded progress but not proven risk reduction.

The purpose of exit criteria is not to make risk closure bureaucratic.

It is to prevent incomplete treatments, temporary workarounds and one successful test cycle from being mistaken for durable model control.

About the authors

Martenweave is maintained by Dzmitryi Kharlanau.

We build practical model-governance infrastructure for SAP migration, MDG, MDM and AMS teams.

Martenweave connects canonical model objects, datasets, mappings, rules, risks, decisions and reviewable changes. This creates a traceable evidence layer for showing not only that remediation work was completed, but that the underlying model exposure actually changed.

Sources and notes

This article was reviewed on 14 July 2026.

SAP currently describes SAP Master Data Governance as the governance layer of a business data fabric, with governed models, preserved semantics and relationships, collaborative workflows, validated values, business-rule monitoring, mass changes and auditable data changes. SAP also recommends curating clean and correct master data early, before an SAP S/4HANA implementation, because more automated processes rely heavily on it.

The current Martenweave Core README describes Martenweave as an open-source, backend-first model-governance and evidence layer for SAP migration, MDM, data governance and AMS. The current source version is listed as 0.5.0.

Martenweave uses canonical model files, deterministic validation, rebuildable generated indexes, dataset-gap analysis, trace and impact analysis, and reviewable PatchProposal and ChangeRequest workflows.

The current core documents validation, trace, impact and dataset-readiness commands that can support reproducible risk-exit evidence.

Martenweave is an independent project and is not affiliated with or endorsed by SAP. SAP, SAP S/4HANA and SAP Master Data Governance are trademarks or registered trademarks of SAP SE or its affiliates.

Primary sources

Related articles