Our sales order data migration to CloudSuite ICS 2022 is failing during the customer validation phase. We’re migrating approximately 15,000 sales orders from our legacy CRM system, but the Data Migration Tool aborts with “Duplicate customer record detected for customer ID: CUST-10234”.
The issue is that our legacy CRM allowed multiple customer records with the same ID if they had different billing addresses (multi-location customers). CloudSuite appears to enforce customer ID uniqueness more strictly. When we try to import orders, the staging table validation catches these duplicates and blocks the entire batch.
We’ve identified around 800 customers with this duplicate ID problem out of 5,000 total customer records. Simply merging them isn’t straightforward because each location has distinct credit terms, payment history, and assigned sales reps. The legacy CRM data mapping doesn’t provide clear guidance on how to restructure these multi-location scenarios for CloudSuite’s customer master structure.
How should we handle customer ID uniqueness enforcement while preserving the multi-location business logic from our legacy system?
I encountered this exact scenario during our ICS 2022 implementation. The key is creating a customer ID transformation map during staging. Your legacy CUST-10234 with three locations becomes CUST-10234 (parent) with CUST-10234-01, CUST-10234-02, CUST-10234-03 as ship-to children.
The staging table validation will pass once you’ve properly mapped the parent-child relationships. Don’t skip this step - it’s critical for maintaining data integrity in CloudSuite’s customer master structure. We used a Python script to automatically generate the hierarchy based on legacy address data.
For the 800 affected customers, you need to analyze which location should be the parent. Usually it’s the corporate headquarters or the location with the highest transaction volume. The Data Migration Tool has a customer hierarchy import template specifically for this - use it before importing sales orders.
Also verify that your sales orders reference the correct child location IDs after restructuring. We had issues where orders pointed to the old unified customer ID and failed to link properly after the hierarchy was created.
Don’t forget about the financial implications. When you split a legacy customer into parent-child hierarchy, historical AR balances, credit limits, and payment terms need to be carefully allocated. We made the mistake of assigning all credit to the parent, which caused order holds for child locations.
Run an AR reconciliation report after customer migration but before sales order import. This catches discrepancies early.