Migrate from ERPnext Enterprise - Bespoke to Infor CloudSuite Corporate

ERPNext Customer DocType maps 1:1 to Infor CloudSuite Business Partner (Customer) record. We preserve name, territory, territory hierarchy, contact details, tax ID, and payment terms. CloudSuite requires the Customer record to exist before any Sales Order import because Sales Orders carry a required Customer reference. Custom fields attached to the ERPNext Customer DocType require pre-configuration on CloudSuite as extension fields before the Customer import phase runs; we export the Custom Field definitions during scoping and create the equivalent extension schema in CloudSuite first.

ERPNext Supplier DocType mirrors the Customer DocType structure and maps to Infor CloudSuite Business Partner (Supplier) record. Supplier type, payment terms, and address records carry forward. ERPNext's supplier-specific tax categories stored as Custom Fields on the Supplier DocType migrate as extension fields on the CloudSuite Supplier record. Supplier records must be imported before any Purchase Order import because PO header carries a required Supplier reference.

ERPNext Item DocType carries a large attribute set: item code, description, item group, stock UOM, valuation method, barcodes, and custom fields. We preserve the full item master including barcodes and any item-level custom fields. ERPNext UOM handling (each item has a stock UOM with conversion ratios to other UOMs) maps to CloudSuite Item UOM schedules. Item group hierarchies from ERPNext map to CloudSuite product categories. Items must be fully imported before BOM import because BOM child items reference item codes that must exist.

ERPNext BOMs are nested structures referencing Items with quantity ratios and operation routing. We map BOM hierarchies directly but validate that all child item codes exist in the CloudSuite target before committing the BOM record. CloudSuite does not support core code modifications, so any Frappe server scripts handling material requirements calculations or alternate BOM selection must be rebuilt as manual configuration or documented for the CloudSuite partner. Multi-level BOM nesting (parent BOM referencing child BOMs) requires careful dependency ordering during import.

ERPNext Sales Order DocType maps to CloudSuite Sales Order with headers, line items, taxes, discounts, and shipping details preserved 1:1. The Customer reference on each order is resolved to the CloudSuite Customer record via the Customer mapping before the Sales Order import phase. Advance allocation records on ERPNext Sales Orders require separate handling as Payment Entries and are flagged as a distinct workflow during scoping. We preserve the qty-delta logic against Delivery Notes for open orders.

ERPNext Purchase Order DocType mirrors Sales Order structure and maps to CloudSuite Purchase Order with headers and line items preserved. The Supplier reference is resolved via the Supplier mapping before PO import. Any advance allocation records on ERPNext Purchase Orders require separate handling as Payment Entries because advance allocations are not a native PO line item in CloudSuite.

ERPNext uses a voucher-based double-entry system where each Journal Entry contains multiple debit and credit rows against account codes. We map journal entry rows to CloudSuite GL account codes, but the target chart of accounts must have matching account numbers. Pre-migration chart of accounts alignment is a required workstream before any GL data moves. We also flag any ERPNext voucher types (Bank Voucher, Stock Voucher, Payment Voucher) and map them to the equivalent CloudSuite journal types.

ERPNext Stock Ledger Entry records link warehouse, item, and valuation rate per movement. We migrate open stock positions as snapshot records for current inventory valuation; historical movement logs require bulk CSV export from ERPNext (the REST API does not expose a bulk-read endpoint for SLEs) and transformation to CloudSuite inventory movement format. High-row-count SLE tables are the primary reason we fall back to direct DB export rather than API-based reads for this object.

ERPNext Projects carry a nested task hierarchy with assignees, start and end dates, billable hours, and custom task fields. We map the full project-task tree 1:1 into CloudSuite Project and Activity records, including hourly rate settings. ERPNext project-level custom fields and task-level custom fields require pre-configuration on CloudSuite as extension fields before the project import phase. Task hierarchy nesting depth is preserved by setting parent references before child task inserts.

ERPNext Employee DocType contains employment details, department, and reporting structure. We migrate active employees and current compensation records. Payroll history and historical salary data are migrated as optional scope based on the customer's reporting requirements. ERPNext country-specific fields (statutory deductions, leave policy, regional tax IDs) map to CloudSuite Employee extension fields, which require country-specific configuration and should be reviewed against local labour compliance requirements.

ERPNext Custom Fields attach to any DocType via the Custom Field DocType. We export all custom field definitions separately, including the target DocType, field label, field type, and default value. These definitions are applied on CloudSuite as extension fields before the associated data import phase. Field types are mapped to CloudSuite equivalents (text, integer, float, date, select, check). Custom Fields on Item DocType are applied before Item import; custom fields on Customer and Supplier before those imports.

ERPNext User records include email, full name, enabled status, and role profiles. We map enabled users and their role assignments. ERPNext role permission rules export as configuration and are documented for manual reapplication in CloudSuite, because permission structures are destination-platform-specific and cannot be transferred as executable code. User records without a matching CloudSuite User are held in a reconciliation queue for the customer's admin to provision before record import resumes.

ERPNext stores contacts and addresses as separate DocTypes linked by Dynamic Links. We resolve these relationships during export to produce flat contact records with embedded address data compatible with CloudSuite's separate Address and Contact entities. Address formatting rules from ERPNext (country-specific address templates) carry forward as CloudSuite address format configuration. Multi-address scenarios per Customer or Supplier (billing vs shipping address) map to separate CloudSuite Address records with the appropriate address purpose flag.