Custom connectors and business rules can disappear during migration if they are not documented up front. In practice, that leads to incomplete provisioning, broken approval chains, and mismatches between what governance approved and what actually gets created or removed. The safest test is to map every custom workflow before selecting the target platform, then verify parity during staged migration.
Why SAP IDM migrations fail when custom logic is left unmapped
The failure is rarely the platform switch itself. The break happens because SAP IDM often contains hidden policy logic in connectors, transforms, approval routing, exception handling, and cleanup steps that are not visible in a standard target-platform design. If those rules are not extracted first, the migration preserves the data structure but loses the business behaviour.
That is why “lift and shift” assumptions are dangerous here. A target IAM or identity governance platform can import accounts and roles while still failing to reproduce the logic that decides who gets provisioned, under what conditions, and with which exceptions. The result is a technically successful migration that behaves incorrectly in production.
In practice, the most fragile parts are the custom workflows that sit between request, approval, provisioning, and deprovisioning. Those paths often encode local business exceptions, manual compensating controls, and system-specific connector logic that never existed as clean product configuration. Once that logic is omitted, the migration stops matching the original control design.
What actually breaks in provisioning, approvals, and deprovisioning
Incomplete mapping usually shows up first as missed entitlements or partial account creation. Provisioning may still complete at the platform level, but one or more downstream systems never receive the right attributes, group memberships, or local permissions. That creates drift between the identity record and the actual access state.
Approval chains can also collapse when custom routing rules are not rebuilt. A request that once depended on business unit, system, entitlement type, or exception status may now follow a default path that is either too permissive or too restrictive. The organisation may think it has preserved governance, while in reality the decision logic has been simplified away.
Deprovisioning is where the risk often becomes most visible. If custom cleanup logic is not mapped, the target system may remove the primary account but leave local access, service bindings, or exception grants behind. That creates stale access, orphaned entitlements, and inconsistent offboarding outcomes across connected systems.
Why the governance record no longer matches the real outcome
The deepest problem is not just technical failure, but governance mismatch. When custom logic is not documented, the approved workflow and the executed workflow diverge. That means audit evidence, control attestations, and operational reality no longer describe the same process.
This is also why migration testing has to compare behaviour, not just data. A successful cutover should prove that the target platform reproduces the same request path, approval conditions, connector actions, and removal logic as the source system. If parity is only checked at the screen or API level, hidden custom logic can remain untested until users lose access or receive access they should not have.
The safest migration design treats each custom rule as a control dependency. Before cutover, teams should map what the rule does, what input it depends on, what system it affects, and what the fallback behaviour is if the rule fails. That makes the migration testable instead of aspirational.
Risk and Threat Considerations
When custom IDM logic is lost, the main risk is not outage alone, but access-control drift. Provisioning errors can create excess privilege, incomplete revocation, or broken approvals that weaken both operational reliability and governance confidence. In a regulated environment, that can turn a migration issue into an audit issue very quickly.
Failure mechanism: Custom rules, connector behaviour, and exception paths are often embedded in legacy SAP IDM workflows rather than documented as explicit target-state requirements. If they are not mapped before migration, the new platform reproduces the identity data but not the access decision logic, so the control no longer behaves as designed.
Impact: The organisation can end up with stale access after offboarding, missing access after onboarding, or approvals that no longer reflect business policy. Over time, that produces entitlement drift, failed attestations, and a higher chance of manual workarounds that reintroduce risk outside the system of record.
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 IDM workflows govern account creation, change, and removal outcomes. |
| AC-6 — Least Privilege | Broken custom logic can leave excess or lingering access after migration. | |
| CM-2 — Baseline Configuration | The source workflow logic is part of the baseline that must be captured before change. | |
| Recommendation — Document and validate account lifecycle rules before migrating them. Verify migrated workflows still enforce least-privilege access outcomes. Baseline all custom IDM logic before selecting the target platform. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Migration needs controlled handling of custom workflow and connector configuration. |
| A.5.15 — Access control | Approval and provisioning logic directly determine who receives access. | |
| Recommendation — Control and test each migrated workflow as a managed configuration item. Reconfirm that migrated access rules still match approved business policy. | ||
Practitioner Guidance
What to prioritise: Map the logic that changes outcomes, not just the fields that move. The highest-value items are custom approval branches, connector transforms, exception handling, and any rule that decides whether access is created, changed, or removed.
What to verify: Test parity with real migration cases, including edge cases such as conditional approvals, negative entitlements, and cleanup on deprovisioning. A good test proves that the target platform produces the same access outcome for the same business input, not merely that the workflow “runs”.
Practitioner takeaway: The migration succeeds only when the business logic is made explicit first; otherwise the new platform may look correct while silently changing how access is actually granted and removed.
Related resources from NHI Mgmt Group
- What breaks when organisations try to replace cryptographic algorithms without mapping dependencies first?
- What breaks when organisations try to migrate to quantum-safe cryptography without a complete inventory?
- What breaks when organisations try to consolidate Active Directory without first cleaning up security issues?
- What breaks when organisations rotate CI/CD secrets without mapping every downstream connection first?