CRM migration
Field-level mapping, validation, and rollback between aACE and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
aACE
Source
Freshsales
Destination
Compatibility
4 of 10
objects map 1:1 between aACE and Freshsales.
Complexity
BStandard
Timeline
2-3 weeks
Overview
Moving from aACE to Freshsales is a narrowing migration: aACE combines accounting, CRM, order management, inventory, purchasing, and project management in one FileMaker database, while Freshsales is a purpose-built sales CRM with Contacts, Accounts, Deals, and Activities. We extract from aACE using FileMaker export scripts and cache tables (there is no REST API), map the relational Account-Order-Invoice chain to Freshsales Account-Contact-Deal, and preserve Tasks, custom fields, and historical timestamps. Accounting data (open Invoices, Purchase Orders) migrates as read-only Deal notes or custom fields because Freshsales has no native accounting objects. Workflows, FileMaker automation scripts, and document containers do not migrate; we deliver a written inventory of these for the customer's admin to address post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a aACE object lands in Freshsales, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
aACE
Accounts
Freshsales
Account
1:1aACE Accounts are the primary customer and vendor records, holding billing and payment terms. All linked Orders, Invoices, and Purchase Orders reference the Account. We map Accounts 1:1 to Freshsales Account, preserving the company name, billing address, shipping address, and payment terms as custom fields. The Freshsales Account becomes the parent entity before any Contact import begins.
aACE
Accounts (Contacts)
Freshsales
Contact
1:manyaACE supports multiple location contacts per Account with their own address and contact record. We split these into Freshsales Contact records linked to the parent Account, preserving first name, last name, email, phone, title, and the specific location address. Any contact roles defined in aACE (purchasing contact, accounts payable contact) migrate as a custom Contact field.
aACE
Sales Orders
Freshsales
Deal
1:1aACE Sales Orders are the transactional core, linking a Customer Account to Line Items and spawning Invoices and Purchase Orders. We map open Sales Orders to Freshsales Deals with the Account resolved, deal name from the Sales Order number, amount from the total, and close date from the expected ship date. Historical closed orders migrate as completed Deals with the original close date preserved.
aACE
Sales Order Line Items
Freshsales
Deal Product
1:manyaACE Sales Order Line Items map to Freshsales Deal Products. We resolve the Item (SKU, description, quantity, unit price) and link it to the parent Deal during migration. Line item notes and special instructions migrate as a custom product field because Freshsales Deal Products have no native notes field.
aACE
Projects
Freshsales
Deal or Task
lossyaACE Projects hold job headers and link to Tasks, Time entries, and billing records. We discuss with the customer whether Projects map to Freshsales Deals (for billing-trackable work) or to Tasks grouped under a parent Deal (for work-management use cases). We migrate Project status, assigned user, and description as fields on the target record.
aACE
Tasks
Freshsales
Task
1:1aACE Tasks are unit-of-work records linked to Projects and optionally to Accounts and Orders. We preserve task subject, status, assignee (resolved via user email mapping), due date, priority, and any custom flag fields. High-volume task exports use FileMaker's batch export to the cache table before loading into Freshsales via the Tasks API endpoint.
aACE
Employees
Freshsales
User
1:1aACE Employee records hold name, email, department, and role data. We map active Employees to Freshsales User records by email match, preserving the user's display name and primary department as a custom field. The customer's Freshsales admin provisions the actual Freshsales login credentials during the User provisioning step.
aACE
Invoices
Freshsales
Deal Note or Custom Field
lossyaACE tracks open A/R and historical closed Invoices with balance and payment history. Freshsales has no native Invoice object. We migrate open Invoice amounts as a custom numeric field on the related Account (open_ar_balance__c) and flag historical Invoices in a Deal note for audit purposes. Customers requiring full invoice history in Freshsales configure a separate accounting integration post-migration.
aACE
Custom Fields
Freshsales
Custom Fields
lossyaACE tenants add custom fields on Accounts, Orders, and Items via FileMaker. There is no metadata API to enumerate these automatically. We request FileMaker layout definitions during scoping, build the complete field list, and map each to a Freshsales custom field of the appropriate type. Fields without a Freshsales type equivalent are written as JSON in a text field.
aACE
Company Locations
Freshsales
Account Address or Contact Address
1:manyaACE supports multiple locations per Account, each with its own address and contact. We map each location to a Freshsales Contact record with the specific location address, linked to the parent Account. If the customer uses location-based routing or shipping assignment, we flag these as custom fields for territory configuration in Freshsales.
| aACE | Freshsales | Compatibility | |
|---|---|---|---|
| Accounts | Account1:1 | Fully supported | |
| Accounts (Contacts) | Contact1:many | Fully supported | |
| Sales Orders | Deal1:1 | Fully supported | |
| Sales Order Line Items | Deal Product1:many | Fully supported | |
| Projects | Deal or Tasklossy | Fully supported | |
| Tasks | Task1:1 | Fully supported | |
| Employees | User1:1 | Fully supported | |
| Invoices | Deal Note or Custom Fieldlossy | Fully supported | |
| Custom Fields | Custom Fieldslossy | Mapping required | |
| Company Locations | Account Address or Contact Address1:many | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
aACE gotchas
No public API — FileMaker export scripts only
FileMaker cache table is shared per-user
Custom fields require manual field-discovery
Binary document containers are not migrated
Freshsales gotchas
Freddy AI is Pro-tier only despite heavy marketing
Post-migration emails and sequences are disabled
Bot session credits are a one-time 500-session allocation
Phone credits charged per minute with no cap
File storage limits scale with plan tier
Pair-specific challenges
Migration approach
Discovery and export script preparation
We audit the source aACE database: Account count, Sales Order volume, Task volume, custom field inventory (via FileMaker layout review), and any Project or location records. We prepare the FileMaker export scripts under a dedicated migration user account, test them against a sample batch, and validate the cache table output before scaling to full export. We also confirm the Freshsales destination account plan tier (Growth, Pro, or Enterprise) because it determines the API rate limit we design the load pipeline around.
Freshsales schema preparation
We configure the Freshsales destination: standard objects (Account, Contact, Deal, Task), custom fields matched to the discovered aACE custom fields, Deal stages mapped to the customer's order status matrix, and User records provisioned for the sales team. If the customer uses location-based routing or multi-location shipping, we set up Freshsales territories at this stage. Schema configuration happens in a Freshsales sandbox or staging account before any data loads.
FileMaker export and data validation
We run FileMaker exports for each object type in dependency order: Accounts first, then Contacts (with Account parent resolved), then Sales Orders (with Account resolved), then Line Items, then Tasks. Each export writes to the FileMaker cache table, is validated against the aACE schema, and is exported as CSV. We clear the cache table before each batch to prevent stale records. The customer reviews the exported CSV files and confirms record counts before we proceed to the Freshsales load phase.
Freshsales data load with rate-limit handling
We load data into Freshsales via the REST API, respecting the plan-tier rate limit (1,000/hour on Growth, 2,000/hour on Estate, 5,000/hour on Forest/Enterprise). For high-volume Task imports, we use batch chunking and exponential backoff on 429 responses. Accounts load first so that Contact.AccountId resolves correctly at insert time. Sales Orders load as Deals with the AccountId resolved. Line Items load as Deal Products with Price Book entries created first. Tasks load last, with owner resolution via the Employee-to-User email mapping.
Reconciliation and gap analysis
We produce a row-count reconciliation report comparing source aACE record counts to destination Freshsales record counts for each object. We spot-check fifteen to twenty records per object against the source for field-level accuracy. Any gaps (records that failed import due to validation rules or missing parent lookups) are investigated and corrected. Custom fields that produced JSON blobs are flagged for the customer to review post-migration.
Cutover and automation inventory handoff
We freeze aACE writes during cutover, run a final delta migration of any records created or modified since the last export, then mark Freshsales as the system of record. We deliver the automation and script inventory document listing every aACE FileMaker automation script and its recommended Freshsales workflow equivalent. We do not rebuild FileMaker scripts as Freshsales workflows inside the migration scope; that work is handled by the customer's admin or a separate Freshsales implementation engagement.
Platform deep dives
aACE
Source
Strengths
Weaknesses
Freshsales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across aACE and Freshsales.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
aACE: Not publicly documented for aACE itself. The underlying Claris FileMaker Data API caps concurrent sessions per server license, so high-volume extracts must be chunked and timed against the customer's FileMaker Server capacity (confirmed during scoping)..
Data volume sensitivity
aACE doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during aACE to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your aACE to Freshsales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave aACE
Other ways to arrive at Freshsales
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.