Migration workbook · Ten decision gates
SAP IdM migration checklist. Prove readiness before you cut over
A working checklist for programme owners, IAM architects and application teams. Record what is ready, what remains uncertain and which evidence authorises the next step.
SAP IdM mainstream maintenance ends on 31 December 2027. SAP describes extended-maintenance options through 2030. Confirm eligibility, scope and commercial terms in SAP Note 3268799 and your contract. An extension provides planning time; it is not a new SAP IdM release. SAP’s maintenance announcement.
How to use this checklist
This is a readiness workbook, not a promise that a migration will take a particular number of weeks. Its ten gates are editorial recommendations for controlling a replacement programme. They are not a certification standard, statutory requirements or a record of a completed customer project. Your scope, source data, integrations, operating constraints and team availability determine the work.
For each gate, record a status, accountable owner, evidence location, decision date and next action. Use ready only when the evidence demonstrates the condition. Use not ready when a required control fails. Use not yet verified when the answer rests on an assumption. If a condition is not applicable, retain the reason and the approving owner rather than leaving a blank box.
Review the record with the people who operate the affected services. A programme manager can coordinate the decision but cannot approve an application’s entitlement mapping on behalf of its business owner. Likewise, a successful provisioning response is useful evidence but does not replace verification of the resulting account and permissions.
For the wider architecture choices and migration phases, read There Is No New Version of SAP Identity Management to Upgrade To. Use this companion when you need a concrete go/no-go discussion.
The readiness scorecard
| Gate | Evidence to bring | Decision owner |
|---|---|---|
| 1. Support and scope | Contract position, systems in scope, exclusions | Sponsor and platform owner |
| 2. Current-state inventory | Sources, jobs, connectors, roles, dependencies | IAM lead and application owners |
| 3. Identity and access cleanup | Correlation tests and approved disposition decisions | Data and role owners |
| 4. Target responsibilities | Control map and source-of-truth decisions | Architecture and security |
| 5. Integration proof | Observed results for supported target operations | Integration and application owners |
| 6. Lifecycle tests | Joiner, mover, leaver and exception evidence | Process owners |
| 7. Coexistence | Writer ownership and reconciled differences | Operations lead |
| 8. Cutover and recovery | Rehearsed runbook, thresholds and recovery test | Change authority |
| 9. Evidence continuity | Accessible historical and new decision records | Control and records owners |
| 10. Retirement | Disabled legacy paths and accepted service handover | Service owner |
Do not turn this table into a percentage that conceals a critical failure. Nine ready gates do not compensate for a leaver process that leaves privileged access active. Identify mandatory conditions for each wave and escalate any exception to the person authorised to accept that specific risk.
Confirm the support position and the actual scope
Start with the deployed SAP IdM version, its dependencies and the support arrangements that apply to your organisation. Retain a dated support record with the relevant product availability information, contract interpretation and the owner who confirmed it. Access to an SAP support note may require an authorised SAP account; a public summary cannot settle an individual contract.
Then define what the programme replaces. Include identity populations, SAP and non-SAP systems, lifecycle processes, governance controls and operational services. Record exclusions explicitly. A cloud authentication project does not automatically replace on-premises provisioning, local role administration or historical reporting.
Ready when: the sponsor and platform owner agree on scope, support assumptions and the internal completion objective. Each exclusion has an owner and a continuing control. Pause when: the business case assumes support disappears for every customer in 2027, or assumes extended maintenance automatically covers every component until 2030.
Inventory the deployed behaviour and its configuration
Collect identity stores, repositories, scheduled jobs, provisioning tasks, scripts, connectors, role definitions, approval paths and service accounts. Capture actual operating behaviour from logs and target systems, then compare it with documentation. Identify jobs that run rarely, such as annual campaigns or certificate renewal, because a short observation window can miss them.
For each integration, record the business purpose, authoritative source, target version, supported operations, schedule, volume, credentials owner, failure queue and support contact. Identify dependencies outside the platform: email approvals, spreadsheets, manual service-desk actions, batch files and jobs triggered by another scheduler.
Ready when: application owners validate the inventory and unresolved differences have named investigators. Keep sensitive configuration in an access-controlled location. Pause when: an integration is labelled unused solely because nobody remembers it, or a script has no person able to explain its business effect.
Resolve identity matches and access cleanup decisions
Define how the target will correlate a person with existing accounts. Test stable identifiers, duplicate records, renamed users, rehires, multiple employment relationships and contractor-to-employee changes. An email address may change or be reused; do not assume it is a safe permanent identity key without checking the source rules.
Give every role, entitlement and workflow a disposition: retain, redesign, merge or retire. Ask business owners to approve access-related decisions. Lack of observed use is a reason to investigate, not automatic proof that an entitlement can be deleted. Seasonal duties and emergency access need context.
Ready when: correlation tests have no unexplained matches and cleanup decisions are approved with recoverable evidence. Pause when: ambiguous identities could cause the target to create duplicate accounts, attach privileges to the wrong person or remove valid access. Treat those outcomes as specific defects, not acceptable background noise in a migration report.
Assign each target responsibility
Separate authentication, governance, provisioning, reconciliation and audit reporting. Decide which service owns each responsibility and which system is authoritative for each material attribute. SAP Cloud Identity Services, Microsoft Entra, an IGA engine and application-specific administration can be parts of a target architecture, but their presence does not establish how they work together.
Document requests, approvals, role policy, separation of duties, access expiry, reviews and exception handling. For each control, specify its input, responsible person, executing service, target result and retained evidence. Identify responsibilities that move from SAP IdM to a different team, because handover is an operating-model change as well as a technical change.
Ready when: every required outcome has one accountable owner and an unambiguous implementation path. Pause when: two services believe they own the same attribute, or a control disappears because each supplier expects the other product to provide it. Compare options using demonstrated coverage and operating cost rather than a preferred product label.
Prove integrations against the real target versions
A connector name is not an acceptance test. Verify the operations you need: discover, create, update, enable, disable, remove, assign permissions and reconcile. Test the required account types and entitlement structures. A connector that provisions a basic user may not manage the privileged roles, nested groups or custom objects in your scope.
Exercise rate limits, timeouts, invalid input, insufficient permissions and unavailable targets. Check whether retrying an operation duplicates work or safely converges on the intended state. Confirm how credential rotation and certificate expiry affect the connection, and who receives an actionable alert when the integration fails.
Ready when: evidence records the input, requested change, actual target state and exception path for each required operation. Pause when: success means only that an API returned an acknowledgement. Agree on a manual fallback for systems outside automated coverage and test that fallback before counting them as governed.
Test complete lifecycle outcomes
Choose representative identities and run complete joiner, mover and leaver journeys. Include a future-dated hire, a cancelled start, a manager change, a contractor expiry and a rehire where those cases occur in your business. Observe source ingestion, identity correlation, policy, approval, provisioning and reconciliation together.
For a mover, prove that obsolete access is removed as well as new access granted. For a leaver, consider active application sessions, local accounts, keys and ownership dependencies. Disabling a central account does not necessarily terminate every application-issued session; Microsoft documents that distinction. Define target-specific verification.
Ready when: process owners accept both ordinary and failure scenarios and can reconstruct the outcome from the evidence. Pause when: only a demonstration account with minimal permissions has passed. Use the offboarding playbook to expand the leaver test beyond directory disablement.
Control coexistence and reconciliation
Define which platform may write each target object and attribute during every stage. If the old and new systems both enforce different desired states, they can reverse one another’s changes or repeatedly recreate access. A coexistence design needs explicit ownership boundaries, not simply a promise that the teams will coordinate.
Begin observation or simulation with permissions and configuration that prevent unintended writes. Compare predicted changes with current target state and have owners review the differences. Simulation has limits: it cannot prove every downstream effect, so follow it with controlled write tests in an appropriate environment. Confirm your selected engine’s actual simulation behaviour in its version-specific documentation.
Ready when: unexplained differences are resolved and the writer transition is recorded per target. Pause when: a large discrepancy report is dismissed as expected without classification. Keep an approved baseline and explain which changes are intended cleanup, which reflect timing and which indicate a defect.
Rehearse cutover and recovery
Write a wave-specific runbook with prerequisites, access restrictions, ordered actions, validation checks, communications and decision authority. Set measurable pause and recovery conditions before the maintenance window. Examples include failed revocations in a critical application, unexplained identity collisions or loss of a required evidence feed.
Recovery must account for business changes that occur during the transition. Restoring an old database may restore obsolete access or erase a valid new decision. Identify reversible configuration changes, irreversible target actions and the compensating steps needed after the point where simple rollback is no longer safe.
Ready when: the team has rehearsed the runbook and demonstrated the recovery method for the scoped wave. Pause when: rollback consists only of “turn SAP IdM back on.” The change authority should know who can stop the wave, how users will receive support and what evidence must exist before the next wave begins.
Preserve the evidence across both platforms
List the historical records that remain necessary: access requests, approvals, policy versions, review decisions, provisioning results, exceptions and significant incidents. Define retention and access requirements with the relevant records, privacy and control owners. Do not export everything indefinitely merely because storage is available.
Test whether an authorised reviewer can find and interpret a historical decision after SAP IdM is no longer running. Preserve the identifiers and explanatory context needed to connect the old record to the corresponding identity, application and entitlement in the target. An unreadable archive is not an effective evidence handover.
Ready when: a sample can be reconstructed across the transition and new decisions are captured from the start of target operation. Pause when: the archive depends on an account scheduled for deletion, or evidence access requires restarting an unsupported production service. Record known gaps and their approved treatment rather than presenting incomplete history as continuous coverage.
Retire the legacy paths and accept the service
Retirement includes more than stopping a server. Disable obsolete schedules, connector credentials, network permissions, service accounts, callbacks and manual procedures. Confirm that no source or target still relies on an old job. Keep archives separate from active provisioning paths so evidence retention cannot accidentally reactivate account changes.
Hand over operating procedures, monitoring, backup and recovery, escalation contacts, credential ownership and known exceptions. Train the service desk and application teams on the new failure modes. Specify who maintains connectors and policies after the project team leaves, and how changes are tested before release.
Ready when: the service owner accepts the system with evidence of stable operation, owned residual risks and a completed legacy retirement record. Pause when: a hidden legacy job remains the only way to complete a business-critical process. Close that dependency or document an explicitly approved transition arrangement with an end condition.
Run a useful go/no-go meeting
Bring the scorecard, open defects, reconciled target results and a short exception register. Begin with conditions that could cause unauthorised access, service interruption or loss of evidence. Review whether each mandatory condition is satisfied; do not spend the meeting counting completed technical tasks.
For every exception, record the affected population and systems, possible consequence, compensating measure, owner, expiry and verification plan. The person accepting the risk must have authority for that service or control. A project team cannot convert a failed security condition into acceptance merely by changing its status colour.
Finish with one recorded decision: proceed within the agreed scope, proceed with specifically approved conditions, or pause pending named evidence. Assign a time for reassessment. This makes the checklist useful even when the answer is “not yet,” because the next action and required proof are clear.
Where easyIGA belongs in the evaluation
easyIGA adds a business-facing workspace to the open source midPoint platform. Employees request access and managers make decisions with the available context. The evidence overview explains captured approvals, grants outside easyIGA and missing historical records. Policy-conflict checks are available at decision time; authoring and simulating rules inside easyIGA remain planned. The required SAP and non-SAP operations form part of the integration scope agreed for your migration.
Our team’s experience includes 14+ midPoint implementations. We use your inventory to identify the migration work, supported versions and responsibilities before agreeing a delivery plan. A scoped pilot gives both teams concrete evidence for the next stage.
Discuss your SAP IdM readiness gaps Understand the IGA operating model
Sources and editorial record
Product scope and editorial wording updated on 12 October 2026. Original source-check dates are retained below.
Verified 12 September 2026. The gates, suggested evidence and go/no-go criteria are editorial implementation guidance. They are not SAP contractual terms or customer results.
- SAP: Preparing for SAP Identity Management’s End-of-Maintenance in 2027, February 2024; mainstream and extended-maintenance direction.
- SAP Note 3268799, access-controlled support reference; not independently inspected in this audit. Confirm its application with your SAP support owner.
- Microsoft Learn: Migrate identity management scenarios from SAP IdM, living migration guidance; consulted for target responsibility and cleanup considerations.
- Microsoft Learn: Revoke user access in an emergency, living technical guidance on identity-provider and application session boundaries.
- Evolveum: midPoint 4.10 synchronisation, version-specific documentation; reconciliation and target-state considerations.
- easyIGA product scope and Our team’s background, current production statements.
Photo: imgix / Unsplash, Unsplash License; existing editorial asset, attribution retained and checked. Send corrections through our contact page.