Migrate from aACE to Twenty CRM

aACE Accounts are the primary customer and vendor records holding billing and payment terms. Every linked Sales Order, Invoice, Purchase Order, and Project references an Account. We map Accounts 1:1 to Twenty Company records and use the Account name as the Company.displayName dedupe key. Address fields split into Company.address/streetAddress, addressCity, addressState, addressCountry. Custom fields on Account migrate to custom fields on Company or serialize as a JSON note if Twenty's field type does not match.

aACE Sales Orders are the transactional core linking a Customer Account to Line Items and spawning Invoices and Purchase Orders. We map Sales Order headers to Twenty Opportunity records with amount, closeDate, and stageName resolved from the aACE order status. Open orders migrate first with their full line item detail preserved as Opportunity description or a linked Note. Closed orders migrate with a historical flag.

aACE Items hold SKU, description, unit cost, and pricing and link to Sales Orders, Purchase Orders, and Invoices as line items. We map Item.sku to Product.skuCode, Item.description to Product.description, Item.unitCost to a custom Product.unitCost__c field, and pricing tiers to price book entries in Twenty.

aACE tracks both open A/R and historical closed Invoices with full balance and payment history. Twenty CRM has no native Invoice object. We migrate open Invoices as a custom Invoice custom object with header fields (invoice number, date, due date, total amount, balance) and line items as Note records linked to the Company. Closed invoices migrate as historical Note records with an archived flag.

aACE Purchase Orders link to Items, Vendors, and the originating Sales Order. They represent supply-chain data that Twenty CRM does not natively model. We migrate PO headers and line items as a custom PurchaseOrder custom object or as Note records linked to the Vendor Company. Partial receipts and PO status are preserved as custom fields.

aACE Projects hold the job header and link to Tasks, Time entries, and billing records. We create a Project custom object in Twenty before migration, preserving Project status, dates, assigned user, and related Task links. If Twenty has a native project management module at migration time, we remap to the native object instead.

aACE Tasks are unit-of-work records linked to Projects and optionally to Accounts and Orders. We preserve task title, status, assignee, due date, and any custom flag fields. High-volume task exports use FileMaker's batch cache mechanism with a dedicated migration user to avoid colliding with active users.

aACE Employee records hold name, email, department, and role. We map active Employees to Twenty UserInvite records so the customer's admin can complete onboarding. Historical employees with no active login map to a People record with an inactive flag.

aACE supports multiple locations per Account, each with its own address and contact record. We create the primary Company record from the Account and add additional addresses as Company address fields or as a custom Location custom object linked to the Company.

aACE Distribution Lists are FileMaker portal-based address-book groupings. These migrate as a custom Group custom object with a many-to-many join table linking to People records, or as tags on People records depending on the customer's scoping preference.

aACE tenants frequently add custom fields to standard objects via FileMaker. There is no metadata API to enumerate these fields. We request FileMaker layout definitions during scoping, build the complete custom field list, pre-create matching custom fields in Twenty's Settings Data Model, and migrate the values. Fields that cannot map to a compatible Twenty field type serialize as JSON in a custom text field.

FileMaker container fields store attachments, signatures, and scanned documents inside the aACE database. Export scripts do not reliably extract container binary data, and aACE exposes no separate document API. This is a known limitation. We flag documents and attachments for a separate FileMaker-native document export step and do not include binary container data in the primary migration scope.