Migrate your reybex data

Customer records are standard relational entries with name, address, and contact fields accessible via both API methods. We map them 1:1 for most destinations, preserving country-specific address structures and language variants where present.

Articles represent SKUs with variant matrices (size, color, etc.) stored as structured rows. Variant attributes must be unpacked into destination-specific product schema. We handle multi-language article descriptions by selecting the primary language during import.

Order headers and line items are accessible via API. We preserve order status, pricing, discounts, and fulfillment tracking. Note that cancelled or archived orders may require separate scoping to confirm completeness of the history.

Purchase orders map to vendors and expected receipts. Vendor relationships may need reconciliation against the destination vendor master. PO approval workflows do not transfer and must be reconfigured in the target system.

Real-time stock quantities are tied to warehouse locations and lot/batch tracking. We export current stock positions and warehouse assignments; bin-level or serialized stock requires custom field mapping.

Financial accounting integration means invoices carry GoBD-compliant metadata including tax codes and document numbers. We map invoice line items to chart-of-accounts entries and flag any multi-currency invoices for exchange-rate handling.

Bank statements and cash register (POS) transactions are stored in German compliance format. TSE-signed receipts must be mapped to equivalent audit trails in the destination; we extract transaction dates, amounts, and payment methods.

Project records include tasks, time entries, and budgets. Task dependencies and milestone hierarchies require flattening during export and reconstruction in PM-oriented destinations.

BOMs (bills of materials) and production routings are stored as structured data. We map finished-goods outputs and material consumption lines; machine capacity planning data does not transfer natively.

Sales activities (calls, emails, notes) are tied to customer records. Activity types and timestamps migrate; custom activity fields require schema discovery before mapping.

Custom fields on Articles and Customers are supported but require schema discovery per tenant. We detect all custom field definitions during the pre-migration audit and generate a mapping matrix before import.

EDI transaction sets (ORDERS, INVOIC, DESADV) are platform-native and cannot be meaningfully migrated to non-EDI systems. We export EDI metadata and partner assignments but recommend re-establishing EDI connectivity post-migration.