Teams should treat custom workflows as control logic, not just configuration. If a workflow drives approvals, SoD checks, or provisioning exceptions, it needs to be redesigned and tested in the target state before cutover. Otherwise the organisation migrates technical functionality while preserving governance fragility.
Why custom workflows must be treated as migration logic, not just SAP configuration
Custom workflows in SAP IDM often encode approval routing, segregation of duties decisions, exception handling, and conditional provisioning. When teams migrate the platform, those workflows become part of the control surface. If they are copied without revalidation, the new system may be technically live while the governance decisions behind it are no longer equivalent.
That is why migration teams should map each custom workflow to the business control it enforces, then decide whether the logic should be rebuilt, simplified, retired, or replaced by native target-state controls. The workflow owner, not just the technical migration team, needs to confirm what the workflow is supposed to permit, block, or escalate.
A useful test is whether the workflow changes access outcomes or only the user interface. If it affects approver selection, rule evaluation, entitlement exceptions, or downstream provisioning, it is a control dependency and should be validated as such. If it only changes labels, notifications, or routing convenience, it is lower risk and can be migrated with lighter assurance.
What usually breaks when workflow logic is lifted and shifted
Custom workflows fail in migration when they depend on old role models, legacy organisational hierarchies, hard coded approvers, or undocumented exception paths. Those dependencies may still execute in the old environment, but they can behave differently once master data, integrations, or the target IAM operating model changes. The result is often silent drift rather than an obvious outage.
Another common failure mode is partial equivalence. A workflow may still open and close requests, yet no longer enforce the same SoD check, approval threshold, or rework path. That creates a control gap that is easy to miss in unit testing because the transaction appears successful. SAP Kubernetes secrets exposure 2023 is a reminder that adjacent SAP control failures can expose sensitive access paths when governance assumptions are not actively verified.
Teams should also watch for custom logic that was never documented because it evolved through exception handling over time. During migration, undocumented flows are the most likely to be missed, especially when they are only triggered for edge cases such as emergency access, delegated approval, or privileged provisioning.
If the workflow controls access to systems with sensitive credentials or administrative rights, the migration risk rises further. Control failures in those paths can turn a functional migration into an exposure event, because the old approval model may no longer bound who can receive access or under what conditions.
How to redesign and validate workflows before cutover
The best migration approach is to treat workflow redesign as a prerequisite for go live, not a post migration cleanup task. Rebuild the workflow in the target state, validate the business rule intent with the control owner, and test the full path from request to approval to provisioning to audit trail.
SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890) illustrates the same migration principle from a different angle: inherited technical behaviour can survive long enough to create serious exposure if it is not reviewed in the target environment. For workflows, the practical equivalent is inherited governance behaviour.
Validation should include representative positive and negative cases, not just happy-path testing. Teams need to confirm that approved requests still flow, disallowed exceptions still stop, SoD conflicts still trigger the intended review, and audit records still show who approved what and why. If the target platform changes role resolution, timing, or connector behaviour, those differences must be tested explicitly.
Where possible, simplify during migration. A custom workflow that exists only to compensate for a legacy limitation is often a candidate for replacement by standard target-state controls, not reimplementation. The less bespoke logic that remains, the easier it is to explain, test, and govern after cutover.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Custom workflows often govern account provisioning and exception handling. |
| AC-6 — Least Privilege | Workflow logic can grant or block elevated access and exceptions. | |
| AU-2 — Event Logging | Workflow changes need auditable records for approvals and provisioning outcomes. | |
| Recommendation — Validate workflow-driven provisioning against AC-2 before cutover. Preserve least-privilege decisions when rebuilding workflow paths. Ensure workflow actions emit audit events that prove who approved and what changed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Workflow approvals and exception paths are part of access control governance. |
| A.8.15 — Logging | Migrated workflows need traceable records for approvals and exceptions. | |
| Recommendation — Reconfirm access-control intent for every migrated workflow. Verify logging captures workflow decisions and provisioning outcomes. | ||
Practitioner Guidance
What to prioritise: Start with workflows that influence approval, SoD, privileged access, or provisioning exceptions. Those are the flows where a migration mistake can change the actual security decision, not just the process shape.
What to verify: Require each custom workflow to have a named control owner, a documented business purpose, and test evidence for both allowed and blocked outcomes. If you cannot show the intended access decision before cutover, the workflow is not ready.
Decision rule: If the workflow changes who gets access, when access is granted, or which exceptions are permitted, redesign and test it in the target state before migration. If it only changes presentation or convenience, it can be treated as lower-risk configuration.
Practitioner takeaway: The safe migration pattern is to preserve the control intent, not the legacy implementation. Teams should accept some workflow redesign as the cost of carrying governance forward into the new platform.