D365 Finance and Operations Data Migration: What to Move, Archive or Retire

A D365 Finance and Operations data migration involves more than transferring records from a legacy ERP to a new system. Teams must decide which data is essential for day-to-day operations, which information must remain available for historical reference, and which records no longer have a valid business purpose.

Moving everything can increase complexity, preparation effort, and cost. Removing too much can create gaps in reporting, audit readiness, financial reconciliation, and business continuity. The better approach is to classify each data category as migrate, archive, or retire based on business requirements, dependencies, retention obligations, and future access needs—not simply on age or volume.

Quick answer: What should you migrate, archive, or retire?

The correct decision depends on how the data is used, what depends on it, and who is accountable for approving its disposition. An inactive record may still be financially or contractually important, and an old transaction is not automatically safe to delete.

1. The three-way ERP data disposition framework

Every data category in the migration scope should have a documented disposition. The table below provides a starting point for project workshops; the final decision should be approved by the relevant business owners.

These decisions require business judgment as well as technical analysis. Migration tools can transfer or transform data, but they cannot independently determine whether records are still needed or whether retention obligations have been satisfied.

• Inactive does not mean unnecessary. An inactive customer or vendor may still be linked to an outstanding balance, credit, dispute, or contractual obligation.
• Old does not mean safe to delete. Historical transactions may be required for audit, tax review, disputes, financial reconciliation, or internal reporting.

Microsoft’s data migration guidance recommends defining relevant migration data around business requirements. The final scope should also reflect your organization’s operating model and applicable compliance requirements.

Reference: Data migration for Dynamics 365 implementation projects

2. Six questions to guide data disposition

Before deciding what to migrate, archive, or retire, evaluate each data category against six questions. Record the answer, supporting evidence, and decision owner in the migration register.

Is it required for day-one operations?

Identify the records needed to process transactions, manage inventory, pay suppliers, collect receivables, and run essential business processes after go-live.

Does another record or process depend on it?

Check links to open transactions, active master data, financial settlements, reports, integrations, and downstream systems before excluding a record.

Must it remain available for audit or compliance?

Confirm applicable retention periods, contractual commitments, legal holds, audit requirements, and internal policies with Finance, Compliance, and legal stakeholders as appropriate.

Does it need to reside in the operational ERP?

Determine whether users need the information for routine transactions or whether an approved archive or reporting environment can meet the need.

Can archived information be retrieved when required?

Test search, reporting, security, retrieval time, and preservation of relationships and context. An archive is useful only if authorized users can access and interpret the information.

Who approves the decision?

Assign a business owner and document the rationale. IT and migration specialists can advise on feasibility, but disposition decisions should not be made solely for technical convenience.

This process helps teams avoid blanket rules, such as automatically migrating the last five years of data regardless of business need. Retention and access requirements vary by organization and jurisdiction, so obtain the right compliance input before authorizing retirement.

3. Three practical ERP data migration scenarios

The right decision depends on how the information is used, not just which module or table contains it. These illustrative scenarios show how the same migrate/archive/retire framework can apply to different data types.

Scenario A: Closed financial transactions

A company moving from Dynamics AX 2012 has eight years of posted financial transactions. Finance needs opening balances and current information in D365 Finance and Operations, while auditors may need access to older transaction details.

A practical approach could be:

• Migrate opening balances and historical detail required for agreed operational, reporting, and reconciliation needs.
• Archive older transactions that must remain accessible but are not needed for routine processing.
• Retire redundant copies only after retention, reconciliation, ownership, and dependency checks are complete.

The number of historical years to migrate should follow business and reporting requirements rather than an arbitrary time limit.

Scenario B: Inactive customers and vendors

A legacy ERP may contain thousands of accounts that have not been used recently. Some are genuinely obsolete; others may be linked to outstanding invoices, credits, disputes, or contractual obligations.

• Migrate active accounts and inactive accounts with open balances or continuing obligations.
• Archive historical account information required for reference or compliance but not for new transactions.
• Retire verified duplicates or redundant records after dependencies and retention obligations have been resolved.

An inactivity date can help identify records for review, but it should not determine the final outcome on its own.

Scenario C: Historical inventory and temporary data

Manufacturers and distributors may hold years of inventory movements alongside temporary extracts, test loads, and intermediate datasets. Current stock, open inventory transactions, and required traceability information may need to be migrated. Historical movements may be better suited to an archive if they are needed only for investigation or periodic reporting. Temporary files and redundant extracts may be retired after confirming they are not required records and have no remaining dependencies.

