Migrate your Visibility ERP data

Visibility supports multi-level, phantom, and configured BOMs. During migration, we preserve the full BOM hierarchy by walking the parent-component tree and mapping each level's routing association. Phantom BOMs require us to suppress the phantom entity and roll its components into the parent.

Work Orders carry job-specific routing steps, labor estimates, material allocations, and status histories. We map open Work Orders by status (Released, In Process, Closed) and carry forward the full step sequence. Historical closed Work Orders can be migrated as reference records with a flag to exclude from live shop-floor systems.

Production Orders in Visibility reference the BOM and Routing to generate material and labor requirements. We map the Production Order header, its linked BOM revision, and the operation step sequence. Where destinations lack a separate Production Order object, we merge into Work Orders and preserve production-type as a custom field.

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 explicit field-level mapping during scoping.

Sales Orders in Visibility capture the full quote-to-invoice lifecycle including configured lines, pricing, discounts, and shipment schedules. We migrate open and historical Sales Orders with line-item detail. Order status transitions are preserved as a lifecycle custom field on the destination.

Open Purchase Orders with line items, vendor assignments, scheduled receipts, and unit costs migrate directly. We map the PO header to the destination's PO object and flatten line-level detail including partial receipt quantities and item descriptions.

Visibility tracks lot numbers, serial numbers, expiration dates, and bin locations. Lot-controlled items require us to map the lot assignment at the inventory transaction level, not just the item master. We flag items that are lot-tracked in the source but not in the destination before migration runs.

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 can accommodate the source's account codes. Account-segment mismatches are flagged before import begins.

Open invoices, credit memos, and payment records carry customer/vendor references, due dates, and aging buckets. We map open AP/AR by aging period and preserve the original invoice numbers as reference fields on the destination. Historical closed records are migrated as read-only archive entries unless the customer specifies otherwise.

QC inspection results, non-conformance records, and corrective actions link to Work Orders and inventory transactions. We migrate QC records as related children of their parent Work Orders, mapping pass/fail status and inspector notes. Custom QC checklist fields require explicit value mapping.

Visibility's Document Management module stores files and revisions linked to entities across the system. There is no publicly documented bulk export endpoint for the document repository. We do not migrate binary documents — only the document metadata (name, revision, linked entity, date) is carried forward as a cross-reference index for manual re-upload.

Visibility allows user-defined fields across most major objects. We extract the custom field schema during scoping and map each field individually to the destination's equivalent. Custom fields that use dropdown or list values require value-level cross-reference tables to avoid silent data corruption at import time.

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 destination equivalent. Users without email addresses in the source cannot be auto-provisioned in cloud destinations and are flagged for manual handling.