SOX-Compliant ERP Migration: Maintaining Audit Trails in Dynamics 365

An ERP migration is one of the highest-risk events in a public company's control environment. It is, by definition, a change to your Internal Control over Financial Reporting (ICFR) — the exact thing SOX Section 404 requires you to assess, document, and have your external auditor attest to. Get it wrong and you face a material weakness disclosure in your 10-K, investor confidence erosion, and audit fees that spiral. Get it right and you have modernized your financial systems without a single auditor finding.

This guide covers the specific controls, documentation, evidence packages, and timing strategies that CFOs, Controllers, and SOX compliance owners need to execute a SOX-compliant ERP migration to Dynamics 365 — without triggering a material weakness.

Why an ERP Migration Is a SOX 404 Event

Internal Control over Financial Reporting (ICFR) is the set of processes designed to ensure financial statements are reliable and accurate. SOX Section 404(a) requires management to assess ICFR effectiveness annually. Section 404(b) requires an independent public accounting firm registered with the PCAOB to audit the effectiveness of ICFR and provide a report in the company's Form 10-K. The presence of Section 404(b) requirements significantly increases the complexity and resource intensity of compliance.

An ERP migration changes the system that generates, processes, and stores your financial data. That makes it a control change — and your auditors will treat it as one. The SEC has noted in comment letters: "You disclose that you substantially completed the implementation of your new Enterprise Resource Planning System ('ERP')... and the implementation of this System has affected and will continue to affect your internal controls over financial reporting."

This is not theoretical risk. In a real SEC 8-K filing, a company reported two material weaknesses in internal controls over financial reporting arising from an ERP implementation, specifically citing "ineffective design and implementation of IT general controls for information systems that are relevant to the preparation of financial statements." The company warned that inability to remediate could "negatively affect the market price and trading liquidity" of its stock and "cause investors to lose confidence in our reported financial information." Sypris linked misstatements and two material weaknesses to its ERP transition, including weak user access over accounting period changes, poor data-conversion controls, and inadequate close monitoring.

The 5 SOX Control Areas Auditors Scrutinize in a Dynamics 365 Migration

Every ERP migration touches five control domains that auditors will test. Missing any one of them creates a gap your external auditors will flag.

1. Access Controls During ETL

Who could touch the data during extraction, transformation, and load? SOX compliance in Dynamics 365 requires clear role-based access controls, ensuring that no single individual has authority over multiple critical financial tasks.

During migration, this gets harder, not easier. Your ETL process may involve service accounts with elevated privileges, temporary admin access to staging environments, and engineers who can read and modify financial data outside the production security model.

What auditors want to see:

• Named service accounts with documented permissions — not shared credentials
• Access logs showing who connected to source, staging, and target environments
• Evidence that elevated access was time-bound and revoked after cutover
• Proof that production Dynamics 365 security roles were configured before data load, not after

2. Change Management for Migration Scripts

Migration scripts, DMF projects, ADF pipelines, and mapping workbooks are not project notes. They are production change artifacts that transform your financial data. Crowe's SOX compliance roadmap requires companies to "document change management, access provisioning, testing protocols, and migration controls to confirm ERP implementation aligns with SOX Section 404 expectations."

Every iteration of the migration logic must be version-controlled, peer-reviewed, and signed off by business owners in UAT before running in production. You cannot modify a SQL script or API payload on go-live weekend without a formal change request.

What auditors want to see:

• Version-controlled migration scripts in a repository (Git, Azure DevOps)
• Documented review and approval process before any script runs against production data
• Test execution logs from UAT and dry-run environments
• A clear trail from script version → test result → approval → production execution

3. Data Integrity — Proving Zero Loss

This is where most migrations fail the audit test. You must prove — with documented, reproducible evidence — that every financial record in the source system arrived intact in Dynamics 365. A verbal claim of "the row counts match" is not evidence.

According to KPMG's ICFR Handbook, data migration creates the risk that financial data will be corrupted, lost, or not migrated completely or accurately. Flaws in this process evaluate directly as a deficiency in ICFR.

What auditors want to see:

• Record counts by entity, reconciled source-to-target
• Hash-based or checksum validation of critical financial fields
• Sub-ledger to General Ledger reconciliation in both source and target
• Dollar-value reconciliation of all balance sheet accounts, GL trial balance, and open AR/AP
• Exception reports documenting every record that was excluded, transformed, or failed — with business justification

