Code-based migration packages security changes with the application and promotes them through the standard deployment process. Manual export and import is used when changes were made through the security interface and are not part of the codebase. The first is more controlled and repeatable, while the second is useful for exceptions that need explicit handling.
How code-based migration differs from manual security export and import
Code-based migration treats security as part of the application lifecycle. Roles, duties, duty assignments, or other security artefacts are represented in source control and moved with the code through the normal build and deployment path. Manual export and import is a configuration transfer method, used when security changes were made in the D365 Finance and Operations interface and need to be moved outside the codebase.
The practical difference is traceability and repeatability. Code-based migration is versioned, reviewable, and aligned to the same promotion path as other changes, while manual export and import is more of an exception-handling mechanism for changes that were created interactively and must be captured after the fact.
When each approach is the right fit
Use code-based migration when security is part of the intended solution design and should be deployed consistently across environments. That approach works best when teams want the security model to be treated like any other application asset, with predictable release management and fewer environment-specific surprises.
Use manual export and import when the change already exists in the environment through the user interface and is not yet represented in code. It is also the safer choice when you need to move a one-off adjustment, a production exception, or a locally handled security fix without delaying it until the next code release.
In practice, the right question is not which method is simpler, but which method preserves the source of truth. If the long-term owner expects security to be maintained as part of the solution, code should become the authoritative record. If the change is intentionally operational and temporary, manual handling may be appropriate, but it should remain tightly controlled.
What the difference means for release control and supportability
Code-based migration usually gives better change control because it fits standard promotion, testing, and rollback processes. It is easier to compare between environments, easier to review for unintended privilege changes, and easier to support when auditors or admins need to understand why a security state exists.
Manual export and import can be effective, but it introduces a dependency on the correctness of the exported artefact and on disciplined environment management. If the same security change is later recreated in code, teams need to avoid duplicates, drift, or confusion about which version is authoritative. That is where change ownership and documentation become important.
For teams working in regulated or highly controlled environments, the key operational concern is consistency. Security moved through code tends to be more repeatable; security moved manually tends to be more situational. The distinction matters because the same role change can look harmless in isolation but create governance gaps if it is not tracked and promoted deliberately.
Risk and Threat Considerations
Security moved outside the codebase can drift from the intended design, especially when different environments accumulate ad hoc exceptions. That creates the usual risks of inconsistent privilege, hidden dependencies, and harder-to-review access changes, particularly when the manual path becomes a habit rather than a rare exception.
Failure mechanism: A security change made in the UI can bypass the normal review and deployment chain, leaving the promoted environment out of sync with source-controlled security design or creating a duplicate control path that no one owns clearly.
Impact: The result can be unintended access, inconsistent behaviour between environments, longer troubleshooting cycles, and weaker audit evidence about who approved the final security state.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Security migration is a change-control problem. |
| CM-5 — Access Restrictions for Change | Security exports and imports should be restricted and approved. | |
| Recommendation — Route security changes through approved change control and keep promotion evidence with the release. Limit who can export, import, and modify security settings. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | The question is about controlled versus manual promotion of security changes. |
| A.8.9 — Configuration management | Security artefacts need an authoritative, versioned configuration path. | |
| Recommendation — Manage security changes through documented change approval and testing. Keep migrated security settings under configuration control and reconcile drift. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The topic is about preserving consistent security configuration across environments. |
| Recommendation — Standardise security configuration and track deviations from the baseline. | ||
Practitioner Guidance
What to prioritise: Decide early which security objects belong in source control and which are legitimate operational exceptions. If a security change is expected to persist, promote it into code as soon as possible so the deployed state and the design state stay aligned.
What to verify: Before trusting a manual export and import, confirm that the exported security set matches the intended delta and does not carry forward unrelated interface changes. After deployment, verify that the target environment reflects the same role and permission outcome as the source.
Common mistake: Treating manual import as a permanent shortcut. That usually leads to drift, unclear ownership, and later redeployment problems when the codebase and the live security model no longer agree.
Practitioner takeaway: Use code as the preferred long-term source of truth, and reserve manual export and import for controlled exceptions that must be explicitly reconciled back into the application lifecycle.
Related resources from NHI Mgmt Group
- What is the difference between policy as code and manual security governance in cloud operations?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between code risk analysis and compromise assessment in security operations?
- What is the difference between cloud-native security automation and traditional manual security operations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
