Migrate from Visibility ERP to Infor CloudSuite Corporate

Visibility supports multi-level, phantom, and configured BOMs. We walk the parent-component tree to preserve the full hierarchy during migration, mapping each level's routing association to Cloudsuite's Item BOM structure. Phantom BOMs map as BOM lines with a phantom flag. P-level components require a special mapping to Cloudsuite's non-stock item or configured item model. We validate that the destination BOM revision is active at import time; inactive revisions are locked per the revision-mapping table.

Visibility Work Orders carry routing steps, labor estimates, material allocations, and status histories. We map open Work Orders by status (Released, In Process, Hold) and carry forward the full step sequence. Work Orders referencing a BOM revision that is not active in the destination will fail import unless we lock the destination to the corresponding revision or map to the latest active revision explicitly; we flag all revision-locked Work Orders during scoping.

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. The parent Work Order reference is resolved at import time by matching Work Order number.

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 a bespoke field map during scoping because Visibility's custom field schema is not exposed in public API documentation.

Sales Orders in Visibility capture the full quote-to-invoice lifecycle including configured lines, pricing, discounts, and shipment schedules. We migrate open Sales Orders with line-item detail, configured line references, and pricing. Historical orders (Closed, Invoiced) migrate as reference records only; active orders migrate with full detail to preserve the open invoice state in Cloudsuite.

Open Purchase Orders with line items, vendor assignments, scheduled receipts, and unit costs migrate directly. We map the PO header to Cloudsuite's Purchase Order object and flatten line-level detail including receipt schedules. Vendor tax and payment terms map to Cloudsuite's vendor master fields. Closed POs migrate as reference records.

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 preserve expiration dates and lot status (Available, Quarantine, On Hold) as Cloudsuite lot attributes. Serial number history migrates as a linked transaction log.

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 Cloudsuite's segment structure matches before importing. Segmented account codes require decomposition into Cloudsuite's segment fields (Company, Division, Department, Account). We flag any account segments that exceed Cloudsuite's character limits.

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. Customer and vendor IDs are resolved against the migrated business partner master before invoice records insert.

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 parent references at import time. Standalone QC records without a parent Work Order require manual assignment in Cloudsuite's QC module post-migration.

Visibility's Document Management module stores binary files linked to entities across the system. There is no publicly documented bulk export endpoint. We do not migrate binary document content. We do carry forward document metadata (filename, revision, linked entity, creation date) as a cross-reference index so the customer can manually re-upload files to Cloudsuite's document management system. File count and average size inform the manual effort estimate we provide in the migration workback.

Visibility allows user-defined fields across most major objects, but the custom field schema is not exposed in any public API documentation. We request a custom field export during scoping—typically via a database-level query or a Visibility-supported report—and build a bespoke field map before any import begins. Custom fields that cannot be mapped to a Cloudsuite equivalent are flagged as manual entry candidates or stored as extended data.