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 Data Cleansing and Migration Planning Decide Whether a Greenfield ERP Launch Starts Clean
A Greenfield ERP programme is supposed to reset process debt, but the reset only works if the underlying data is made trustworthy before cutover. When cleansing is underfunded, organisations often carry forward duplicate suppliers, inconsistent product codes, mismatched customer records, and unclear ownership of reference data. That creates immediate friction in finance, supply chain, and reporting because the new platform is being asked to automate bad inputs instead of clean ones. NIST’s control catalogue shows why data integrity and system preparation are treated as operational control issues, not just project hygiene, because weak preparation affects how reliably systems can enforce business process and record accuracy. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because data quality failures become control failures once the new ERP is live. In practice, many teams only discover the scope of bad migration data after users begin reconciling exceptions in production.
How the Failure Spreads Across the New ERP Environment
data cleansing and migration planning are not just about moving rows from one database to another. They are about deciding which records are authoritative, which fields are mandatory, how duplicates are resolved, and what must be retired rather than copied forward. In a Greenfield erp transformation, those choices shape master data, transactional history, integrations, reporting logic, and downstream approvals. If the migration plan is vague, teams can end up with records that technically load but do not support day-to-day operations.
The failure usually appears in a few predictable ways. First, reporting becomes unreliable because the same entity is represented multiple times or mapped inconsistently. Second, integrations break because source and target values do not align, especially where legacy codes were never standardised. Third, process owners lose confidence when users see obvious errors in the new system, which drives workarounds outside the ERP and weakens adoption. Fourth, exception handling becomes the norm because the business must keep fixing data that should have been cleaned before go-live.
Good migration planning therefore has to define scope at the record level. Teams need to know what data is migrating, what is being reclassified, what is being archived, and what must be re-created in the new model. The most important check is not whether data can be loaded, but whether it is usable once it arrives. That usually means validating master data ownership, reconciliation rules, transformation mappings, and cutover dependencies before any final load. Where the ERP also supports finance or regulated operations, the issue extends beyond convenience because inaccurate records can affect traceability, auditability, and control evidence. The guidance breaks down when an organisation treats migration as an IT extraction exercise instead of a business data stewardship exercise.
Where Greenfield Programmes Still Go Wrong at the Edges
Tighter cleansing often increases project effort, so organisations have to balance schedule pressure against the cost of importing ambiguity into the new platform.
There is no single consensus on how much historical data should move in a Greenfield ERP design. Some organisations keep only open items and essential reference data, while others preserve broader history for analytics, legal retention, or operational continuity. The right answer depends on reporting obligations, audit needs, and how much legacy complexity the business can actually absorb. A common mistake is to assume that more migrated history automatically improves continuity. In reality, poorly structured history can slow testing, distort metrics, and complicate user training.
Another edge case is merged or duplicated entities, especially in customer, supplier, and material master records. If teams compress several legacy records into one target record without clear governance, they may resolve one problem while creating a new one in credit, procurement, or fulfilment workflows. Another issue is data owned by multiple functions. Finance, operations, and IT may each believe they are validating the same record set, but without explicit accountability the migration can ship with contradictory assumptions. For highly customised legacy landscapes, the cleansing burden is often larger than anticipated because local exceptions were never documented well enough to map cleanly into the new model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | ERP migrations fail when target data and mappings are not standardised and controlled. |
| 8 — Audit Log Management | Dirty migrations obscure traceability when records and transformations are not auditable. | |
| Recommendation — Standardise migration mappings and baseline target data before cutover. Retain transformation evidence for loaded, rejected, and remapped records. | ||
| NIST CSF 2.0 | ID.AM-2 — Hardware, software, data, and external systems are inventoried | Migration planning depends on knowing what data exists and what is moving. |
| PR.DS-1 — Data-at-rest is protected | ERP transformations require trustworthy handling of sensitive and operational data sets. | |
| GV.RM-05 — Risk responses are identified and prioritized | Underinvestment creates governance risk that must be prioritised before go-live. | |
| Recommendation — Inventory source data, interfaces, and legacy dependencies before migration. Protect migrated datasets and verify integrity during transfer and load. Prioritise cleansing risks by business impact and cutover dependency. | ||
| ISO/IEC 42001:2023 | 6.1 — Actions to address risks and opportunities | Greenfield ERP change requires managed governance of data-related transformation risk. |
| Recommendation — Address data-quality risks as part of programme governance and decision-making. | ||
| DORA | ICT third-party risk management — ICT third-party risk management | ERP programmes often depend on external implementation and migration partners. |
| Recommendation — Control vendor-led migration dependencies and validate their data handling outputs. | ||
Practitioner Guidance
What to prioritise: Treat master data and migration scope as business design decisions, not technical housekeeping. The first question is which records must be authoritative on day one, because that determines whether cleansing work is focused or diluted across low-value data.
What to verify: Confirm that each critical object has an owner, a deduplication rule, a transformation rule, and a retirement rule. If any of those four is missing, the migration is not ready for final cutover even if the load succeeds.
What good looks like: The target ERP can support core transactions, reconciliations, and reporting without manual repair workarounds, and users can explain why the loaded data is trustworthy. The practical test is whether exception volume falls after go-live rather than becoming the operating model.
Practitioner takeaway: The real risk is not simply bad data, but institutionalising bad data inside a brand-new platform that is harder to correct once business processes depend on it.
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 keep relying on batch processing and fragmented data in ERP operations?
- How should organisations replace legacy ERP access controls without creating audit gaps during migration?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
