Controls tied to legacy workflows, integrations, and master data can stop matching the new process environment even when the technical migration succeeds. That creates gaps in approvals, reconciliations, and ownership because the organisation assumes old control logic still applies. The safest approach is to treat control mapping as a core migration deliverable, not a post-go-live task.
Why SAP S/4HANA Migration Breaks When Control Logic Is Left Behind
A technical cutover can succeed while the control environment quietly fails. When a migration is handled as an IT project instead of a control programme, the organisation may carry over approval paths, reconciliations, segregation of duties assumptions, and ownership models that no longer fit the new process design. That is when exceptions start to accumulate and controls lose evidential value.
The key issue is not only whether the new system runs, but whether the business control that used to sit around it still maps cleanly to the new master data, integration points, and workflow states. If the process changed but the control did not, the organisation can end up with a control that looks intact on paper and is ineffective in practice.
In SAP programmes, this often shows up where legacy interfaces, role design, workflow routing, and data ownership were tuned to the old landscape. A migration that does not explicitly revalidate these dependencies can leave hidden gaps between what the system permits and what the business thinks is governed.
What Typically Stops Working First
The first failures are usually operational, not dramatic. Approval chains may still exist but no longer reflect the current transaction path, reconciliations may miss new source-to-target differences, and ownership may be unclear when a process moves across teams or modules. If the control assumes the old chart of accounts, old interface timing, or old master data stewardship, it can become disconnected from the new operating model.
That is why control mapping has to include the process state, not just the application object. For a useful migration review, compare each critical control to the post-migration design and verify that it still answers the same question, at the same point in the flow, with the same evidence source. Legacy logic that once protected the business can become an untested assumption after the move. See the broader control-catalogue expectation in NIST SP 800-53 Rev 5 Security and Privacy Controls and the zero-trust principle of verifying the current state rather than inheriting trust from the old one in NIST SP 800-207 Zero Trust Architecture.
Migration teams also miss that integrations are often part of the control surface, not just plumbing. If an interface changes source, format, timing, or authentication path, a downstream control that depended on the old behaviour may still “work” while no longer supporting the intended check. In SAP environments, that is especially dangerous when business users assume the control survived because the transaction itself still posts.
How to Treat Migration Control Mapping as a Programme Workstream
Control mapping should be owned as a dedicated workstream with the same discipline as data conversion or cutover testing. The practical test is simple: for every critical control, identify the pre-migration trigger, the post-migration trigger, the evidence source, the owner, and the exception path. If any of those changed, the control has changed and must be reapproved, not merely carried forward.
What to verify: confirm that approvals, reconciliations, access checks, and master data governance are still anchored to the correct business event after the migration. Verify the control against the new process design, not the old system diagram, and insist on evidence that reflects live post-go-live behaviour rather than pre-migration assumptions.
What practitioners underestimate: the hardest break is often ownership drift. When business process owners, SAP functional teams, and control owners each assume another group has remapped the control, gaps appear in accountability even when the technical deployment is clean. This is why migration governance should include explicit sign-off on control design, not only system readiness.
Practitioner takeaway: if the migration changes how work flows through the enterprise, the control programme must be redesigned alongside it. Treat every inherited control as provisional until it has been revalidated against the new process, new data model, and new evidence path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Migrated roles and approvals must still enforce current privilege boundaries. |
| AU-6 — Audit Review, Analysis, and Reporting | Control evidence must still be reviewable after process and integration changes. | |
| CM-3 — Configuration Change Control | Migration remaps controls through changed workflows, interfaces, and master data dependencies. | |
| Recommendation — Revalidate role and approval boundaries so post-migration access stays least-privilege. Update audit review points to match the new SAP control evidence path. Treat control remapping as part of change control before go-live. | ||
| NIST CSF 2.0 | GV.PO-01 — Policies, Processes, and Procedures | A migration needs documented control process changes, not just technical cutover. |
| PR.DS-01 — Data-at-rest is protected | Master data and reconciliation evidence depend on governed data flows after migration. | |
| Recommendation — Document post-migration control procedures and ownership before deployment. Confirm migrated master data is protected and governed in its new state. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Legacy access assumptions can fail when SAP roles and workflows change. |
| A.5.37 — Documented operating procedures | Control programmes require updated procedures to remain effective after migration. | |
| Recommendation — Review access rules against the new SAP operating model before go-live. Refresh operating procedures so post-migration controls are executable and testable. | ||