Migrate from Visibility ERP to Microsoft Dynamics 365 Business Central

Visibility's multi-level BOMs with parent-component trees map to the destination's Manufacturing BOM with version-linked component lines. We walk the full parent-component tree at extraction time, preserving the level-by-level hierarchy. Phantom BOMs from Visibility map to the destination's phantom type flag on BOM lines. Each BOM level's routing association migrates as a separate route-card link. Configure-to-order product configurations stored in Visibility's Product Configurator require a bespoke mapping because Dynamics 365 handles product configuration through its Configuration Technology Pack rather than a native configurator table.

Open Work Orders in Visibility with status Released, In Process, or Closed map to Work Order (F&SCM) or production order records in Business Central. We map the work-order-specific routing steps, labor estimates, material allocations, and status histories as operation lines and warehouse journal lines respectively. Work Orders referencing BOM revisions that are no longer active in the destination are flagged during scoping; we apply a revision-mapping table at import time to lock the destination BOM to the correct revision or map to the latest active revision explicitly.

Production Order headers in Visibility reference the BOM revision and Routing to generate material and labor requirements. We map the Production Order header, its linked BOM revision reference, and the operation step sequence as a linked production BOM version and route card. The scheduled start and end dates, quantity, and priority flags migrate as-is. Production orders with a status of Released in Visibility map to Released in the destination; In Process maps to Finished or Confirmed depending on the destination's status set.

Visibility Routings define the sequence of manufacturing operations, work centers, and standard times. We map routing headers, operation steps, and work center assignments. Custom operation-level user fields require the bespoke custom field map built during scoping. Routing work centers in Visibility are mapped to work center codes in the destination, with capacity and efficiency values preserved. If Visibility uses operation-specific user-defined fields at the routing step level, those require manual mapping against the destination's route-operation extension tables.

Open and historical Sales Orders migrate with full line-item detail including configured lines, pricing, discounts, and shipment schedules. We map the Sales Order header, customer reference, and all lines with quantities, unit prices, and line discounts. Partial shipments scheduled in Visibility's shipment schedules map to the destination's shipment schedule lines. If Visibility stores multi-currency pricing, currency codes are preserved and validated against the destination's currency list.

Open Purchase Orders with line items, vendor assignments, scheduled receipts, and unit costs migrate directly. We map the PO header to the destination's Purchase Order object, flatten line-level detail including internal notes and delivery addresses, and preserve the original PO number as a reference field. Receipts not yet invoiced in Visibility retain their expected receipt date and quantity; these flow into the destination's expected receipt tracking.

Visibility tracks lot numbers, serial numbers, expiration dates, and bin locations. Lot-controlled items require mapping the lot assignment at the inventory transaction level, not just the item master. We extract lot genealogy from Visibility, including parent-lot and child-lot relationships, and reconstruct those in the destination's lot tracking tables. Serial number assignments tied to specific work orders or purchase receipts are preserved with their original registration dates and location references.

Visibility uses a hierarchical GL code structure that varies by deployment (segmented vs. flat). We extract the full account tree, map account types, and validate that the destination's segment structure accommodates the source chart. If Visibility uses a segmented account code structure (such as Company-Division-Account), we map each segment to the corresponding Dynamics 365 Financial dimension and validate that dimension values are created before the GL import begins. Account balances carry forward as opening balances in the destination's general journal.

Open invoices, credit memos, and payment records carry customer and vendor references, due dates, and aging buckets. We map open AP/AR by aging period, preserve original invoice numbers as reference fields, and carry forward the open balance as an aging entry in the destination. If Visibility stores payment terms and discount codes, these map to the destination's payment terms and cash-discount tables. Closed AP/AR with full payment history migrates as historical ledger entries with a closed status.

QC inspection results, non-conformance records, and corrective actions link to Work Orders and inventory transactions in Visibility. We migrate QC records as related children of their parent Work Orders, mapping parent references to the destination work order number. If the destination's Quality Management module is not enabled at the time of migration, QC records are loaded as custom tables or notes on the parent record pending module activation.

Visibility allows user-defined fields across most major objects. We extract the custom field schema during scoping via a database-level query or Visibility-supported report and build a bespoke field map before any import begins. Fields that have no destination equivalent are flagged as manual entry or custom-field creation tasks in the migration workback. Without this step, imports silently drop custom field values or write them into wrong columns, which is irreversible once the migration is live.

User accounts, role profiles, and security permissions migrate with role-to-permission mapping preserved where the destination has an equivalent role model. Role names are mapped to the closest Dynamics 365 security role, and any permissions that have no direct equivalent are flagged for manual post-migration review. We do not migrate user passwords; all migrated users receive a password-reset workflow at cutover. Azure AD-backed user provisioning is coordinated with the customer's IT admin during the migration window.