Migrating Dynamics On-Prem to Cloud: Why "Standard" Partners Fail at Data Integrity

Executive Summary for decision makers:

• Global SIs: Best for business process re-engineering ($$$$).
• Microsoft Partners: Best for licensing and standard setup ($$).
• ClonePartner: Best for rapid, zero-loss data migration without process changes ($).
• Risk: ERP migration failure rates are high — most industry estimates place them between 55–75%, driven primarily by data integrity issues at the migration layer, not the application layer.

The Problem: On-Prem Dynamics Is Losing Support

Microsoft has officially set end-of-support dates for Dynamics on-premise products. We detailed the exact dates in our Guide to the Dynamics On-Premise Support Deadline, but the practical consequence is simple: security updates stop, compliance risk starts climbing, and your upgrade path narrows with every quarter you wait.

If you're running Dynamics AX or NAV on-prem, the question isn't whether to migrate — it's how to do it without corrupting the historical data your business depends on.

This guide breaks down the landscape of migration vendors, explains the technical reasons standard tooling fails on legacy Dynamics data, and gives you a framework for evaluating who should touch your database.

SECTION 1: The Three Types of Migration Partners

When you look for help, you usually find three categories. Understanding the difference is the only way to save your budget.

1. The Global Systems Integrators (The "Safe" Bet)

These are the household names — Accenture, Capgemini, Deloitte.

• Best for: Full business process re-engineering. If you want to change how you sell, how you forecast, how you manage supply chain — hire them.
• Not built for: Pure data migration. Their delivery model is built around 9–18 month transformation programs with large teams. Moving data is a line item inside a larger engagement, not their core competency.

2. The Generalist Microsoft Partner

These are the certified resellers. They sold you the license; now they want to move you.

• Best for: Configuring the new Dynamics 365 environment and handling licensing.
• Limitation: Their "migration strategy" typically relies on default Microsoft tooling — the Data Migration Framework, configuration packages, or the Microsoft FastTrack methodology. FastTrack is a solid framework for onboarding, but it assumes your data is clean and schema-compatible. When your data isn't (and after 10+ years on-prem, it rarely is), FastTrack guidance stops at "please clean your data before upload."