The decision should reflect inventory controls, traceability needs, reporting requirements, and approved retention policies.

4. Create a data disposition register

A data disposition register turns the framework into an actionable and auditable process. It gives the project team a consistent record of what will happen to each data category, why the decision was made, and who approved it.

Review the register with the relevant business owners and update it as discovery identifies additional dependencies. This gives Finance, Operations, IT, and Compliance a shared basis for approving migration scope and documenting why data was retained, moved elsewhere, or approved for retirement.

5. Validate disposition decisions before cutover

Successful data migration is not just about transferring selected records accurately. The project must confirm that the correct data was selected and that information excluded from the new ERP remains accessible when required.

Before cutover, verify the following:

• Operational completeness: Required master data, open transactions, balances, and dependencies are present in the target system.
• Financial integrity: Relevant opening balances and financial totals reconcile with approved source figures, and exceptions are documented.
• Historical accessibility: Authorized users can retrieve archived information and produce required reports within an acceptable timeframe.
• Retirement approval: Proposed deletions have passed retention, legal-hold, ownership, and dependency checks, with approval documented.

Include these checks in migration testing and formal business sign-off. Microsoft’s data management and governance checklist is a useful reference for migration planning, data quality, ownership, and control requirements.

Reference: Checklist for data management and governance

6. What to know about Microsoft Dynamics 365 archiving

An archive strategy does not automatically mean that every legacy record can be moved into a single native Microsoft archiving feature. Microsoft documents specific Finance and Operations archiving capabilities for supported functional scenarios and data types. Confirm current feature availability, prerequisites, and supported scenarios before designing the archive approach.

For data that is outside a supported native archiving scenario, an approved archive or reporting environment may be needed. Whatever solution is selected, confirm that authorized users can retrieve the required records, understand their context, and meet the organization’s retention and access requirements.

Microsoft reference: Archive data in Dynamics 365 Finance and Operations apps with Dataverse

7. Pre-migration checklist

Use this checklist before approving the migration scope and cutover plan:

• The source systems, entities, data volumes, and key dependencies are documented.
• Business owners have approved what will be migrated, archived, and retired.
• Open transactions, opening balances, and day-one requirements are confirmed.
• Retention periods, contractual requirements, legal holds, and internal policies have been reviewed by appropriate stakeholders.
• Archive destinations, access controls, search, and reporting have been tested.
• Data mapping, cleansing, transformation, and reconciliation rules are documented.
• Proposed retirement has passed ownership, retention, and dependency checks.
• Cutover responsibilities, validation evidence, exception handling, and formal sign-off are agreed.

8. Frequently asked questions

What data should be migrated to D365 Finance and Operations?

Typically, migrate the configuration and master data, open transactions, opening balances, and other records required for agreed business processes. The final scope depends on operational, reporting, reconciliation, and compliance requirements.

Should historical ERP transactions be migrated or archived?

Migrate historical transactions when they are needed in the operational ERP or for agreed reporting and reconciliation. Archive them when they must remain accessible but are not required for routine processing. Confirm retention and retrieval requirements before deciding.

When can legacy ERP data be retired?

Only after the business owner confirms that the data has no remaining operational, reporting, legal, contractual, audit, or other approved purpose. Retention obligations, legal holds, and technical dependencies must be checked before retirement is authorized.

Does Microsoft Dynamics 365 support data archiving?

Microsoft documents archiving capabilities for specified Finance and Operations scenarios and data types. Feature availability and prerequisites can vary, so check the current Microsoft documentation and confirm whether the data in scope is supported.

How do you prove the migration scope is complete?

Reconcile required opening balances and financial totals, verify that open transactions and master data are present, test critical dependencies, confirm archived records can be retrieved, and retain business-owner approval for any exceptions or data retirement.

Conclusion: Make data disposition a business decision

The goal of D365 Finance and Operations data migration is not to minimize data at any cost. It is to ensure that the new ERP contains what the business needs to operate, that historical information remains accessible for legitimate purposes, and that obsolete data is handled responsibly.

Achieving this requires early collaboration between business owners, Finance, IT, data governance, and migration specialists. Classify data before migration begins, document decisions, validate access and reconciliation, and retire records only after the right approvals.

LGSTech helps organizations assess legacy ERP data, define migration scope, and plan data migration and validation. Talk to a data migration expert to discuss your data requirements and migration risks.