What is the difference between rebuilding provisioning workflows and simply re-implementing the old identity process in a new platform?

Why rebuilding is not the same as copying the old workflow

Rebuilding a provisioning workflow means treating the process as a control system, not a tool migration. The design starts with the outcome you want, such as reliable approvals, correct entitlements, clear ownership, and auditable deprovisioning, then fits integrations and human steps to that outcome. A re-implementation preserves the old sequence, so the new platform simply automates the same weaknesses.

That distinction matters because provisioning is not just account creation. It defines how access is requested, approved, issued, reviewed, changed, and revoked. If the old process had manual handoffs, duplicated approvals, or unclear ownership, moving it into a new platform only makes those flaws faster and more durable.

For identity-driven workflows, the operational value comes from redesigning the control points, not from replacing the interface. The NHI Lifecycle Management Guide is useful here because provisioning sits inside a broader lifecycle that also includes ownership, rotation, visibility, and offboarding. When those stages are designed together, the workflow becomes measurable instead of merely executable.

What changes when you start from the desired control outcome

Outcome-led rebuilding asks what must be true when the workflow is working correctly. That usually means the request is validated against policy, the approval path matches risk, the resulting access is bounded, and revocation is possible without manual intervention. The new platform is then configured to enforce those rules, rather than inherit the old process unchanged.

This approach often reveals that the real problem is not the provisioning tool, but the decision logic around it. A workflow can be technically successful while still issuing access too broadly, routing requests through unnecessary human review, or leaving no clear owner for exceptions. Rebuilding makes those failure points visible so they can be removed or simplified.

In practice, rebuilding also gives teams room to remove legacy dependencies such as spreadsheet approvals, email-only signoff, or ticket queues that exist only because the old process grew around system limitations. The objective is not speed alone, it is cleaner governance with less manual friction and a shorter path to the correct entitlement state.

That is why lifecycle-focused resources matter. A provisioning flow that is designed well at the start is easier to rotate, audit, and retire later. If the workflow cannot support those later states, it was never really rebuilt, only rehosted.

Why re-implementing the old process usually preserves technical debt

Re-implementation is attractive because it feels safe: teams keep the same approvals, the same exceptions, and the same job roles, then simply move them into a new platform. The problem is that the old process often contains hidden assumptions, like manual reviewer knowledge, local workarounds, or inconsistent rules across teams. Those assumptions do not become better because the tooling changed.

Once copied into a new system, old bottlenecks can become harder to challenge because they now look official. The workflow may appear modern, but the underlying behaviour is still slow, inconsistent, and difficult to govern. In identity operations, that usually means excessive access persists, revocation takes longer than it should, and exception handling becomes a permanent operating model.

A useful test is whether the new platform changes the control outcome, not just the path to the outcome. If the same request still requires the same people, the same delays, and the same manual interpretation, you have likely digitised technical debt rather than reduced it. The better outcome is often fewer steps, clearer policy expression, and stronger traceability.

For practitioners, the warning sign is when the project is described as a migration, but success is measured only by feature parity. Feature parity is not governance parity. A rebuilt process should be able to prove better control, cleaner ownership, and less friction in the parts of the workflow that matter most.

Practitioner Guidance

What to prioritise: Define the access outcome first, then map each workflow step to a control purpose. If a step does not improve approval quality, entitlement accuracy, auditability, or revocation reliability, it is probably inherited baggage.

What to verify: Test whether the new workflow changes the decision model, not just the screen flow. A good check is to compare request paths for common, privileged, and exception cases; if they all behave like the legacy process, the redesign is incomplete.

Common mistake: Teams often treat manual review as a feature of governance when it is really a sign that policy, role design, or integration logic has not been simplified enough. Manual steps can still be necessary, but they should be deliberate exceptions, not the backbone of the process.

Practitioner takeaway: If the old process is copied into a new platform, the organisation usually gets the same control weaknesses with a better interface. Real rebuilding changes the governing logic, not just the implementation venue.

Related resources from NHI Mgmt Group

• What is the difference between patching a vulnerability and reducing identity blast radius?
• What is the difference between helpdesk provisioning and helpdesk automation in identity workflows?
• What is the difference between provisioning NHSmail accounts manually and governing them through identity workflows?
• What is the difference between attack surface management and NHI governance?