CRM migration
Field-level mapping, validation, and rollback between aACE and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.
aACE
Source
Nutshell
Destination
Compatibility
7 of 12
objects map 1:1 between aACE and Nutshell.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from aACE to Nutshell is a migration from a FileMaker-backed ERP to a cloud-native CRM. aACE has no REST API — all extraction runs through FileMaker export scripts that write to a shared cache table, which we access under a dedicated migration user account to avoid collisions with active users. aACE Accounts map to Nutshell Companies, individual contact records within each Account map to Nutshell People, and aACE Sales Orders map to Nutshell Deals with stage and amount preserved. Invoices and Purchase Orders are operationally distinct from CRM Deals; we flag them for the customer's accounting team to handle separately or archive to a spreadsheet. aACE custom fields on Accounts, Orders, and Items are discovered from FileMaker layout definitions during scoping and mapped to Nutshell custom fields on Company, Person, and Deal. We do not migrate aACE workflows, projects, or binary document containers. We deliver a written inventory of these for the customer's admin to rebuild or re-enter.
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 Nutshell, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
aACE
Account
Nutshell
Company
1:1aACE Accounts are the primary customer and vendor records holding billing address, shipping address, and payment terms. They map 1:1 to Nutshell Company. Account.Name becomes Company.name, billing address becomes Company address fields, and payment terms are preserved in a custom field payment_terms__c if the customer intends to use Nutshell's billing module. Account is created before any Person import so that the Company lookup is satisfied at Person insert.
aACE
Account Location
Nutshell
Person
1:manyEach aACE Account can have multiple Locations, and each Location carries its own address and primary contact. We split each Location into a Nutshell Company record (for multi-location visibility) or into multiple Person records attached to the same Company (for contact-level tracking). The customer chooses the location strategy during scoping. Location address fields map to Person address fields or to additional Company address fields based on the chosen strategy.
aACE
Contact (Person record)
Nutshell
Person
1:1aACE Person records linked to an Account map to Nutshell Person records with a Company lookup back to the mapped Account-to-Company record. Person.FirstName, LastName, Email, Phone, and Title migrate directly. The Person's aACE record ID is preserved in a custom field aace_record_id__c for audit.
aACE
Sales Order
Nutshell
Deal
1:1aACE Sales Orders are the primary sales pipeline records linking a Customer Account to Line Items. They map to Nutshell Deals. The Sales Order number and description become Deal.name, the total order amount becomes Deal.amount, the order status (Open, Closed Won, Closed Lost) maps to a Nutshell pipeline stage, and the expected ship or close date becomes Deal.expected_close_date. Sales Order status is preserved in a custom field sales_order_status__c.
aACE
Sales Order Line Item
Nutshell
Deal Line Item (custom field)
1:manyaACE Sales Order Line Items hold Item, Quantity, Unit Price, and Discount. Nutshell has no native line-item object; we map line items into a custom multi-line text field line_items__c formatted as JSON or into individual custom fields (product_name__c, quantity__c, unit_price__c) per the customer's reporting needs. Item SKU migrates to a custom field item_sku__c on the Deal.
aACE
Item
Nutshell
Product (custom object)
1:1aACE Items (SKU, description, unit cost, pricing tier) map to a Nutshell custom Product object we create during schema setup. Item.SKU becomes Product.sku, Item.Name becomes Product.name, and Item.UnitCost becomes a custom field unit_cost__c. If the customer does not require a separate Product catalog, Items are mapped as custom fields on the Deal instead.
aACE
Invoice (Open)
Nutshell
Deal (flagged)
1:1Open aACE Invoices (A/R with outstanding balance) are flagged as operationally critical. We map Invoice.Amount, Invoice.Balance, and Invoice.DueDate to Deal-level custom fields invoice_amount__c, invoice_balance__c, and invoice_due_date__c so the A/R team can pursue collections post-migration. Closed historical invoices are archived to a CSV export, not imported into Nutshell's active CRM.
aACE
Purchase Order
Nutshell
Note (archived)
lossyaACE Purchase Orders link Vendors to Items and originating Sales Orders. Nutshell has no native Purchase Order object. Open POs with outstanding receipts are mapped to Nutshell Notes attached to the related Deal or Company for reference. Full PO history is exported as a separate CSV for the customer's accounting records.
aACE
Task
Nutshell
Activity
1:1aACE Tasks linked to Accounts, Sales Orders, or Projects map to Nutshell Activity records. Task.Subject becomes Activity.name, Task.DueDate becomes Activity.due_date, Task.Status (Not Started, In Progress, Complete) maps to Activity.status, and the assigned User becomes the Activity owner. Tasks without a date are imported as open activities with no due date.
aACE
Project
Nutshell
Deal (custom project flag)
lossyaACE Projects hold job headers with linked Tasks, Time entries, and billing. Nutshell has no native Project object. We map Project.Name and Project.Status to a Deal with custom fields is_project__c = true and project_status__c set. Tasks under the Project link to Deal Activities with a custom project_task__c flag. The customer reviews this mapping during scoping and may choose to archive Projects to CSV instead.
aACE
Employee
Nutshell
User (provisioned separately)
1:1aACE Employee records (name, email, department, role) are used to resolve the Owner mapping for Accounts, Sales Orders, and Tasks. We extract the email-to-name mapping but do not create Nutshell User records from Employees because User provisioning is a separate administrative step. Owners on migrated records are resolved via email lookup against the Nutshell User table.
aACE
Custom Fields (Account, Order, Item)
Nutshell
Custom Fields (Company, Deal, Person)
lossyaACE tenants frequently add custom fields to Accounts, Sales Orders, and Items via FileMaker layouts. There is no metadata API to enumerate them automatically. We request the customer share their FileMaker layout definitions during scoping and build the complete custom field list. Each discovered custom field is created as a typed Nutshell custom field (Text, Number, Date, Dropdown, Checkbox) before migration. Fields that have no Nutshell equivalent are written as JSON blobs in a custom notes field with a warning flag.
| aACE | Nutshell | Compatibility | |
|---|---|---|---|
| Account | Company1:1 | Fully supported | |
| Account Location | Person1:many | Fully supported | |
| Contact (Person record) | Person1:1 | Fully supported | |
| Sales Order | Deal1:1 | Fully supported | |
| Sales Order Line Item | Deal Line Item (custom field)1:many | Fully supported | |
| Item | Product (custom object)1:1 | Fully supported | |
| Invoice (Open) | Deal (flagged)1:1 | Fully supported | |
| Purchase Order | Note (archived)lossy | Fully supported | |
| Task | Activity1:1 | Fully supported | |
| Project | Deal (custom project flag)lossy | Fully supported | |
| Employee | User (provisioned separately)1:1 | Fully supported | |
| Custom Fields (Account, Order, Item) | Custom Fields (Company, Deal, Person)lossy | 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
Nutshell gotchas
Contact tier limits enforced on import
No bulk API endpoint requires paginated extraction
Email sequences not exportable via API
Foundation plan disables key sales features
Pair-specific challenges
Migration approach
Discovery and layout review
We audit the source aACE database via FileMaker layouts shared by the customer. We catalog every standard object (Account, Person, Sales Order, Invoice, PO, Item, Task, Project, Employee) and every custom field by reviewing the FileMaker layout definitions. We also extract the cache table structure, identify any FileMaker scripts the customer uses for exports, and document the file size and approximate record counts per object. This output is a written migration scope and a custom field inventory.
FileMaker export under migration user account
We work with the customer's aACE administrator to run FileMaker export scripts under a dedicated migration user account, scoped to one object type at a time. We clear the cache table before each batch to prevent stale records. Exports run in off-peak hours to avoid impacting active users who may simultaneously be running imports. The exported data is saved as CSV and validated against the aACE schema before transformation begins.
Schema design and custom field creation in Nutshell
We create the Nutshell custom fields identified during layout review before any data import. Custom fields are typed (Text, Number, Date, Dropdown, Checkbox) per their aACE counterparts. If the customer selected the multi-location strategy, we configure the Company and Person structure accordingly. If the customer needs a Product catalog, we create the Product custom object. Schema is validated in Nutshell before record import begins.
Sandbox migration and reconciliation
We run a full migration into a Nutshell trial or sandbox environment using production-like record counts. The customer reviews Company, Person, and Deal record counts, spot-checks 20-30 records against the aACE source, and signs off the schema and mapping before production migration begins. Any custom field mapping corrections, location strategy adjustments, or stage name alignments happen here, not in production.
Production migration in dependency order
We run production migration in record-dependency order: Companies (from aACE Accounts), Persons (with CompanyId resolved from Account mapping), Deals (with PersonId and CompanyId resolved), Activities (Tasks linked to Deals or Companies), and custom Product records (Items). Each phase emits a row-count reconciliation report before the next phase begins. Open invoices are mapped to Deal custom fields as flagged during scoping. Closed invoices and Purchase Orders are exported to CSV and archived, not imported as active CRM records.
Cutover, document handoff, and workflow inventory
We freeze aACE writes during cutover, run a final delta migration of any records modified during the migration window, then enable Nutshell as the system of record. We deliver the aACE document container export instructions to the customer's admin team. We deliver a written inventory of aACE custom fields not migrated, aACE Projects requiring manual re-entry or CSV archive, and aACE workflows or automation sequences (none of which migrate to Nutshell). We do not rebuild aACE workflows as Nutshell workflows; that is a separate engagement handled by the customer's admin.
Platform deep dives
aACE
Source
Strengths
Weaknesses
Nutshell
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 Nutshell.
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 Nutshell migration scoping. Not seeing yours? Book a call.
Walk through your aACE to Nutshell 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 Nutshell
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.