Planning the Security Workstream for an ERP Migration: A Practical Guide

In the project plan for a large ERP migration, the security workstream typically occupies a modest section between data migration and change management. A few tasks for role mapping, some time allocated for SoD analysis, a testing phase, and a cutover checklist. The actual work required to migrate thousands of users to a new authorization model is routinely larger, more complex, and more interconnected with other workstreams than the initial plan suggests.

This guide covers the practical considerations for scoping and planning the security workstream, based on patterns observed across migrations of varying scale and complexity.

Scoping: What Actually Needs to Happen

The security workstream in an ERP migration involves several distinct activities, each with its own dependencies and resource requirements.

Discovery and extraction comes first. This involves pulling user master data, role assignments, transaction usage logs, and authorization values from the source system. For organizations with clean, well-documented environments, this can be completed in one to two weeks. For environments with extensive customization, multiple clients, or poor documentation, allow three to four weeks and budget for surprises.

Role design or persona development follows. This is the analytical core of the workstream: determining what the target-state authorization model should look like. Whether you're mapping legacy roles directly to target equivalents or deriving personas from usage data, this phase requires both technical expertise (understanding the source and target authorization models) and business input (validating that the proposed design reflects actual organizational needs).

User-to-role mapping is the most labor-intensive phase. Each user needs to be assigned to the appropriate roles or personas in the target system. At scale, this involves processing thousands of individual assignments, handling exceptions, and managing the approval workflow with business stakeholders.

SoD analysis and remediation runs parallel to or immediately after the mapping work. Every proposed assignment needs to be checked against the organization's SoD ruleset, and conflicts need to be resolved through redesign, mitigation controls, or documented exception approval.

Testing covers both positive access (can users do what they need to do?) and negative access (are users prevented from doing what they shouldn't?). Both types are necessary; most migration plans only account for the first.

Cutover and stabilization involves executing the role assignments in the target system and supporting users through the first days and weeks of go-live. Access-related support requests typically spike immediately after go-live and remain elevated for two to four weeks.

Timeline: How Long Each Phase Actually Takes

For a migration involving 5,000 users, realistic timelines for each phase are as follows. These assume a dedicated security workstream team of two to three people working full-time.

Discovery and extraction: 2 to 4 weeks, depending on source system complexity and data quality.

Role design or persona development: 3 to 6 weeks. This is often the most variable phase because it depends heavily on how much stakeholder input is required and how many iterations the design goes through before approval.

User-to-role mapping: 4 to 8 weeks for manual approaches. Automated tooling can compress this to 1 to 2 weeks, but stakeholder review and approval still require time.

SoD analysis and remediation: 2 to 4 weeks if integrated with mapping. 4 to 8 weeks if performed as a separate sequential phase, due to the rework cycle.

Testing: 2 to 4 weeks for positive testing. Add 2 to 3 weeks for meaningful negative testing.

Stabilization: 2 to 4 weeks post-go-live.

Total elapsed time: 15 to 29 weeks for a 5,000-user migration. Most initial project plans allocate 8 to 12 weeks for the same scope. The gap between planned and actual duration is one of the most consistent patterns in migration project retrospectives.

Dependencies: What the Security Workstream Needs from Other Teams

The security workstream doesn't operate in isolation. It has critical dependencies on several other migration activities.

The functional design team determines the business processes and system configuration in the target environment. The security workstream can't finalize role designs until the functional design is stable enough to know which transactions and authorization objects will exist in the target system.

The data migration team controls when user master data is loaded into the target system. The security workstream needs this data to validate role assignments in the actual target environment, not just in design documents.

The change management team communicates access changes to end users and manages the approval process with business stakeholders. Delays in stakeholder availability for review and approval directly impact the security workstream timeline.

The basis or system administration team manages the target system's authorization configuration, including role creation, authorization object customization, and user provisioning. The security workstream designs the roles; the basis team implements them.

These dependencies mean that the security workstream timeline is often constrained not by its own capacity but by the availability of inputs from other teams. Planning should account for this explicitly.

Common Mistakes to Avoid

Starting too late is the most common planning error. The security workstream has a long lead time, and the discovery and design phases need to begin well before the mapping work starts. Organizations that defer the security workstream until the functional design is "complete" find themselves compressing a 20-week workstream into 10 weeks.

Underestimating stakeholder involvement is the second most common error. Business stakeholders need to validate persona definitions, approve role designs, review SoD exceptions, and sign off on final access assignments. Each of these touchpoints requires their time, which is limited and competed for by other migration workstreams.

Treating automation as optional is increasingly a planning gap. For migrations above 2,000 users, manual approaches create timeline risk and error rates that can be substantially reduced with appropriate tooling. The cost of the tooling is typically a fraction of the consultant hours it displaces.

Skipping negative testing is a tactical choice that creates strategic risk. If you don't verify that users can't perform unauthorized functions, the auditors will verify it for you at a much higher cost.