Legacy ERP migration fails when historical data is treated as a single load problem. GP, NAV, and AX environments contain years of ledger, customer, vendor, item, payroll, and operational records. Moving all of it directly into a new cloud ERP can increase storage cost, slow the new system, and make reconciliation harder.
Tool longevity matters when the data being moved is older than the destination platform. COZYROC has spent the SSIS market with customers in , and the 200+ component SSIS+ suite supports SQL Server versions from 2005 through 2025. That version range matters here because GP, NAV, and AX history often sits on the older instances a migration package still has to read.
The Better Migration Question
The question is not “How do we move everything?” The better question is:
What data must live in the new operational ERP, what data must remain queryable for audit and reporting, and what data only needs controlled retention?
That distinction leads to a staged architecture:
- Extract from the legacy ERP.
- Clean and normalize records outside the target ERP.
- Load only active operational data into the new system.
- Preserve older history in a lakehouse, archive, or reporting store.
- Use delta detection during the hybrid period while old and new systems overlap.
COZYROC Components For Legacy Dynamics Migration
| Pain point | COZYROC component | Architectural result |
| Dynamics GP data requires specialized extraction patterns | Historical and operational GP records can be extracted through SSIS package logic | |
| NAV page and table structures need controlled connectivity | NAV connection settings can be managed through an SSIS connection manager before staging | |
| AX legacy data requires adapter-aware extraction | AX records can move into staging, cleansing, and archive stores through SSIS data flow logic | |
| Hybrid cutover requires changed-row detection | Only new, changed, or deleted rows need to move during parity windows | |
| Schema differences complicate staging | DFT+ / Dynamic Data Flow Task | Metadata-driven packages reduce manual remapping between legacy and target structures |
| Existing SSIS packages need a cloud runtime | Existing SSIS package assets can be uploaded, parameterized, scheduled, and monitored |
Migration Architecture Pattern
Use a three-zone migration structure:
- Legacy extraction zone. COZYROC Dynamics adapters read GP, NAV, AX, or SQL-backed ERP data into staging.
- Control and cleansing zone. DFT+, lookup logic, and validation tables normalize customers, vendors, dimensions, chart of accounts, addresses, and item records.
- Target and history zone. Active data loads to the new ERP, while historical data lands in reporting tables, OneLake, SQL endpoints, or archive storage.
During phased deployment, Table Difference can compare legacy source rows with staged or target records to isolate changes. That lets teams maintain parity without running full reloads every night.
TCO And ROI Framing
The savings come from avoiding three expensive mistakes:
- Overloading the new ERP with decades of inactive history.
- Hiring developers to rewrite existing SSIS migration logic into notebooks or custom services.
- Running repeated full-history loads when changed-row detection is enough.
COZYROC also helps preserve existing SSIS knowledge. If the team already understands package design, the migration work can stay closer to the skills and assets they already have.
FAQ
Do we have to move all Dynamics GP history into the new cloud ERP?
No, load only active operational data into the new system. Older ledger, customer, vendor, and payroll history belongs in a lakehouse, archive, or reporting store where it stays queryable for audit without inflating ERP storage cost or slowing the new platform. The migration question is what must live in the operational ERP, not how to move everything.
How do we keep the old and new ERPs in parity during cutover?
Use changed-row detection instead of full reloads. compares legacy source rows with staged or target records and isolates new, changed, and deleted rows, so only deltas move during the hybrid window. That keeps nightly parity work small even while both systems overlap.
Which components extract data from GP, NAV, and AX?
Each legacy platform has its own adapter. reads historical and operational GP records, manages NAV connectivity ahead of staging, and moves AX records into staging, cleansing, and archive stores through normal SSIS data flow logic.
Can our existing SSIS migration packages run in the cloud?
Yes, executes existing SSIS package assets. Packages are uploaded, parameterized, scheduled, and monitored, which means the migration logic the team already tested does not need a rewrite into notebooks or custom services just to get a managed runtime.