CRM migration
Field-level mapping, validation, and rollback between aACE and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
aACE
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
7 of 10
objects map 1:1 between aACE and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
3-5 weeks
Overview
Migrating from aACE to Microsoft Microsoft Dynamics 365 Sales means leaving a FileMaker-backed ERP consolidation environment for a cloud-native CRM with deep Microsoft 365 integration. aACE exposes no REST API, so we extract data through FileMaker export scripts scoped to a dedicated migration user, chunk by object type, and validate against the cache table before loading into Dynamics via the Dataverse API. We preserve relational links from aACE Orders to their Line Items, Invoices, and Shipments as explicit lookups in Dynamics, and we flag Purchase Orders and Projects for a separate scoping conversation because those objects sit at the ERP boundary that Microsoft Dynamics 365 Sales does not cover natively. Custom fields discovered from aACE FileMaker layouts map to Dynamics custom fields or serialize as JSON blobs in note fields to prevent silent data loss. Workflows, automations, and FileMaker container documents are not migrated.
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.
Source platform
aACE platform overview
Scorecard, SWOT, gotchas, and pricing for aACE.
Destination platform
Microsoft Dynamics 365 Sales platform overview
Scorecard, SWOT, gotchas, and pricing for Microsoft Dynamics 365 Sales .
Data migration guide
The complete Microsoft Dynamics 365 Sales migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Microsoft Dynamics 365 Sales migration checklist
Pre- and post-cutover tasks for moving onto Microsoft Dynamics 365 Sales .
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 Microsoft Dynamics 365 Sales , including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
aACE
Account
Microsoft Dynamics 365 Sales
Account
1:1aACE Accounts (the primary customer and vendor record) map directly to Dynamics 365 Account. The Account holds billing and payment terms, and all linked Orders, Invoices, and Locations reference it. We preserve the aACE Account number as AccountNumber and the primary contact reference as a Lookup to the related Contact record.
aACE
Company Location
Microsoft Dynamics 365 Sales
Account Address ( Dynamics 365 Customer Address table)
1:manyaACE supports multiple locations per Account, each with its own address and contact record. We migrate each location as a separate Dynamics 365 Customer Address record linked to the parent Account, using the address purpose (billing, shipping, primary) from aACE's location type field. Primary location address populates the Account's default billing and shipping address fields.
aACE
Item
Microsoft Dynamics 365 Sales
Product
1:1aACE Items (inventory-part records holding SKU, description, unit cost, and pricing tiers) map to Dynamics Product2. The aACE Item number becomes Product Number, and pricing tiers migrate as Price List entries in the Dynamics default price list. If the customer uses aACE's multi-currency pricing, we split Price List Items by currency.
aACE
Sales Order
Microsoft Dynamics 365 Sales
Opportunity
1:1aACE Sales Orders map to Dynamics Opportunity. The aACE order number becomes Opportunity Name, order total maps to Amount, and the Sales Order date maps to Close Date. Order status from aACE (open, closed-won, closed-lost) determines the Dynamics StageName. aACE's linked Line Items migrate as Opportunity Product records.
aACE
Sales Order Line Item
Microsoft Dynamics 365 Sales
Opportunity Product
1:1aACE Order Line Items link to Items and carry quantity and unit price. We map each line to a Dynamics Opportunity Product record, resolving the PricebookEntry reference using the Item's SKU and the active price list. Extended price and discount amounts preserve where aACE tracks them at the line level.
aACE
Invoice
Microsoft Dynamics 365 Sales
Invoice (Sales Invoice in Dataverse)
1:1aACE A/R Invoices map to Dynamics Invoice records. Open invoices migrate with full balance remaining and payment history so the A/R team can pursue collections post-migration. Closed invoices migrate as historical records with invoice status set to Paid. We flag open invoices as operationally critical and migrate them in the first batch before any other object.
aACE
Purchase Order
Microsoft Dynamics 365 Sales
Purchase Order (requires Dynamics 365 Finance or Supply Chain Management)
lossyaACE Purchase Orders link to Vendors, Items, and optionally to the originating Sales Order. Microsoft Dynamics 365 Sales does not include Purchase Order management; it requires Dynamics 365 Finance or Supply Chain Management as a separate license. We do not migrate Purchase Orders as standard scope. We deliver a written inventory of open POs with vendor, line items, and receipt status for the customer's ERP implementation team to handle in a separate engagement.
aACE
Project
Microsoft Dynamics 365 Sales
Project (requires Dynamics 365 Project Operations)
lossyaACE Projects hold job headers with linked Tasks, Time entries, and billing records. Microsoft Dynamics 365 Sales does not include project management; Project Operations is a separate license. We do not migrate Projects as standard scope. We deliver a written inventory of active Projects with their linked Tasks, estimated hours, and billing status for the customer's Project Operations implementation team.
aACE
Task
Microsoft Dynamics 365 Sales
Task
1:1aACE Tasks link to Projects and optionally to Accounts and Orders. We map task status, assignee, due date, and any custom flag fields to the corresponding Dynamics Task fields. Assignee resolves via the Employee-to-User mapping by email. High-volume task exports from aACE use FileMaker's chunked cache table approach with each batch validated before proceeding.
aACE
Employee
Microsoft Dynamics 365 Sales
User
1:1aACE Employee records (active roster with role and department) map to Dynamics User records. We resolve each Employee by email against the destination Dynamics User table. Historical payroll records and inactive employees are not migrated as Users; they are written to a separate audit table in Dynamics as custom records if the customer requests retention.
| aACE | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Account | Account1:1 | Fully supported | |
| Company Location | Account Address ( Dynamics 365 Customer Address table)1:many | Fully supported | |
| Item | Product1:1 | Fully supported | |
| Sales Order | Opportunity1:1 | Fully supported | |
| Sales Order Line Item | Opportunity Product1:1 | Fully supported | |
| Invoice | Invoice (Sales Invoice in Dataverse)1:1 | Fully supported | |
| Purchase Order | Purchase Order (requires Dynamics 365 Finance or Supply Chain Management)lossy | Fully supported | |
| Project | Project (requires Dynamics 365 Project Operations)lossy | Fully supported | |
| Task | Task1:1 | Fully supported | |
| Employee | User1:1 | 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
Microsoft Dynamics 365 Sales gotchas
Professional tier 15-table custom table limit blocks migrations
October 2024 pricing increase applies at renewal for all customers
Custom fields must be created in the UI before API writes
Power Platform request limits apply to bulk migrations
Activity records orphaned to inactive owners fail silently
Pair-specific challenges
Migration approach
Discovery and FileMaker layout audit
We audit the aACE database via FileMaker export scripts across all active object types (Accounts, Locations, Items, Sales Orders, Invoices, Purchase Orders, Projects, Tasks, Employees). We request the customer's FileMaker layout definitions to enumerate custom fields on every object. We assess data volume per object type, identify relational links (Order to Line Items, Invoice to Order, Project to Tasks), and flag open invoices and active Purchase Orders as operationally critical records. The discovery output is a written migration scope, a custom field inventory, and a record-dependency graph.
FileMaker migration user provisioning and cache strategy
We provision a dedicated migration user account in aACE with sufficient privileges to run export scripts on all object types. We configure the export sequence to clear the cache table before each batch, run under the migration user to avoid collisions with active users, and chunk exports by object type with validation against the cache table before committing to the destination. This step typically requires coordination with the customer's FileMaker administrator and adds one to three days to the pre-migration timeline.
Microsoft Dynamics 365 Sales schema setup
We configure the destination Microsoft Dynamics 365 Sales environment: custom fields (matching discovered aACE custom fields), address composite fields, opportunity fields and stage values aligned to the customer's order status matrix, and product price lists matched to aACE pricing tiers. We create the migration user with Dataverse API access, Bulk API permissions, and the necessary security roles. We validate the schema in a Dynamics Sandbox before production migration begins.
Sandbox migration and reconciliation
We run a full migration into Dynamics Sandbox using production-like data volume. The customer's operations lead reconciles record counts (Accounts in, Locations in, Items in, Orders in, Invoices in, Tasks in), spot-checks 20-30 random records against the aACE source, and validates that relational links (Order to Line Items, Invoice to Account) resolved correctly. Mapping corrections happen in the Sandbox, not in production. This step typically takes one to two weeks.
Production migration in dependency order
We run production migration in record-dependency order: Accounts first (as the parent of all other records), Locations (as child records attached to Accounts), Items and Products, Sales Orders as Opportunities (with Line Items as Opportunity Products), Invoices (with open invoices first), Tasks, and Employees as Users. Each phase emits a row-count reconciliation report before the next phase begins. The FileMaker export runs under the dedicated migration user with cache table cleared before each batch. Dynamics Dataverse API handles the load with rate-limit handling and batch chunking.
Cutover, delta migration, and ERP handoff
We freeze aACE writes during cutover, run a final delta migration of any records modified during the migration window, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver the Purchase Order inventory and Project inventory documents to the customer's ERP implementation team. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's sales and operations teams. We do not rebuild aACE automations as Dynamics workflows; that work is documented separately for the customer's admin team.
Platform deep dives
aACE
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 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 Microsoft Dynamics 365 Sales .
Object compatibility
1 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 Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your aACE to Microsoft Dynamics 365 Sales 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 Microsoft Dynamics 365 Sales
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.