Migrate from Brightpearl to Infor CloudSuite Corporate

Brightpearl stores customers and vendors as Contact records differentiated by a role flag. Customer-role Contacts map to Infor Business Partner records with PartnerType set to Customer. We preserve the contact's email, phone, addresses, and owner assignment. The PCF_* custom fields migrate to Infor OS custom fields with a pcf_ prefix convention. Country and postal address fields require normalisation: Brightpearl requires full country names (not ISO codes) matching Settings > Localization > Countries exactly, and Infor similarly requires country values matching its internal country string list — we apply a two-pass normalisation against both systems' published country lists before import.

Vendor-role Contacts in Brightpearl map to Infor Business Partner records with PartnerType set to Supplier. Lead time, payment terms, and address data transfer. The distinction between customer and vendor role is critical at migration time because Infor enforces Business Partner type as a filter on Purchase Order and AP workflows — misclassified contacts will cause purchase order routing failures in Infor.

Brightpearl Products (SKUs, product types, price list assignments, and PCF_* custom fields) map to Infor Item records. We preserve product code as Item code, product name as description, and multiple price list assignments by creating Infor Price List records and linking them to the Item. Product type (goods vs service) determines the Infor Item type flag. The Brightpearl product taxonomy (category hierarchy) maps to Infor's item classification structure.

Brightpearl's four-level location hierarchy (Aisle / Bay / Shelf / Bin) grouped into Zones requires flattening to a location path string for Infor. We represent each Brightpearl location as a slash-delimited path (e.g., Zone-A / Aisle-01 / Bay-A / Shelf-01 / Bin-001) and reconstruct the zone association as a separate Infor zone record with location membership. Zone-to-warehouse linkage is preserved as Infor warehouse assignment on each location record. This transformation is the most structurally complex mapping in a Brightpearl migration because Brightpearl treats the four levels as independent dimensions while Infor's location model is more flat.

Brightpearl Sales Orders map to Infor Sales Order records with line items, pricing, discounts, and fulfilment status preserved. Order numbers, order dates, and owner assignments transfer directly. The parent Contact (customer) must resolve to a Business Partner in Infor before the Sales Order imports — we perform Business Partner lookup by email as a pre-import step. Brightpearl's order-status workflow states map to Infor's order status codes. We flag orders in pending status with placeholder contacts as high-risk because Brightpearl requires a valid formatted placeholder contact; these orders require manual resolution before Infor import.

Brightpearl Purchase Orders map to Infor Purchase Order records with vendor assignment, lead time, expected delivery dates, received quantities, and line items. The parent Business Partner (Supplier) must resolve by matching the Brightpearl vendor contact email to an Infor Business Partner record before PO import. Received quantities and backorder flags transfer to maintain the PO lifecycle state in Infor.

Brightpearl invoices and credit notes map to Infor AR Invoice and Credit Memo records. Accounting data embedded in Brightpearl invoice records (GL account references, tax amounts, line-level discounts) require cross-referencing against the Chart of Accounts mapping before import. Invoice PDFs do not transfer automatically; we flag them for the customer's admin to re-attach in Infor Document Management post-migration. Historical invoices in Brightpearl's closed accounting periods map to Infor posted transactions, which is the most sensitive financial mapping in the migration.

Brightpearl's Chart of Accounts with account codes maps to Infor's Chart of Accounts structure. We export the full account code list from Brightpearl and map each to the corresponding Infor account code, preserving account type (asset, liability, equity, revenue, expense) and subaccount structure. The account mapping is a prerequisite for all financial document imports (invoices, credit notes, purchase orders) because these documents reference account codes. We flag any Brightpearl accounts with no direct Infor equivalent for the customer's finance team to resolve before the financial data migration phase.

Brightpearl Price Lists (a price value associated with a product and a price list identifier) map to Infor Price List records. Multiple price lists per product are supported in both systems. We export all price list assignments from Brightpearl and create corresponding Infor Price List records, then link each to the mapped Item records. Price type (wholesale, retail, contract) and currency transfer directly.

Brightpearl inventory summary (total cost value per SKU) maps to Infor inventory valuation records. Summary data provides the opening inventory position for Infor's costing engine. We use this to seed Infor's on-hand quantity and average cost per item before the detail-level inventory migration runs.

Brightpearl inventory detail (per-warehouse, per-location stock levels) maps to Infor inventory detail records with warehouse and location references resolved via the warehouse location mapping. We reconstruct the per-SKU per-location stock position from Brightpearl's inventory detail export and load it into Infor with location references resolved to the flattened location path strings. This mapping runs after both the warehouse location hierarchy and the inventory summary mappings are complete.

Brightpearl staff members assigned as Owners of Contacts and Orders map to Infor User records. We resolve owners by email match against the Infor destination User table. Any Brightpearl Owner without a matching Infor User is placed in a reconciliation queue — the customer's Infor admin provisions the missing Users (active or inactive depending on whether the original Brightpearl user is still employed) before record import resumes. Owner resolution is a gate for all subsequent object imports because Order and Contact records reference OwnerId.