Poor data preparation can contaminate the new system from day one. Inconsistent master data, duplicate records, and unclear migration scope can disrupt reporting, create integration errors, and undermine user trust in the platform. If teams do not validate what data moves, what is retired, and what is remapped, the new environment may inherit the same operational problems in a different form.
Why This Matters for Security Teams
A Greenfield ERP transformation is supposed to reset the operating model, but underinvesting in cleansing and migration planning usually preserves the worst parts of the legacy estate. Dirty master data, duplicate customer and supplier records, and unclear cutover rules can distort financial reporting, break downstream integrations, and create access or segregation issues that are hard to unwind after go-live. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is clear that integrity, accountability, and configuration discipline are not optional controls. NHIMG research shows the same pattern in identity-heavy environments: only 5.7% of organisations have full visibility into service accounts, and 97% of NHIs carry excessive privileges, which is a useful warning sign for any transformation that relies on automated interfaces and migrated entitlements. The lesson is simple: if the migration plan does not define what is cleaned, what is remapped, and what is retired, the new ERP will inherit legacy risk at production speed. In practice, many security and transformation teams discover the quality problem only after reporting defects and user workarounds have already become normalised.
How It Works in Practice
Effective Greenfield planning starts before data moves. Teams should classify source data by business criticality, regulatory impact, and technical dependency, then establish explicit rules for standardisation, deduplication, archival, and rejection. That means deciding whether a field is authoritative, whether a record survives if it fails validation, and whether an integration should be remapped or retired. Governance needs both business ownership and technical enforcement, because migration failures often come from ambiguity rather than tooling.
A practical approach usually includes:
- Data profiling to identify nulls, outliers, duplicates, and conflicting keys before extraction.
- Master data stewardship so that customer, supplier, product, and chart-of-account records have named owners.
- Migration mock runs to validate transformation logic, reconciliation reports, and rollback criteria.
- Cutover controls that separate data readiness from process readiness and prevent last-minute scope creep.
For security-sensitive objects such as roles, service accounts, tokens, and integration credentials, the migration plan should align with identity controls rather than treating them as ordinary records. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports integrity checks, least privilege, and traceable change control, while NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results shows why this matters when machine identities are already hard to inventory and rotate. If the organisation cannot prove which data was cleansed, which entitlements were migrated, and which interfaces were decommissioned, the ERP cutover becomes a trust exercise instead of a controlled control point. These controls tend to break down when multiple workstreams share the same migration window because ownership gaps make exception handling indistinguishable from approved scope.
Common Variations and Edge Cases
Tighter cleansing often increases programme cost and delays, so organisations must balance data purity against operational continuity. Current guidance suggests that the right level of cleansing depends on the risk profile of the dataset, not on a blanket “perfect data” target.
Some environments need more aggressive pre-migration remediation than others. Highly regulated sectors may need traceability for every transformed record, while fast-moving commercial rollouts may tolerate limited historical data and archive the rest. There is no universal standard for how much historical data must move into a Greenfield ERP, but the decision should be explicit and documented. Special care is needed when legacy systems contain overlapping account structures, shadow integrations, or manually maintained spreadsheets that bypassed formal governance.
NHIMG research also shows why underestimating machine-related data matters: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 71% of NHIs are not rotated within recommended time frames. That makes migration scope a security decision, not only a business one. If access objects, secrets, and integration mappings are copied without validation, the new platform can launch with inherited privilege sprawl and hidden dependencies. Best practice is evolving, but the operational rule is stable: migrate only what is validated, retire what is obsolete, and reconcile everything else before go-live.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-2 | Data integrity and validation are central to avoiding contaminated ERP migrations. |
| NIST SP 800-53 Rev 5 | CM-2 | Baseline configuration control maps to migration scope and approved system state. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Migration often moves machine identities and secrets that need controlled lifecycle handling. |
| NIST AI RMF | Risk governance helps classify migration errors by impact, likelihood, and accountability. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust limits blast radius when migrated data or entitlements are wrong. |
Assign owners for migration risk decisions and require documented acceptance for exceptions.
Related resources from NHI Mgmt Group
- How should organisations manage access risk during Oracle ERP Cloud migration and transformation projects?
- What breaks when migration planning does not account for data mapping and access controls in SAP transformation projects?
- What breaks when organisations rely only on segregation of duties checks in ERP cloud security?
- What do organisations get wrong about protecting personal data inside ERP systems?
