---
title: "What Data Should You Actually Migrate to Your New ERP?"
slug: what-data-should-you-actually-migrate-to-your-new-erp
date: 2026-05-04
author: Raaj
categories: [General]
excerpt: "Most ERP migrations fail because of scope, not technology. Use this four-bucket framework to decide what data to migrate, archive, or leave behind."
tldr: "Migrate clean master data and open transactions live, bring 3–5 years of GL summaries, archive everything else outside the ERP, and destroy what's past retention."
canonical: https://clonepartner.com/blog/what-data-should-you-actually-migrate-to-your-new-erp/
---

# What Data Should You Actually Migrate to Your New ERP?


Almost every ERP project starts with the same promise: "we'll migrate everything." Almost every one regrets it. The scope of your data migration — not your chart of accounts design, not your workflow configuration — is the single decision most likely to determine whether your project ships on time, passes UAT, and stays within budget.

The problem is structural. Your implementation partner is incentivized to say yes to more scope because more scope means more billable hours. Nobody pushes back on migrating 15 years of closed purchase orders until the project is six weeks late and the cutover window has blown past. By then the damage is done. For a deeper look at why splitting data migration from implementation reduces risk, see [Why Data Migration Isn't Implementation](https://clonepartner.com/blog/blog/data-migration-vs-implementation-guide/).

Modern cloud ERPs are not filing cabinets. They are high-performance transactional engines. Treating them like a cheap data dump costs you in licensing, storage, and operational drag. Microsoft's own Dynamics guidance says not to migrate more data than users need. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/performing-solution-design-for-performance?utm_source=openai))

This guide gives you a framework for deciding exactly what goes into your new ERP, what stays behind, and what gets archived — before the first line of migration code is written.

## The Scope Creep That Kills ERP Projects Before Kickoff

**ERP data migration scope** is the exact set of objects, history depth, transformation rules, and validation tests that will exist in production at cutover. Most projects begin with a bad default: "let's migrate everything so nobody loses access." It sounds safe. In practice it bloats storage, stretches cutover, and makes the new ERP inherit every duplicate vendor, stale SKU, and broken naming convention from the old system.

The consequences are predictable:

- **Longer cutover windows.** Every additional data object adds extraction, transformation, validation, and reconciliation work to a cutover that was already tight.
- **More UAT failures.** Dirty historical data generates false negatives in testing. QA teams waste cycles chasing data defects instead of testing business processes.
- **Higher cloud storage costs.** Quantifiable and brutal — we break this down below.
- **Slower system performance.** A cloud ERP loaded with 20 years of closed transactions is slower to query, harder to upgrade, and more expensive to operate than one loaded with only what the business needs today.

> [!WARNING]
> If "historical data" is one line in your SOW, push back. History depth must be defined per object: GL, AR, AP, inventory, purchasing, fixed assets, employees, attachments, and notes.

Most failed migrations are scoped to fail before kickoff. The fix is not better tooling. The fix is a better framework for deciding what moves.

## The Four-Bucket Framework for ERP Data Migration Scope

Every data object in your legacy system belongs in one of four buckets. This framework works regardless of whether you are moving from GP to Business Central, SAP to Dynamics 365 F&O, or NetSuite to BC.

Microsoft's built-in migration paths from Dynamics GP and QuickBooks are selective by design — they focus on master records, open documents, on-hand inventory, beginning balances, and optional chosen history, not a blind copy of every legacy record. That is a strong clue about what belongs in a live ERP. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-dynamics-gp?utm_source=openai))

| Bucket | Action | Typical Data |
|---|---|---|
| **1. Migrate live, structured** | Load into the production ERP | Active customers, vendors, items, COA, dimensions, open AR/AP, open SO/PO, current + prior FY GL detail |
| **2. Migrate as summary** | Load balances, not line-level history | Closed-period GL balances, monthly trial balances, historical aging snapshots, year-end balances for 3–5 years |
| **3. Archive, queryable** | Keep searchable outside the live ERP | Closed transactions older than 2 years, terminated employees, inactive vendors, old inventory detail, attachments |
| **4. Don't migrate** | Leave in legacy or destroy per policy | Test data, draft transactions, duplicate records, system logs, expired records past retention |

### Bucket 1: Migrate Live, Structured

This is your operational data — the records your team uses on Day 1.

- **Master data:** Active customers, active vendors, current items, live Bills of Materials (BOMs), GL accounts, chart of accounts, dimensions/segments, payment terms, tax codes.
- **Open transactions:** Open sales orders, open purchase orders, open AP/AR invoices, unapplied cash, unreconciled bank transactions, active projects.
- **Current and prior fiscal year GL detail:** Full journal entry detail for the current FY and the immediately prior FY to support year-over-year operational reporting.

Every record you migrate must be extracted, mapped, transformed, validated, and loaded. If you migrate a closed purchase order from 2018, you must also migrate the vendor attached to it, the items on the lines, the tax schedules applied to it, and the GL accounts it hit. If any of those legacy master records violate the validation rules of your new ERP, the import fails. Keep Bucket 1 tight — this is the minimum viable data set.

### Bucket 2: Migrate as Summary

Historical data your finance team needs for comparative reporting, but does not need at the transaction level inside the new system. For a deeper dive into financial mapping risks, see [7 Costly Mistakes to Avoid When Migrating Financial Data](https://clonepartner.com/blog/blog/financial-data-migration-mistakes-to-avoid/).

- **Closed-period GL balances** for 3–5 prior fiscal years (period-end trial balances, not individual journal entries).
- **Historical aging snapshots** (AR/AP aging at each fiscal year end).
- **Historical item-level sales summaries** (e.g., total units sold per month per item) rather than individual posted sales shipments.

Summary balances give your CFO the ability to run comparative P&L and balance sheet reports without loading millions of individual transactions into the new environment.

### Bucket 3: Archive, Queryable

This data has legal or operational value but does not belong in your production ERP.

- Closed transactions older than 2 years (paid invoices, fulfilled sales orders, received POs).
- Detailed GL journal entries older than the prior FY.
- Terminated employee records.
- Inactive vendors and customers with no activity in 24+ months.
- Historical inventory transaction detail.
- Discontinued items.

The archive must be **queryable** — a read-only SQL database, an Azure Data Lake, or a purpose-built archive tool. Your auditors need to pull a specific invoice from 2021. They do not need that invoice inside your production ERP.

**Archive, queryable** is the part many partners under-design. A read-only legacy environment, replicated SQL database, historical company in your new ERP, or purpose-built archive can all work. The key is indexed retrieval by document number, date, entity, and amount.

### Bucket 4: Don't Migrate — Leave or Destroy

Data that has no legal retention requirement and no operational value.

- Test/sandbox data from your legacy system.
- Draft or voided transactions that were never posted.
- System logs, error tables, and staging tables from previous integrations.
- Expired records (warranties, contracts, temp vendor setups) past your retention policy.
- Duplicate and orphaned records that should have been cleaned up years ago.

> [!WARNING]
> Before destroying anything, verify your state-level retention requirements. Some states extend retention beyond federal minimums. When in doubt, archive to cold storage — don't delete.

## The 7-Year Audit Rule: Legal Requirement vs. Operational Reality

This is the argument that derails more scope conversations than any other: "We need 7 years of data for compliance."

The statement is partially correct, but stakeholders frequently misinterpret what it requires. IRS guidance is more nuanced than the blanket "7-year rule" suggests: many tax records follow a three-year baseline, six years can apply for substantial underreporting, seven years applies in certain loss-claim cases, and employment tax records must generally be kept for at least four years. Most CPAs advise keeping business financial records for at least 7 years as a practical safe harbor. ([irs.gov](https://www.irs.gov/businesses/small-businesses-self-employed/how-long-should-i-keep-records?os=vbkn42tqho5h1r&ref=app&utm_source=openai))

Here is the distinction that matters: **the IRS requires records to be accessible, not active.** The IRS does not require a specific kind of recordkeeping system — it says you may use any system adapted to your business that clearly shows income and expenses. For electronic records, the requirement is that they remain machine-readable, support the return, and preserve an audit trail. ([irs.gov](https://www.irs.gov/es/businesses/small-businesses-self-employed/recordkeeping?utm_source=openai))

There is no requirement that historical financial records reside inside your production ERP. A read-only legacy database, a SQL archive with proper access controls, or an Azure Data Lake with quarterly archive snapshots satisfies the retention requirement at a fraction of the cost.

The practical approach:

1. **Current + prior FY detail** → live in the new ERP (Bucket 1)
2. **3–5 years of summary balances** → migrated as summaries (Bucket 2)
3. **Full transaction detail for years 3–7** → queryable archive outside the ERP (Bucket 3)
4. **Keep your legacy system in read-only mode** for 12–18 months post-cutover as a safety net

> [!TIP]
> **The Audit Defense:** When auditors request historical detail, provide a direct export from your Bucket 3 archive. Document the exact date the legacy system was locked down and the exact query used to extract the archive. This proves data immutability better than a migrated record in a new ERP that could have been altered post-go-live.

## Master Data: The Silent Saboteur of Your Go-Live

If you get master data wrong, nothing else matters. Your GL balances will not reconcile. Your purchase orders will not post. Your AP team will be unable to pay vendors.

McKinsey reports that 82% of surveyed organizations spend at least one day per week resolving master data quality issues, and describes structured data management as make-or-break for deployment success. Organizations that prioritize data management see shorter deployment timelines and better testing productivity. ([mckinsey.com](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/master-data-management-the-key-to-getting-more-from-your-data?utm_source=openai))

The most common master data problems we see:

- **Duplicate vendors.** "Acme Corp," "ACME Corporation," "Acme Corp." — three records for the same entity, each with different payment terms and bank details.
- **Stale item costs.** Standard costs that have not been updated in years, causing immediate variances on Day 1.
- **Inconsistent customer records.** Four addresses for the same customer, with different tax IDs and credit limits across locations.
- **Orphaned GL accounts.** Chart of accounts entries that have not posted a transaction in 5+ years but are still marked "active."

A real-world case illustrates the scale of this risk: SPAR Group's SAP S/4HANA implementation at its KwaZulu-Natal distribution center in early 2023 resulted in what court documents describe as immediate failures in order picking, dispatch scheduling, inventory visibility, and pricing accuracy. The system was intended to centralize supply chain operations but failed due to poor data migration, warehouse integration problems, and inadequate change management. The project has cost an estimated R1.6 billion–R2 billion (~$85–107M USD) in lost turnover and profits.

**The fix:** Run a dedicated **master data cleanup sprint — 4 to 6 weeks minimum** — before any migration code is written. This sprint should include:

1. **Deduplicate:** Full deduplication pass on customers, vendors, and items in the legacy system.
2. **Validate:** Verify every active GL account against last 12 months of posting activity.
3. **Standardize:** Enforce strict formatting for addresses, tax IDs, naming conventions, and dimensional tags.
4. **Inactivate:** Flag obsolete items, closed warehouses, and dormant accounts.
5. **Assign owners:** A named business owner for each data domain signs off on their master data before migration starts.

> [!TIP]
> If no named business owner can approve a customer, vendor, item, or GL mapping rule, that object is not ready for migration.

Do not attempt to clean master data during the migration process. ETL scripts are not a substitute for data governance. If you skip this sprint, your migration engineers will spend their time writing complex, brittle mapping logic to handle exceptions that should have simply been deleted.

## The True Cost of Over-Migration: Storage, Speed, and Sanity

Cloud ERPs are not free storage lockers. The math on over-migration is brutal, especially on Microsoft's Dynamics 365 platform.

**Dataverse database storage costs $40 per GB per month** for add-on capacity. File storage runs $2/GB/month. For comparison, the same data in SharePoint costs roughly $0.20/GB/month — a 200x difference for structured data. Standard Azure SQL storage runs roughly $0.65/GB, and Azure Blob Storage costs fractions of a penny. ([microsoft.com](https://www.microsoft.com/licensing/guidance/Power-Platform?msockid=2bc9ae6427dd694936bdb89c26e168d0&utm_source=openai))

> [!CAUTION]
> 100 GB of extra structured history at Dataverse's published add-on rate is $4,000/month. 1 TB is $40,000/month. Storing dead data in a premium transactional database is financial malpractice. ([microsoft.com](https://www.microsoft.com/licensing/guidance/Power-Platform?msockid=2bc9ae6427dd694936bdb89c26e168d0&utm_source=openai))

> [!NOTE]
> Microsoft increased default Dataverse storage entitlements in December 2025 — but the add-on pricing of $40/GB/month for database storage has not changed. More free capacity does not change the economics of over-migration. It just delays when you hit the overage threshold.

Beyond storage, over-migration hits your project in three other ways:

- **Longer cutover windows.** A migration that moves only open AR, open AP, and active master data can execute in hours. A migration moving 15 years of line-level history can take days to run through the target ERP's API rate limits and posting validation logic. If your cutover script takes 72 hours, you have zero margin for error over a weekend go-live.
- **More reconciliation work.** Every migrated data set must be validated. More data means more validation and more places for discrepancies to hide.
- **Higher UAT failure rates.** Dirty legacy data mixed with clean new data generates false test failures that erode confidence in the system.

| Factor | Over-Migration | Strategic Archiving |
|---|---|---|
| Cloud storage cost | $40/GB/mo (Dataverse DB) | $0.02–$0.20/GB/mo (Azure Blob/SQL) |
| ERP query performance | Degraded by historical volume | Optimized for operational data only |
| Cutover window | 48–72+ hours | 12–24 hours (less data to load) |
| UAT defect rate | Higher (dirty legacy data) | Lower (clean, scoped data) |
| Audit readiness | Data in ERP but hard to navigate | Dedicated archive, purpose-built queries |
| Future upgrades | Slower (more data to validate) | Faster (lighter footprint) |

STAEDEAN, a third-party ISV specializing in Dynamics 365 migrations, reports that their configurable AX-to-D365 templates can reduce migration timelines from 116 days to 44 days. Treat that as vendor-reported data, not a neutral benchmark. Even so, the direction is right: selective, configurable migrations beat bespoke "move everything" programs. ([staedean.com](https://staedean.com/blog/microsoft-dynamics-365-erp-trends?utm_source=openai))

## Specific Data Scope Guidance for Common ERP Moves

Every ERP pair has its own architectural quirks. Here is what we recommend based on real project experience.

### GP → Business Central

Moving from GP's Dexterity-based architecture to BC's AL-based architecture requires careful handling of financial dimensions. Microsoft's own migration tool supports setting an "Oldest GL Year" to limit historical depth — use it. You can choose active vs. all customers, vendors, and items, and keep deeper history in GP Historical Snapshot extension tables for reporting. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-dynamics-gp?utm_source=openai))

**Bring:** Active master records, open transactions (unapplied AR/AP), current + prior FY GL detail, GL summary balances for 3–5 years.

**Leave behind:** Full GL detail older than 2 FYs, closed AP/AR transactions, historical inventory detail. Keep GP running in read-only mode or push your history into a separate "Historical Company" within BC, or an Azure Data Lake.

For the full technical breakdown, see [Dynamics GP to Business Central: Migrating 20 Years of History](https://clonepartner.com/blog/blog/dynamics-gp-to-business-central-migrating-20-years-of-history/).

### NAV → Business Central

NAV's dimension structure maps more cleanly to BC than GP's does, but this is still modernization, not raw copying. Microsoft is explicit that data from tables with code customizations cannot be carried forward to Business Central online. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-nav?utm_source=openai))

**Bring:** Master data, open transactions, 2 years of GL detail. **Leave behind:** Historical job costing detail, closed warehouse entries, superseded BOMs, bespoke table history (unless the custom process is being rebuilt as an extension).

### SAP ECC → Dynamics 365 F&O

SAP and D365 use fundamentally different relational models. You cannot push SAP tables directly into D365 using standard ETL pipelines. D365's import model is built around data entities and entity/table validations, not direct table copies. D365 generates unique RecIDs for every record and validates financial dimensions on every posted transaction. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/data-entities?utm_source=openai))

Attempting to migrate historical SAP material documents or FI/CO documents line-by-line will result in API throttling and validation failures. If dual-write is involved, Microsoft warns that migration performance will be poor if maps are activated before migration is complete; initial synchronization is capped at 500,000 rows per run.

**Bring:** Business partners, product masters, open AR/AP, open sales and purchase documents, current FY GL. **Leave behind:** SAP transport logs, closed CO postings, historical MM/SD movements, old FI line items.

For the full SAP migration playbook, see [SAP ECC to Dynamics 365: The 2027 Data Migration Playbook](https://clonepartner.com/blog/blog/sap-ecc-to-dynamics-365-the-2027-data-migration-playbook/). For technical execution details on bypassing standard bottlenecks, see [Migrating Dynamics 365 On-Premise to Cloud](https://clonepartner.com/blog/blog/dynamics-365-on-premise-to-cloud-migration/).

### NetSuite → Business Central

NetSuite's subsidiary structure does not map 1:1 to BC's multi-company architecture — each subsidiary typically becomes a separate BC company. When extracting data, you must carefully segment records by subsidiary before mapping to the target BC companies. NetSuite governs RESTlets and web services at the account level, and requests that exceed concurrency limits are blocked — making cold-history extraction a great way to burn cutover time. ([docs.oracle.com](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_1500275531.html?source=%3Aem%3Anw%3Amt%3A%3Arc_wwmk180514p00061%3Ansl100768561&utm_source=openai))

**Bring:** Active customers, vendors, items, chart of accounts, open subledger transactions, current + prior FY GL. **Leave behind:** Saved searches, custom record history, SuiteScript execution logs, closed transactions older than 2 FYs.

See [NetSuite to Dynamics 365 Business Central Migration: Technical Guide](https://clonepartner.com/blog/blog/netsuite-to-dynamics-365-business-central-migration-technical-guide/) for the full treatment.

### QuickBooks → Business Central

This is typically the cleanest migration because QuickBooks has less history depth. Microsoft's QuickBooks Online migration extension imports customers, vendors, items, chart of accounts, the beginning-balance GL transaction, on-hand inventory, and open customer/vendor documents. It does **not** automatically adjust partially paid amounts — that is basically Microsoft spelling out the right live scope for a typical SMB move. ([learn.microsoft.com](https://learn.microsoft.com/en-ca/dynamics365/business-central/ui-extensions-quickbooks-online-data-migration?utm_source=openai))

**Bring:** Chart of accounts, customer/vendor list, open invoices, and a beginning balance journal entry. **Leave behind:** PDF attachments and notes should go to SharePoint, not Dataverse.

## The 1-Page ERP Data Migration Scoping Template

Before your implementation partner writes the first line of migration code, you need a scoping document that is precise, not long. Every object in scope should have defined attributes. If a data entity is not on this document, it does not get migrated.

```yaml
object: Vendor master
bucket: 1 - Migrate live, structured
history_depth: Active vendors plus inactive vendors with open balance or activity in last 24 months
source_of_truth: Legacy ERP AP vendor table
owner: AP manager
transform_rules:
  - merge duplicates by tax ID and remit-to logic
  - standardize payment terms and country codes
  - retire vendors with no activity and no retention requirement
validation:
  - record counts by status
  - sample field-by-field checks
  - open balance reconciliation
archive_location: Read-only legacy SQL archive
cutover_method: Full load plus final delta at T-1
```

Your template should capture these fields for every major data entity:

1. **Data entity** — The specific object (e.g., Open Accounts Receivable, Active Customers, Item Master).
2. **Bucket** — Which of the four buckets it falls into.
3. **History depth** — How many fiscal years of detail, or the exact inclusion filter (e.g., "Unapplied amount > 0").
4. **Source of truth** — Which system is authoritative (especially important with multiple legacy systems).
5. **Business owner** — The named individual responsible for validating this data during UAT.
6. **Transform rules** — Deduplication, mapping, and formatting logic.
7. **Validation method** — Record counts, hash totals, balance reconciliation, sample-based spot checks.
8. **Archive strategy** — Where non-migrated data will live and who can access it.

By forcing stakeholders to put their name next to a data entity, you rapidly eliminate requests for "nice to have" historical data. When the Controller realizes they personally have to validate 15 years of migrated journal entries, they quickly agree to an archive strategy.

If your implementation partner cannot produce this document before the project starts, that is a red flag. You are about to scope the project by accident instead of by design.

## The Decision That Saves ERP Projects

Your new ERP should be a clean operating system, not a museum.

ERP data migration is a highly specific engineering challenge that requires strict boundary setting, deep knowledge of target API constraints, and the willingness to tell stakeholders "no" when they ask to migrate dead data. By enforcing the four-bucket framework, mandating a master data cleanup sprint, and isolating historical data in low-cost archives, you protect your ERP investment. The new system launches fast, stays lean, and operates as designed.

If your current partner's scope cannot explain these choices object by object, stop before build starts. That is the cheapest moment to fix the plan.

> Scoping your ERP data migration? ClonePartner acts as your independent data engineering team — separate from your implementation partner. We enforce the four-bucket framework, run the master data cleanup sprint, build extraction and transformation scripts, and own the reconciliation. Book a 30-minute technical scoping call to walk through your data inventory before your implementation kicks off.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Should I migrate inventory transaction history to my new ERP?

No. Migrate current on-hand quantities, item master data, and open inventory-affecting transactions. Historical receipts, adjustments, and transfers older than 2 years have no operational value in the new ERP. Archive them in a queryable database for audit access.

### How far back should I migrate GL detail?

Bring full journal entry detail for the current and prior fiscal year into the live ERP. Migrate 3–5 additional years as period-end summary balances only. Archive older detail in a read-only SQL database or data lake.

### Do auditors require 7 years of data inside the new ERP?

No. The IRS requires records to be retained and accessible, not active in your production ERP. A read-only archive with proper access controls, a documented chain of custody, and a reconciliation tying archive totals to the last legacy trial balance satisfies the requirement.

### What should happen to email attachments and notes during an ERP migration?

Migrate only attachments tied to open work, active disputes, compliance evidence, or live contracts. Archive the rest. If attachments go into Dataverse, they eat database storage at $40/GB/month — route them to SharePoint or Azure Blob instead. Text-based notes are small and can be migrated as fields.

### How much does Dynamics 365 Dataverse storage cost per GB?

Dataverse database storage costs $40 per GB per month for add-on capacity. File storage is $2/GB/month. By comparison, SharePoint storage is roughly $0.20/GB/month and Azure Blob is fractions of a penny — making Dataverse up to 200x more expensive for storing historical data.