Migrate from Astral Manufacturing ERP to Microsoft Dynamics 365 Business Central

Astral Customer master records map to D365 Customer records. We extract customer name, contact details, billing and shipping addresses, payment terms, and GST/tax registration. D365 requires choosing Customer type as Person or Company; we infer this from the Astral customer record structure. Multiple addresses in Astral require mapping to D365's address roles (Invoice, Delivery, Order). The source customer code becomes the Customer Number in D365 and acts as the dedupe key during import.

Astral Vendor records map to D365 Vendor. We extract vendor name, contact information, address, payment terms, and tax registration. The vendor code from Astral becomes the Vendor Number. Vendor ledger entries from open AP are imported separately after Vendor records are committed to satisfy the foreign key constraint.

Astral Items map to D365 Items. We distinguish manufactured items (Type = Inventory Item with BOM linkage) from purchased items (Type = Inventory Item or Service Item). Item tracking method in D365 (None, Serial No., Lot No., or Both) is set based on the batch tracking configuration in Astral's Stock Management module. The source item code becomes the Item Number and serves as the parent reference for BOM and production order linkage.

Astral Items with BOM child records (Bill of Materials links for manufactured goods) map to D365 Production BOM. We decompose the Astral BOM child rows into BOM Component Lines with item number, quantity per, and unit of measure. D365 BOM version validity dates are derived from the Astral production order creation timestamps. If Astral stores multi-level BOM (BOM referencing another BOM), we flatten or nest the structure based on the customer's D365 routing configuration.

Astral Purchase Orders map to D365 Purchase Orders. PO header fields (vendor reference, order date, currency, payment terms) and line data (item number, quantity, unit cost, line discount) migrate directly. D365's approval workflow status on PO must be set to Open at import; approval routing is a post-migration configuration step. Closed or received POs migrate as history with a Posted = Yes flag to prevent re-receipt.

Astral batch tracking records (batch serial number, warehouse location, stock-on-hand quantity, batch status) map to D365 Item Ledger Entry records. Batch serial numbers migrate as Lot No. or Serial No. depending on Astral's tracking configuration. Current stock-on-hand values are inserted as positive adjustment entries in the inventory journal. We reconcile total stock value from Astral's stock ledger against D365 Item Ledger Entry totals before closing the inventory migration phase.

Astral Production Process records map to D365 Production Orders. The production header (item to manufacture, quantity, scheduled dates) migrates as-is for open production orders. For released and finished production orders, we insert as Finished status with the output posted to the item ledger. Routing steps and quality checkpoints from Astral's Production Process module map to D365 Production Order Routing Lines and Quality Management setup; routing sequences are rebuilt as D365 routing versions rather than direct data migrations because D365 routing is a configuration entity.

Open Sales Orders from Astral migrate to D365 Sales Orders with status Open. Historical closed orders migrate as Sales History records linked to the customer. Line data (item, quantity, unit price, discount) maps directly. D365's invoice and shipment posting workflow is not triggered during migration; orders are landed as unfilled so that the customer's D365 admin can fulfill and invoice from the imported records.

Astral's open receivables and payables map to D365 Customer and Vendor Ledger Entries. We extract current balance, due date, document type (Invoice, Credit Memo, Payment), and party link. Payment history and reconciliation records are not independently migratable from Astral; we import the open balances as opening entries with a reference to the original Astral document number for audit. The customer's D365 admin posts these as opening balance entries before the migration cutover date.

Astral invoices linked to closed sales or purchase orders migrate to D365 as Posted Invoices with the Posted flag set. Invoice headers (customer/vendor, date, currency, tax amounts) and line items (item, quantity, price, tax, discount) migrate directly. Invoice PDF attachments require separate document migration handling via D365's document attachment API. Open invoices are migrated as Open = Yes with the remaining amount set to the outstanding balance.

Astral Quality Test records attach to production batches. We migrate test result values as structured fields (test name, measured value, pass/fail threshold, result). However, quality management threshold rules, sampling plans, and pass/fail configurations are destination-specific. These are delivered as a quality configuration blueprint for the customer's D365 admin to set up under Quality Management after migration, because D365 stores these as setup entities rather than transaction records.

Active Astral users map to D365 User accounts. We extract user name, email, and role assignments. D365 user licensing and authentication is Microsoft Entra ID-backed; the customer's Entra tenant is connected during D365 provisioning. We match Astral user emails against Entra UserPrincipalName to resolve the User SID for D365 user provisioning. Role assignments from Astral's permission structure map to D365 permission sets, but security roles are rebuilt by the D365 admin because permission set composition is role-specific.

Where Astral's native HRMS module stores employee records (name, department, designation, employment dates), we migrate these as D365 Human Resources Worker records. Compensation history, PTO balances, and payroll data are not migratable without a payroll integration path; we flag these as manual post-migration entry. If the destination D365 deployment does not include the Human Resources module, we migrate core employee fields as a custom Worker table and flag the full HRMS rebuild scope separately.