A migration factory is a structured delivery model for moving many applications through a repeatable identity migration process. It standardises work into consistent steps, roles, and controls so teams can reduce risk, improve throughput, and avoid one-off rewrites for each application.
Expanded Definition
A migration factory is a repeatable delivery model for moving applications through a standard identity migration sequence. It usually defines intake criteria, assessment steps, target-state decisions, testing, cutover, and rollback so teams can process many workloads with consistent governance rather than treating each migration as a one-off project.
The term is often used in large-scale platform or identity programmes where speed and repeatability matter more than bespoke engineering. The boundary to watch is that a migration factory is not the migration itself. It is the operating model around migration, including the roles, handoffs, templates, and controls that make each move predictable. In practice, the value comes from reducing variance, not from adding more technical complexity.
Definitions vary slightly across vendors and delivery consultancies, but the common thread is industrialised change: the same sequence of decisions and checks is reused across many applications. For identity-heavy migrations, that repeatability matters because credentials, entitlements, service accounts, and authentication dependencies often fail in different ways than application code.
Examples and Use Cases
A migration factory shows up when organisations need to move many systems through the same identity pattern without creating a bespoke project for each workload. The model is especially useful where the risk is not the first migration, but the twentieth, when inconsistency starts to appear.
- Moving dozens of applications from shared credentials to distinct workload identities under one standard process.
- Converting legacy access patterns into a repeatable onboarding, validation, and cutover workflow for each application owner.
- Standardising how secrets are discovered, replaced, tested, and retired during a cloud or platform transition.
- Running a controlled migration wave where every application follows the same dependency check, rollback gate, and approval path.
A useful tradeoff is that a factory increases throughput only when the underlying template is accurate. If the common process is too rigid, teams may force edge cases into the wrong path and create rework. If it is too loose, the supposed factory becomes a collection of inconsistent exceptions.
For identity and secrets work, repeatability is often the real asset. The Ultimate Guide to NHIs is useful background because it ties migration decisions to lifecycle, visibility, rotation, and offboarding concerns that commonly surface during large-scale change.
Security Implications
When a migration factory is poorly designed, it tends to scale mistakes as efficiently as it scales good practice. A weak template can copy insecure authentication patterns across many applications, preserve overprivileged access, or leave old credentials active after cutover. The failure is rarely dramatic in a single step; it is cumulative and often only visible after the programme has already spread risk widely.
One practical consequence is that identity migration can expose hidden dependency chains. Applications may still depend on shared tokens, embedded secrets, or brittle service-account relationships that were never documented. If the factory does not include validation, ownership, and post-move verification, those hidden dependencies survive the migration and become harder to detect later.
NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. In a migration factory, that matters because the same privilege pattern can be reproduced across many workloads unless least-privilege decisions are built into the process.
A common practitioner observation is that cutover success does not prove security success. Applications may run, but stale access paths, duplicated secrets, or incomplete revocation can leave the old environment still trusted long after the move.
Domain and Governance Relevance
Migration factory thinking matters most when the subject of migration includes non-human identities, service credentials, or machine-to-machine trust. In those environments, the governance problem is not just application relocation. It is whether the migration process preserves ownership, reduces standing access, and creates a reliable record of what was changed, by whom, and when.
That is why migration factories are relevant to NHI programmes: they turn scattered identity changes into a governed lifecycle process. The model supports repeatable decisions about inventory, dependency mapping, rotation, revocation, and post-migration validation, which are the controls that usually fail when identity work is handled ad hoc. It also helps security and platform teams align on who approves a change, who verifies the outcome, and when an old access path can be retired.
In practice, the strongest migration factories treat identity transition as an operational control surface, not just a project milestone. That distinction is what keeps large migrations from becoming large-scale identity accumulation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Migration factories depend on knowing which NHIs and owners move in each wave. |
| NHI-02 — Secrets and Credential Management | Identity migrations often replace embedded secrets and service credentials. | |
| NHI-04 — Authorization and Least Privilege | Factory templates must prevent overprivileged access from being replicated. | |
| Recommendation — Maintain a complete NHI inventory and assign ownership before each migration wave. Replace embedded credentials with managed secrets and rotate them during cutover. Enforce least privilege in the standard migration pattern to avoid privilege replication. | ||
| CIS Controls v8 | 5 — Account Management | Repeatable migrations require controlled creation, change, and removal of accounts. |
| 6 — Access Control Management | The factory must preserve approved access while removing stale access paths. | |
| Recommendation — Track account lifecycle changes so migrated identities are approved and retired cleanly. Validate access scope after each move and remove obsolete permissions promptly. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Migration factories operationalise identity and access decisions across many systems. |
| Recommendation — Standardise identity and access checks for every migrated application. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Access Enforcement | Zero Trust migration patterns require explicit enforcement during workload transition. |
| Recommendation — Apply explicit access enforcement when shifting workloads to the new trust model. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Migration work often exposes or leaves behind credentials in code and config. |
| Recommendation — Search migration paths for exposed credentials and eliminate them before cutover. | ||