For a deeper look at reconciliation failures, see 7 Costly Mistakes to Avoid When Migrating Financial Data.

4. Segregation of Duties During Cutover

Within a complex ERP system like Dynamics 365, managing Segregation of Duties (SoD) becomes increasingly difficult, especially when customizing security roles and permissions. Improper role assignments or conflicting permissions can inadvertently allow a user to perform incompatible tasks that breach SOX compliance requirements.

During migration, the SoD risk multiplies. The same engineer who writes the extraction script should not also run the load into production and approve the reconciliation. Having effective IT controls and appropriate segregation of duties are among the most commonly reported material weaknesses.

If team size forces overlap, compensating controls must operate with enough precision to catch a material misstatement — signing a checklist is not sufficient.

Required separation:

Role	Responsibility	Cannot Also Do
Migration Engineer	Write & test ETL scripts	Approve production execution
Data Steward	Validate source data quality	Execute load scripts
Migration Lead	Approve production run	Write extraction logic
Controller/Finance	Sign off on reconciliation reports	Modify migration scripts

5. Audit Trail Continuity

Pre-migration transactions must remain traceable after go-live. In Dynamics 365 Finance & Operations, an audit trail serves as a tracking mechanism that monitors system-level and user-level changes across modules. It logs detailed information about edits, deletions, and insertions, capturing metadata such as the user ID, timestamp, and the values before and after the change.

The challenge: your legacy system recorded Created By, Created On, Modified By, and Modified On for every financial transaction. If your migration tool overwrites these with today's date and a service account name, you have destroyed the audit trail.

How metadata preservation works depends on the Dynamics 365 platform:

Dataverse / Customer Engagement: Standard tools often default to "Today" as the creation date, destroying your audit trail. Created On can be preserved using the overriddencreatedon attribute during the Create operation. Preserving Created By requires User Impersonation via the CallerId property. Most generic tools do not support the complex impersonation logic or identity mapping required to link legacy users to modern Entra ID profiles, leading to compliance failures.

Finance & Operations: System tracking fields are system-maintained. Microsoft states they cannot reconstruct original dates for records that existed before tracking was enabled. In Dataverse-based imports, modifiedon, createdby, and modifiedby cannot be imported directly — if you need that legacy context, use custom columns or an archive model. The General journal entity does not support every account type.

In both cases, you must preserve legacy IDs, voucher numbers, posting dates, dimension values, and report parameters. Validate key reports after the move.

For a deep dive on why standard migration adapters break at this level, see Dynamics 365 Migration Case Study: Why Standard Adapters Fail on High-Volume Data.

Why Standard Migration Tools Fail the Audit Test

Manual CSV exports, native Dynamics import wizards, and ad-hoc DIY scripts introduce three categories of SOX risk.

Chain-of-custody gaps. When a Controller exports GL data to CSV, a consultant cleans it in Excel, and an admin uploads it via the Dynamics import wizard, there is no immutable log of what changed between export and import. Every manual touch is a potential SoD violation and an undocumented transformation.

Metadata loss. Microsoft does not have any formal SOX documentation for Dynamics 365. They do have audit and compliance tools to help, but it is up to the customer to implement the necessary business processes. Native import tools are designed for simple data uploads — not for preserving the posting sequences, workflow histories, and GUID-level relationships that make historical transactions auditable.

No reproducibility. SOX 404(b) demands that your external auditor can independently verify your migration. If your migration was a manual weekend exercise with no scripts, no logs, and no validation reports, there is nothing to verify. You cannot simply produce a correct balance sheet; you must demonstrate the chain of custody for every number on that sheet.

Specific tooling considerations:

• Native Dynamics 365 Data Tools: The data management workspace provides staging tables, validations, and job history. But database logging is not designed to track automated batch transactions, can degrade long-running imports, and can expose sensitive data if permissions are not controlled. Finance & Operations can also clean up execution history and staging data after the configured retention period — native logs are not your long-term audit archive.
• DIY SSIS or Azure Data Factory Pipelines: These are flexible transport layers, but the burden of code review, approval, exception handling, and evidence retention stays entirely on your team. They rarely include the comprehensive compliance documentation required out-of-the-box.
• Microsoft FastTrack: Useful, but it is a no-cost advisory service delivered with a qualified implementation partner. It provides guidance; it does not take execution accountability for your migration controls.

