Migrate from Udyog ERP to Microsoft Dynamics 365 Business Central

Udyog ERP Customer master stores billing address, GSTIN, PAN, and contact details as flat fields. We extract via direct SQL SELECT against the customer_mst or equivalent table, validate GSTIN checksums against the GSTN public API, and map to D365 Customer (BC) or CustTable (F&O) with the GST Registration Number and PAN mapped to India-specific tax identification fields. Billing and shipping addresses are mapped to the D365 address roles model. The customer GSTIN validation step flags inactive or invalid registrations before import to prevent compliance issues downstream.

Vendor master mirrors the customer structure with additional TDS deduction fields. Indian statutory deductions (TDS rate codes, sections, certificates) map to D365's withholding tax configuration under Purchasing Payables setup. We preserve vendor GSTIN and CIN data, validate against GSTN, and map the TDS deductee type to the applicable withholding tax group in D365. Vendor payment terms migrate as D365 payment terms linked to the vendor record.

Udyog ERP Item master includes SKU, HSN code, unit of measure, opening stock, and valuation method (FIFO or weighted average). We export Items with their HSN code mapped to D365's Harmonized System Nomenclature field, unit of measure mapped to the D365 unit of measure code, and valuation method mapped to the costing version configuration. Standard BOM linkages stored as parent-child relationships are preserved as references for BOM migration.

The Indian accounting chart includes statutory ledgers for GST Input Tax, GST Output Tax, TDS Payable, TCS Receivable, and GST Payable that must map to D365's posting group configuration. We map standard account codes to destination account numbers and flag India-specific tax accounts (GST Settlement, GST TCS, GST TDS) for configuration in D365's Indian statutory posting group setup before the COA is activated. The source account name in Hindi or regional script is preserved in the account name field; the D365 account number uses the mapped standard code.

Outstanding payable vouchers include voucher number, party name, amount, due date, and GST tax component. We preserve voucher-level detail to allow reconciliation in D365 by creating open vendor ledger entries with the original voucher reference in the description field. GST tax components are split into base amount and tax amount on separate ledger entries using the India GST posting groups. The payment term and due date migrate as-is to preserve cash flow forecasting accuracy.

Outstanding receivable vouchers include voucher number, customer name, amount, due date, and GST tax component. We create open customer ledger entries with the original voucher reference preserved in the description or external document number field. GST components split to separate ledger entries using India GST posting groups. The aging report must match between systems within 0.1 percent tolerance before we close the migration gate.

All posted journal vouchers with narration, date, and multi-legger debit or credit lines are exported in chronological sequence from Udyog ERP SQL. We maintain the original voucher numbering to preserve audit trail continuity. Each journal line maps debit or credit amounts to the corresponding D365 G/L Account, with the narration field carrying the original journal description. Journal batches are created per source voucher series to maintain document traceability.

Multi-level BOMs with scrap percentages, operation sequences, and work centre assignments require careful extraction and flattening. Udyog ERP stores BOM versions by date, which we flatten to the active version at migration cutover. We run BOM explosion queries in SQL to expand the full hierarchy and validate component quantities against production orders before loading. D365 BOMs are created with version control enabled, scrap percentages configured per BOM line, and work centre resources mapped from Udyog ERP's routing setup.

Work orders reference BOM, planned quantity, and actual production quantities. Status flags (Pending, In Progress, Closed) map to D365 production order statuses: Started becomes Released, In Progress becomes Released with quantity posted, and Closed maps to Completed. We sequence work orders by creation date to preserve production state. Any under-closed production orders requiring material consumption posting are flagged for manual closure in D365 before the migration gate closes.

Production orders capture input material consumption and finished goods output with date-stamped transactions. We extract full consumption ledgers and flag any under-closed production orders that require a consumption journal to be posted before migration. D365 production orders are created in the equivalent status and linked to the BOM and routing that migrated from Udyog ERP. WIP balances are calculated from the sum of material and operation consumption records.

India-specific GST filing data stored in Udyog ERP's proprietary format linked to invoices does not export cleanly to D365's general ledger structure. We extract invoice-level detail as a structured export (CSV or JSON) and preserve the GSTR-1 and GSTR-3B period data as reference records in a D365 data entity or a linked Azure Blob Storage container for external GST reconciliation and filing. D365 Finance and Operations India localization provides GST return configuration but the return generation relies on the configured posting groups rather than imported historical return files.

Employee records include designation, department, and bank details for payroll processing. Udyog ERP stores leave balances and attendance data separately. We map the core employee record (name, employee ID, department, designation, date of joining) to D365 Worker, with bank details mapped to the payment method fields. Leave balance data is extracted as a separate reference export for manual entry into D365 Payroll or the customer's HRMS of record since D365's HR module has a separate data model from the ERP production module.