Migrate from Herbst Insight ERP to Infor CloudSuite Corporate

Herbst Customer records carry billing address, shipping address, contact details, credit limit, and payment terms in a single master record. We map these directly to Infor CloudSuite Customer using the customer code as the dedupe key. If Herbst uses a vendor hierarchy for related entities, we map the top-level parent to the Infor Customer and create subsidiary entities as distinct Customer records with a ParentCustomer relationship where the destination schema supports it.

Herbst Supplier records store address, banking details, and purchasing terms. We map vendor code, name, and payment terms to the Infor Supplier table. Any open Purchase Order references attached to the Supplier account are migrated as PO header records with line-item detail in a subsequent phase, with the Supplier resolved by vendor code before PO import begins.

Herbst Items carry SKU, description, pricing, cost, stock-control settings, and BOM data for manufacturing variants. We map the primary SKU to Infor Item code, variant attributes to Infor's UOM and dimension structure, and BOM records to the Infor Bill of Materials module where applicable. Stock location, batch, and serial number fields vary by warehouse configuration — we harmonise these during the inventory phase.

Herbst Chart of Accounts is fully exportable with account codes, names, and posting-level flags. We map account codes directly to Infor GL account segments and preserve the posting-level flag (balance sheet vs. P&L) on each account. Tax codes are handled as separate mapping entities and must be reconciled against Infor's tax setup before AP/AR loads begin.

Open payables and receivables are migrated as balanced header-level records with line-item detail to maintain referential integrity in Infor. We export Herbst AP and AR as separate header-line tables, compute the running total per account, and validate against Herbst's trial balance before loading. Any orphaned lines (no matching header or no matching supplier/customer) are escalated to a reconciliation queue before the Infor import step runs.

Order history is exported from Herbst as header status, line items, and fulfillment links. We preserve order number, order date, status, and line-item detail including quantity, price, and tax. Partial or voided orders require explicit status-mapping decisions during scoping. Completed orders migrate as historical records; open orders migrate as active records and are validated against the Customer, Supplier, and Item lookups that were resolved in earlier phases.

Herbst stock records include location, batch, and serial number fields that vary by warehouse configuration. We export multi-warehouse stock records per location code, harmonise bin-level data against the destination warehouse structure, and load stock quantities as inventory transactions with a transfer or adjustment flag. Serial and batch numbers are preserved where the destination schema supports them.

Herbst payroll stores effective-dated compensation, deduction codes, and payroll run history subject to Irish employment law. We migrate payroll as summarised records (annual earnings, tax deductions, pension contributions) rather than granular timesheet lines to avoid jurisdiction-mapping errors. The customer finance and HR leads must approve the payroll schema before we proceed with any compensation data load. Infor CloudSuite HCM is a separate module; payroll summaries can load into CloudSuite Financials as GL journal entries or into a dedicated HCM system depending on scope.

Herbst user records include role assignments and access permissions that do not map 1:1 to Infor's role-based security model. We extract the user list with email, name, and role flags as a reconciliation report. The customer's Infor administrator provisions matching users and assigns Infor role permissions based on our report. Active vs. inactive status is preserved as a boolean flag for the admin to resolve during provisioning.

Herbst allows custom fields within modules. We catalog every custom field definition during discovery, document the Herbst field name, data type, and associated module, and produce a written field map recommending an Infor extended field or user-defined field equivalent. The Infor administrator creates the destination fields before migration; we do not provision them as part of the data load because Infor's extended field creation is an administrative task that requires Infor OS or consultant access.