For a comparison of these approaches, see Microsoft Dynamics 365 On-Premise to Cloud Migration: SSIS vs Azure Data Factory vs ClonePartner.

Building Your Migration Evidence Package for Auditors

Your external auditor will request specific artifacts to support their 404(b) attestation. Prepare these during migration, not after. Reconstructing evidence retroactively is a red flag.

The Migration Evidence Package:

1. Extraction Logs — Timestamped records showing what data was pulled from the source, when, by which service account, and with what parameters. Include row counts by entity.
2. Data Dictionary and Transformation Specifications — Field-level documentation detailing how legacy data structures map to Dynamics 365 entities (e.g., mapping legacy GL accounts to MainAccount and FinancialDimension structures). Include value conversions, calculated fields, and business logic applied. Version-controlled and approved before production execution.
3. Automated Validation Reports — Script-generated reports comparing source and target: record counts, hash values, dollar-value reconciliations. Machine-generated — not manually assembled spreadsheets.
4. Sub-Ledger to GL Reconciliation — Proof that AR, AP, inventory, and fixed asset sub-ledgers tie to the General Ledger in both source (pre-extraction) and target (post-load). This is the single most-requested artifact.
5. Exception Logs and Resolution Evidence — Every record that was excluded, failed validation, or required manual intervention — with documented disposition, root cause analysis, severity, and approved remediation steps.
6. Formal Sign-Offs — Migration Lead, IT Director, Controller, and CFO sign-off at each phase gate: extraction complete, transformation validated, load verified, reconciliation confirmed.
7. Key Report Inventory — Proof that pre-migration reports can be reproduced or accessed after go-live, including report parameter definitions and a documented access path.

The reconciliation package should not stop at row counts. For in-scope cycles, include dollar totals, open-item counts, status distributions, and sample traces from source record to target record and report output. If a transformation intentionally compresses or splits records, state that rule upfront so an auditor sees an expected difference, not an unexplained variance.

Cutover Timing: Why Period-End Beats Mid-Period

Cutover timing directly affects your SOX risk exposure.

Period-end cutover (preferred): Close your GL in the source system at month-end or quarter-end. Run all standard close procedures. Generate your final trial balance, sub-ledger reconciliations, and financial statements from the legacy system. Then extract. This creates a clean, auditor-friendly boundary: everything before the cutover date was processed and closed in the source; everything after runs in Dynamics 365.

Mid-period cutover (high risk): You will need to split a reporting period across two systems. Transactions that started in the source may close in the target. Auditors will want to see how you handled in-flight transactions, partial-period allocations, and dual-system reconciliation. It can be done, but the documentation burden doubles.

Sypris' disclosed ERP weakness touched period changes, data conversion, account reconciliations, and close monitoring — exactly the areas that get harder if the population is moving during cutover.

Before extraction, confirm:

• All period-end journal entries are posted and approved in the source
• Bank reconciliations are complete through the cutover date
• Intercompany eliminations are finalized
• The trial balance from the source is locked — no further postings allowed

Common SOX Findings After an ERP Migration

These are findings auditors flag in post-migration reviews — and the ones you can prevent with proper planning:

• Incomplete migration documentation. The migration "just happened" over a weekend. No extraction logs, no transformation specs, no validation reports. Auditors have nothing to test.
• No segregation of duties during cutover. A single consultant extracted, transformed, loaded, and validated the data. No independent verification.
• Missing reconciliation evidence. The team confirmed balances "matched" verbally but never produced a formal sub-ledger-to-GL reconciliation comparing source and target.
• Inability to recreate pre-migration reports. The legacy system was decommissioned immediately after cutover. When auditors asked to reproduce a prior-period AP aging report, nobody could.
• Metadata overwritten. All migrated transactions show today's date and a service account as the creator, destroying the original posting timeline.
• Undocumented exceptions. Records failed validation and were manually "fixed" in Excel before re-import — with no log of what changed.

Historical Data: The 7-Year Retention Problem

The 7-year retention requirement is frequently misunderstood during ERP migrations. The Sarbanes-Oxley Act requires accounting firms to "prepare, and maintain for a period of not less than 7 years, audit work papers, and other information related to any audit report." This does not mandate loading seven years of closed ERP detail into the new production system.

