AS400 & JD Edwards to D365 Finance & Operations: Data Migration Roadmap

Why Migrate Now?

Legacy systems like AS400 and JD Edwards built your business—but they're also anchoring it. Vendor support is eroding, skilled resources are scarce, and modernizing your supply chain or financial processes means fighting against outdated architecture.

D365 F&O provides:

• Integrated financial and supply chain management: One data model instead of point-to-point integrations.
• Real-time visibility: Cash flow, inventory, and demand forecasting that actually reflect reality.
• AI and automation: Anomaly detection, demand planning, and process mining built in.
• Scalability without reinvestment: Cloud-native infrastructure grows with you.

The cost of staying on AS400 or outdated JDE is higher than the cost of moving. But the move itself? That's a data problem first, process problem second.

Phase 1: Discovery & Assessment

Before you touch data, you need to understand what you have.

Your discovery phase should map:

• Data sources: AS400 libraries, JDE tables, ancillary systems (WMS, sub-ledgers, legacy AR/AP). Include spreadsheet repositories—they're always bigger than you think.
• Entity inventory: Chart of accounts, legal entities, business units, cost centers. What's live? What's dead code?
• Master data relationships: Customer → address → payment term → credit limit chains. Which are 1:1 vs. 1:many?
• Data quality baseline: Duplicates, orphans, inactive records, null rates by field. Measure it now; you'll validate against it later.
• Volume profiling: Open purchase orders, unpaid invoices, months of history to migrate. This drives your testing strategy and parallel-run duration.

Phase 2: Data Mapping & Transformation

Data mapping is where you translate "AS400 speak" into "D365 speak." It's not a 1:1 conversion.

Your mapping should cover:

• Chart of accounts: AS400 account numbers may use prefix-coded account dimensions (e.g., 1-1000-100 = company-GL-dept). D365 uses account structure rules. Map carefully, and don't forget intercompany eliminations.
• Vendor/customer master: Multi-site vendors, variant terms per location, credit holds, and payment preferences. AS400 often splits this across files; D365 consolidates it.
• Item master: Product codes, variants, unit of measure conversions (case → units), costing method (standard vs. actual), and shelf life attributes. JDE variants need consolidation.
• Open transactions: Unpaid invoices, partially received POs, accrued liabilities. These carry forward; make sure the GL impact lands in the right period.
• Multi-currency and intercompany: If you operate globally, currency rounding rules and intercompany settlement logic must be nailed down upfront.

Phase 3: Financial Data Migration

Financial data is the most audited, most questioned piece of your migration. Get it right.

Focus on:

• GL opening balances: Balance sheet accounts must reconcile to your last AS400/JDE financial close. Use a verification script that sums by account and compares. Build a reconciliation register showing opening GL balances before and after data load.
• Accounts payable: Invoice header (vendor, amount, due date, payment status) + line detail (PO reference, GL account, tax code). Unapplied credit memos must be flagged for resolution.
• Accounts receivable: Customer invoices, payment applications, cash discounts taken, and deferred revenue. Aging buckets drive reserve calculations; verify they roll forward correctly.
• Fixed assets: Asset register, depreciation schedules, accumulated depreciation, and book value. If you've been depreciating manually in GL, that's tech debt being exposed right now.
• Multi-currency: Balance GL in home currency, then verify all foreign currency sub-ledgers tie to GL revaluation entries. Spot-check foreign exchange gain/loss calculations.

Phase 4: Supply Chain & Operations Data

Supply chain data includes inventory, BOMs, purchase orders, and sales orders—the transactional backbone of your business.

Prioritize:

• Inventory on hand: Physical counts by warehouse and item, with serial/batch numbers if tracked. If your legacy system hasn't been reconciled to physical inventory in 6 months, do that first.
• Open purchase orders: Vendor, item, quantity, unit cost, receipt status, and invoice matching status. Partially received POs must link to the matching invoice.
• Open sales orders: Customer, item, order quantity, shipment status, and billing status. Backorders and drop-ships require special handling.
• Bills of material: Component lists, scrap factors, and co-products. If you manufacture, this is critical. D365's BOM costing can be complex; validate a sample of finished goods costs.
• Routings and work centers: Machine capacity, labor rates, and setup times. These drive MRP and production scheduling.