3. The Specialized Data Migration Service (That's Us)

This is a newer category. We aren't here to re-org your business processes.

• Focus: Data integrity, schema transformation, and speed.
• Approach: We treat migration as an engineering problem — custom extraction, transformation, and loading logic built for your specific source schema.

Section 2: The Comparison Matrix

We've analyzed standard proposals from SIs and Partners against our own engineer-led model.

Section 3: Why Standard Migration Tooling Fails on Legacy Dynamics Data

This section exists because the failure mode is technical, not organizational. Understanding where the standard tools break helps you evaluate any vendor — including us.

The Tools That Partners Typically Use

Most Generalist Microsoft Partners rely on some combination of:

• Data Migration Framework (DMF) / Data Import/Export Framework (DIXF) — built into D365 F&O for entity-based data import.
• Configuration Packages — used in Business Central for table-level data import via RapidStart.
• SSIS (SQL Server Integration Services) — for custom ETL pipelines, often used by more technical partners.
• Azure Data Factory (ADF) — Microsoft's cloud-native ETL service, increasingly recommended for large-volume moves.
• KingswaySoft — a third-party SSIS connector library with Dynamics-specific adapters.

These tools work well when the source data is clean, the schema matches the target, and the entity relationships are standard. The problem is that after 10–20 years of on-prem operation, none of those conditions hold.

Five Categories of Data Integrity Failure

When we say "data integrity," we mean something specific and testable:

Our definition: Zero record loss, correct foreign key preservation across all entities, accurate field-type conversion (including decimal precision for currencies), no truncation of text/memo fields, and complete attachment migration with parent-record linkage intact.

Here are the five failure categories we see repeatedly:

1. Foreign Key Orphaning Legacy Dynamics systems accumulate orphaned records over years — invoice lines pointing to deleted customers, journal entries referencing decommissioned GL accounts. Standard import tools either silently drop these records or throw a constraint violation and halt the batch. Either outcome means data loss or stalled migrations.

2. Field Truncation and Type Mismatch On-prem systems often have custom fields with different length constraints or data types than their D365 Cloud equivalents. A VARCHAR(500) notes field in NAV that maps to a VARCHAR(250) field in Business Central will silently truncate unless the transformation layer catches it. Decimal precision differences between AX currency fields and D365 F&O fields can turn $5,000.00 into $50.00 if the scale factor isn't handled.

3. Attachment and Document Corruption PDF attachments, embedded images, and linked documents stored as BLOBs in the legacy SQL database often fail to migrate cleanly through standard tools. The file may transfer, but the parent-record linkage breaks — so the attachment exists in the new system but isn't connected to the invoice or purchase order it belongs to.

4. Custom Entity and Extension Conflicts Any Dynamics system that's been in production for years will have custom tables, modified standard entities, and ISV extensions. The Data Migration Framework expects standard entity shapes. When your source has a custom SalesOrderExtension table with fields that don't exist in the target schema, DMF doesn't know what to do with it. Partners typically tell you to "manually reconcile" these — which means your team is rebuilding data maps in spreadsheets.

5. Currency and Multi-Company Rounding Errors Multi-entity environments with multiple currencies are especially fragile. Exchange rate tables, rounding rules, and intercompany elimination entries all need to be migrated with their full calculation context intact. Standard tools move the numbers but not the calculation logic, which means your trial balance in the new system won't match the old one.

Why Version Matters

Not all Dynamics on-prem migrations are the same. The source version changes the technical difficulty significantly:

• Dynamics AX 2009: Uses a proprietary kernel and data dictionary. Extraction requires direct SQL access to the AX database, and the schema has almost no overlap with modern D365 F&O entity models.
• Dynamics AX 2012 (R2/R3): Introduced the Data Import/Export Framework (DIXF), which is a precursor to DMF. Closer to modern D365, but custom models and ISV solutions from this era often use non-standard table structures.
• Dynamics NAV 2016/2018: C/AL-based, with data stored in SQL Server but accessed through the NAV service tier. Configuration packages can handle simple entities, but custom pages, codeunits, and table extensions require manual remapping to AL extensions in Business Central.
• Dynamics GP: Uses a completely different SQL schema (see our Dynamics GP SQL Database Structure guide). GP migrations to D365 are essentially cross-platform data transformations, not upgrades.

A vendor that doesn't ask which version you're running in the first conversation is a vendor that hasn't done this enough.

Where Standard Tools Work (and Where They Don't)

To be clear: standard tools aren't useless.

• Azure Data Factory is excellent for high-volume, repeatable batch loads when the schema mapping is already defined.
• KingswaySoft provides strong Dynamics-specific connectors that reduce the SSIS boilerplate significantly.
• DMF/DIXF works well for standard entities (customers, vendors, items) when the source data is clean.

These tools break down when they hit dirty data, custom schemas, and complex entity relationships — which describes most legacy Dynamics environments that have been in production for a decade or more.

Our approach uses custom Python and SQL scripts that handle transformation logic inline — cleaning, remapping, and validating data during the move rather than requiring a separate "data cleansing" phase that adds weeks to the timeline.

Section 4: What to Evaluate Before Choosing Any Migration Vendor

Regardless of who you hire, here's a framework for evaluating migration partners:

Data Integrity Guarantees

• Do they define "data integrity" in measurable terms? (Record counts, foreign key validation, field-level checksums)
• Do they run automated post-migration validation, or do they hand you a spreadsheet and say "please verify"?

Rollback and Recovery

• What happens if the migration fails mid-batch? Is there a rollback procedure, or do you start over?
• Do they maintain a snapshot of your source data before migration begins?

Audit Trail Preservation

• For regulated industries: do they preserve the audit trail from your legacy system, or does the migration create a "day one" reset in D365?
• How do they handle GL transaction history for SOX or IFRS compliance? (See our SOX-Compliant ERP Migration guide)

Schema Expertise

• Do they ask about your Dynamics version, custom entities, and ISV extensions in the first call?
• Can they show you a data map before you sign a contract?

Testing Methodology

• How many test migrations do they run before go-live?
• Do they validate at the field level, or just check record counts?

Section 5: How ClonePartner Handles This

We are an engineer-led service. That means we optimize for precision, not billable hours.

Unlimited Sample Migrations

Most vendors charge for a "test run." We don't. We run sample migrations of your data repeatedly until the output matches your validation criteria — record counts, field values, attachment linkage, all of it.

The 30-Day Safety Net

Here is a scenario that keeps CIOs awake: The migration is marked "Complete" on Friday. You pay the invoice. On Tuesday, a sales rep realizes their client notes from 2022 are missing.

• With a standard partner: That's a new change request.
• With ClonePartner: That's covered. We include a 30-day post-migration support window. If you find a data issue we missed, we fix it. No additional charge.

Continuous Sync During Transition

We can set up real-time data pipelines so your old and new systems run in parallel during the transition period. Your team keeps working in the legacy system while we validate the new environment. Zero downtime. Zero forced cutover.

Who Should You Choose?

• Choose a Global SI if you need to re-engineer business processes alongside the migration.
• Choose a Microsoft Partner if your data is clean, your schema is standard, and you need licensing and configuration help.
• Choose a specialized data migration service if your priority is getting historical data into D365 intact, fast, and without forcing your team to spend weeks on manual data cleansing.

If you want to understand what your specific migration looks like — record volume, entity complexity, timeline — the fastest way to find out is a conversation.