Migrating decades of closed transactions inflates your Dynamics 365 database, increases licensing costs, degrades system performance, and exponentially increases migration failure risk. Dynamics 365 does not automatically enforce retention timelines, legal holds, or immutable storage for historical data. You need an archival solution or a governed data lake to satisfy the 7-year requirement without burdening your production ERP.

The recommended approach:

• Migrate open/active data — open AR/AP, active customers and vendors, open purchase orders, current-year GL balances (as opening balances or summary journal entries).
• Archive closed history — in a read-only, searchable, tamper-proof repository outside Dynamics 365. Options include Azure Data Lake, a dedicated SQL data warehouse, or Dataverse long-term retention.
• Maintain chain of custody — Confirm that financial records, logs, metadata, reports, and supporting documents have been fully captured, without gaps or omissions.
• Provide auditor access — Auditors should be able to retrieve historical records directly without reactivating retired applications or databases.

A practical scoping pattern is object-based, not date-based: active master data, open sub-ledger items, open balances, and the history needed for live comparative reporting move into production. Fully closed detail goes to archive, provided the audit trail and access procedure are documented.

For guidance on scoping what to migrate, see What Data Should You Actually Migrate to Your New ERP?.

The Pre-Cutover Auditor Conversation

Brief your external audit firm 90 days before go-live. Do not surprise them with a new ERP system at year-end. Especially under Section 404(b), discuss control documentation, evidence, and test plans to align with auditor expectations and prevent last-minute surprises or audit rework.

Your auditor is not your adversary. They are required to evaluate whether your controls operated effectively through the transition. Give them the evidence and they will sign off. Withhold it and they will expand their testing scope — costing you weeks and fees.

What to cover in the briefing:

1. Scope and timeline. What system are you leaving? What is the target? When is cutover? Which legal entities and financial processes are in scope? What data moves vs. gets archived?
2. Control mapping. Show them your source-system controls, target-system controls, and the gap analysis. Identify controls that change, any that are new, and any temporarily suspended during cutover.
3. Migration approach. Explain whether the migration is script-based, tool-based, or manual. Walk them through the SoD model, access controls, and validation methodology. Confirm no manual CSV manipulation will occur.
4. Evidence package. Share the list of artifacts you plan to produce (extraction logs, validation reports, reconciliation reports, sign-offs). Ask if they need anything beyond what you have planned.
5. Historical data strategy. Explain what stays in the legacy system, what gets archived, and how auditors can access pre-migration records for future audit periods.
6. Materiality thresholds. Align on what dollar-value discrepancies in reconciliation will trigger escalation versus what falls below the materiality threshold. Confirm that your planned UAT sign-off documentation meets their testing standards.

By controlling the narrative and presenting a structured, engineering-led approach, you shift the auditor's posture from skeptical to collaborative.

If you find errors after sign-off, treat them like an ICFR event — not a help-desk ticket. Log the incident, quantify scope, rerun reconciliations, evaluate whether compensating controls operated effectively, and brief the audit team if the issue could affect ICFR. Do not manually alter the database. Correct data via standard journal entries or approved API updates, fully documenting the compensating controls used.

How ClonePartner Handles SOX-Compliant Migrations

We treat data migration as a precise engineering discipline — not a weekend project. For Dynamics 365 migrations involving SOX-regulated companies, our process produces the exact evidence package auditors demand:

• Automated, scripted ETL — no manual CSV manipulation. Every transformation is code, version-controlled, and reproducible.
• Metadata preservation — we preserve Created By, Created On, Modified By, and Modified On using Dynamics 365's overriddencreatedon attribute and CallerId impersonation, so your historical audit trail remains intact.
• Built-in validation reports — automated record-count reconciliation, hash validation, and GL balance comparison generated as part of every migration run.
• Strict SoD enforcement — extraction, transformation, load, and validation are handled by separate roles with documented access controls.
• Complete evidence package — we deliver extraction logs, transformation specs, validation reports, exception logs, and reconciliation reports ready for your auditor's review.

We build custom, programmatic pipelines that extract data directly via API or secure database connections, transform it according to auditor-approved specifications, and load it into Dynamics 365 without manual intervention — saving your internal finance and IT teams hundreds of hours of documentation work.

For a look at how we structure migrations operationally, see How We Run Migrations at ClonePartner. For the broader transition process, see The Practical Guide to Moving from On-Prem Dynamics to Dynamics 365 Online.