Phase 5: Testing & Validation Strategy

A data migration is not complete until you've proven the data works in context. Testing is phase 5—not phase 6.

Execute:

• Reconciliation testing: GL balance sheet balances, AR aging matches invoice detail, AP aging matches invoice detail, inventory on hand matches physical, and cost of goods sold flows through correctly.
• Transactional testing: Can you receive a PO against migrated open order? Can you invoice a migrated SO? Can you apply a payment to a migrated AR invoice? Run 50–100 end-to-end transactions through the system.
• Dimension validation: Do all migrated GL accounts exist in your account structure? Do all vendor/customer records have required tax IDs and payment terms?
• Parallel run: Run the migration in your UAT environment, then do a 1–2 week parallel run in production where you post transactions in both systems. Pick a weeklong period and compare GL ending balances, AR sub-ledger, and AP sub-ledger.
• User acceptance testing (UAT): Let your finance, procurement, and operations teams run their month-end close, purchase-to-pay, and order-to-cash workflows on migrated data.

Phase 6: Cutover Planning & Go-Live

Cutover is the period between your last AS400/JDE transaction and your first D365 transaction. It's typically 1–7 days, depending on data volume and your tolerance for operating dark.

Plan for:

• Blackout windows: When will you stop posting transactions to the legacy system? Who's on call during cutover?
• Final data extract and load: Timing and validation. If you find orphaned records in the final extract, what's the remediation plan?
• Reconciliation sign-off: CFO must sign off that GL balances are correct before you flip the switch.
• Operational readiness: Are WMS systems, HR systems, and CRM systems (if integrated) ready to receive D365 data? Have you tested the outbound integrations?
• Rollback plan: If something fails in the first 48 hours of go-live, what's your path to revert? Keep your legacy system online for 2–3 days as a safety net.

Common Gotchas in AS400/JDE Migrations

These issues trip up most migrations. Plan around them:

• Orphaned records: Customers with no address, vendors with no payment term, items with no BOM. Your source data isn't as clean as you think. Discover and resolve these in phase 1.
• Duplicate masters: The same vendor exists under two vendor IDs because a data entry error created a dupe 15 years ago. Consolidate before migration, not after.
• Implicit business logic: AS400 has stored procedures, user-defined functions, and batch jobs that enforce rules. Those rules don't exist in D365. You need to find them, document them, and rebuild them in workflow, validation rules, or custom extensions.
• Multi-site operations: If you have multiple inventory locations, different GL structures per site, or customer-specific pricing, D365's configuration is far more complex than legacy systems. Budget extra testing time.
• Historical data depth: JDE and AS400 often archive old transactions. If you need 3+ years of open AR/AP, that data extraction can be complex. Plan for ETL specialists, not just ERP consultants.
• Costing method changes: Moving from actual costing (AS400 standard) to standard costing (D365 best practice) means recalculating inventory and COGS. If your legacy system underabsorbed overhead, that becomes visible in D365, and your margins look different.

The Role of Your Implementation Partner

A good D365 partner doesn't just configure the system—they manage your data migration like surgeons managing an organ transplant.

Expect them to:

• Map your legacy data to D365 entities, including custom fields and extensions.
• Build ETL pipelines (SSIS, Azure Data Factory, or custom scripts) to extract, transform, and validate data.
• Execute test loads and validation runs until reconciliation is perfect.
• Partner with your finance and operations teams to walk through the migrated data and sign off on accuracy.
• Manage the cutover window and the first 30 days of production support to catch and fix data issues fast.

Migration Readiness Checklist

• Inventory all data sources (AS400 libraries, JDE modules, spreadsheets, subsidiary systems).
• Profile data quality and identify clean-up tasks (deduplication, orphan resolution, field standardization).
• Map legacy entities to D365 entities with business logic rules documented.
• Build sample transformation scripts and test with first 100 records.
• Create GL reconciliation template (legacy system opening balances vs. D365 post-migration balances).
• Plan 1–2 full test migrations in UAT before production cutover.
• Execute parallel close in legacy and new system for at least one month.
• Document every transformation rule and validation check; don't rely on tribal knowledge.
• Train your team on D365 data entry standards and validation rules before go-live.
• Establish a data governance owner post-go-live to prevent master data decay.