Migrate from WennSoft to Twenty CRM

Twenty enforces strict CSV import dependency order — Companies must precede People

Twenty's CSV import function resolves foreign-key relationships at import time: a Person record with a companyId must reference an existing Company record. WennSoft stores Customers with embedded location and company data in a single record, but Twenty separates People and Companies into distinct objects. We must export, transform, and import Companies first, then resolve the companyId on each Person record before importing People. Circular references (WennSoft locations pointing back to the parent customer as a company) are flagged and resolved by assigning the primary location as the Company and storing additional locations as a custom field or secondary address on the Person.

Twenty validates unique field values against soft-deleted records — duplicates may restore deleted data

Twenty's uniqueness validation checks both active and soft-deleted records. WennSoft does not enforce uniqueness at the field level across the GP database — duplicate Customer IDs or Equipment Numbers can coexist in separate tables. During migration, importing a record with the same unique value as a soft-deleted Twenty record will restore that deleted record instead of creating a new one. We audit WennSoft for duplicate identifiers before export and prepend a prefix (e.g., WS-) to WennSoft IDs during import to avoid unintended record restoration while preserving traceability to the original WennSoft system ID.

Equipment Records have no direct Twenty CRM equivalent — custom object creation is required before import

Twenty's standard CRM objects (People, Companies, Opportunities, Tasks) do not include an Equipment entity. WennSoft Equipment Records (with manufacturer model, serial number, install date, and service contract status) must be mapped to a custom object created in Twenty's Data Model before any import runs. The custom object requires Fields to be created first via Settings → Data Model, and the import sequence must account for the new Equipment object appearing last in the dependency chain. If the Equipment custom object is not created before the migration sample run, Tasks linked to equipment records via ID will fail to resolve and land in an error state.

Workflows, triggers, and GP-integrated automations do not migrate — rebuild is required in Twenty's workflow builder

WennSoft Signature stores workflow logic in GP triggers, SmartList-based automations, and billing rate matrices that execute within the Dynamics GP event model. Twenty's workflow builder operates on CRM objects with a different trigger/action paradigm — it listens to record create/update events on People, Companies, Opportunities, and Tasks and executes actions scoped to those objects. GP table events, posting routines, and extended pricing matrix logic have no equivalent in Twenty's workflow engine. We export WennSoft workflow definitions as a reference document for your Twenty admin to rebuild in Settings → Data Model → Workflows, but the migration itself carries no automation logic.

Twenty's CSV export is capped at 20,000 records per file — large WennSoft datasets require batched API pulls

Twenty's UI-based export (⋮ → Export view) is limited to 20,000 records per CSV. WennSoft customers with large equipment fleets or high service-call volumes can exceed this ceiling. We pull WennSoft data via API (or GP database direct query for on-premises instances) in batched queries using offset pagination or date-range filters, then compose the CSV files in chunks of 18,000 records to stay within the limit with margin for validation errors. This approach also allows us to parallelize the migration pipeline and reduce total migration time for large datasets.