CRM migration

Migrate from aACE to Microsoft Dynamics 365 Sales

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 logo

aACE

Source

Microsoft Dynamics 365 Sales

Destination

Microsoft Dynamics 365 Sales  logo

Compatibility

70%

7 of 10

objects map 1:1 between aACE and Microsoft Dynamics 365 Sales .

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

aACE logo

aACE

What's pushing teams away

  • The native integration ecosystem is thin: there is no built-in connector for modern e-commerce platforms, marketing automation tools, or SaaS CRMs, so teams using Shopify, HubSpot, or Stripe resort to manual data entry or custom FileMaker scripting.
  • The FileMaker backend becomes a liability at scale. Reviewers cite performance degradation with large datasets, limited concurrent-user capacity, and the inability to expose the database directly to external tools or BI platforms.
  • The reporting module is a frequent complaint: aACE ships with a fixed set of reports and no native export to external business intelligence tools, forcing power users to rebuild reports in Excel or third-party add-ons.
  • When companies grow past the 50-100 user range or need true cloud-native ERP capabilities — including SaaS integrations, mobile-first UX, and automated workflow engines — they migrate to platforms like NetSuite, Acumatica, or SAP Business One that offer a broader integration ecosystem.

Choosing

Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales

What's pulling them in

  • Deep Microsoft 365, Teams, and Outlook integration makes Microsoft Dynamics 365 Sales a natural fit for Microsoft-first organizations already invested in that ecosystem
  • Sales Enterprise and Premium tiers offer unlimited custom tables and advanced AI-driven forecasting and predictive analytics not available in lower tiers
  • Professional tier pricing at $65 per user per month offers a lower entry cost than Salesforce for SMB teams with straightforward CRM needs
  • Flexible customization options allow businesses to build bespoke apps, tailor forms and views, and integrate with other Dynamics 365 modules
  • Microsoft Copilot AI tools are embedded directly into the sales workflow on Enterprise and Premium, automating routine tasks and providing deal intelligence

Object mapping

How aACE objects map to Microsoft Dynamics 365 Sales

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

maps to

Microsoft Dynamics 365 Sales

Account

1:1
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

Account Address ( Dynamics 365 Customer Address table)

1:many
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

Product

1:1
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

Opportunity

1:1
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

Opportunity Product

1:1
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

Invoice (Sales Invoice in Dataverse)

1:1
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

Purchase Order (requires Dynamics 365 Finance or Supply Chain Management)

lossy
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

Project (requires Dynamics 365 Project Operations)

lossy
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

Task

1:1
Fully supported

aACE 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

maps to

Microsoft Dynamics 365 Sales

User

1:1
Fully supported

aACE 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.

Gotchas + challenges

What specifically takes care here

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 logo

aACE gotchas

High

No public API — FileMaker export scripts only

Medium

FileMaker cache table is shared per-user

Medium

Custom fields require manual field-discovery

Low

Binary document containers are not migrated

Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales gotchas

High

Professional tier 15-table custom table limit blocks migrations

High

October 2024 pricing increase applies at renewal for all customers

Medium

Custom fields must be created in the UI before API writes

Medium

Power Platform request limits apply to bulk migrations

Medium

Activity records orphaned to inactive owners fail silently

Pair-specific challenges

  • No REST API — FileMaker export scripts only

    aACE exposes no documented REST or GraphQL API for bulk data access. All data extraction runs through FileMaker export scripts that write to a temporary cache table before producing a spreadsheet. We plan migration scripts around this constraint, chunking exports by object type and validating against the cache table before committing to the destination Dynamics environment. Customers expecting a direct API pull need their expectations reset during the scoping call. The absence of an API also means there is no way to run delta or incremental syncs after the initial load without re-running export scripts.

  • FileMaker cache table is shared per-user — migration user isolation required

    The export and import processes in aACE both write to the same temporary FileMaker cache table scoped to the running user account. When exporting large datasets, we run exports under a dedicated migration user account to avoid colliding with active users who may simultaneously be running imports. We clear the cache table before each batch to prevent stale records from contaminating the export. This constraint doubles the pre-migration setup time because a dedicated migration user must be provisioned in aACE before any export runs.

  • Custom fields require manual discovery from FileMaker layouts

    aACE tenants frequently add custom fields to standard objects — on Accounts, Orders, and Items — to support unique business processes. There is no metadata API to enumerate these fields automatically. We request the customer share their FileMaker layout definitions during scoping so we can build the complete field list. Custom fields that do not map to the Dynamics schema are written as JSON in a note field to prevent silent data loss. If the customer has more than 50 custom fields, the mapping phase extends by one to two weeks.

  • Purchase Orders and Projects are out of scope for Microsoft Dynamics 365 Sales

    aACE Purchase Orders and Projects sit at the ERP boundary that Microsoft Dynamics 365 Sales does not cover natively. Sales includes Opportunity and Order management but not Purchase Orders or project tracking. We deliver a written inventory of open Purchase Orders with vendor and receipt status, and active Projects with linked Tasks and estimated hours, so the customer's ERP implementation team can handle these in Dynamics 365 Finance or Project Operations as a separate engagement. Migrating these objects into the wrong Dynamics entities (for example, mapping Purchase Orders to Opportunities) creates data integrity issues downstream.

Migration approach

Six steps for a successful aACE to Microsoft Dynamics 365 Sales data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

aACE logo

aACE

Source

Strengths

  • All records — Accounts, Orders, Invoices, Tasks, Projects — live in a single FileMaker database with explicit relational links between them.
  • Combines accounting, CRM, order management, inventory, purchasing, and project management in one platform without requiring data exports between modules.
  • Per-user access privileges and custom privilege sets allow granular field-level and record-level security without dedicated IT staff.
  • Cloud-hosted options with a monthly hosting fee remove on-premises server maintenance for small and mid-size distributors.

Weaknesses

  • All reporting and data analysis must be built within FileMaker's native tools, which lack the flexibility of dedicated BI platforms like Power BI or Tableau.
  • No documented public REST API — migrations are handled via FileMaker export scripts and temporary cache tables rather than API-driven pipelines.
  • FileMaker's underlying architecture limits concurrent-user performance and makes the platform difficult to extend with external integrations or automated workflows.
  • Companies requiring deep supply chain automation, multi-entity consolidation, or real-time e-commerce synchronization outgrow the platform's native capabilities.
Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales

Destination

Strengths

  • Native integration with Microsoft 365, Teams, Outlook, and SharePoint for unified productivity workflow
  • Unlimited custom tables and complex workflows on Enterprise tier enable deep customization for complex sales processes
  • AI-driven predictive analytics and deal intelligence on Enterprise and Premium tiers help sales teams prioritize pipeline
  • Dataverse unified data layer provides a consistent API and data model across all Dynamics 365 and Power Platform apps
  • Strong security model with Field-Level Security and Record Ownership rules for governance-conscious enterprises

Weaknesses

  • Sales Professional tier caps custom tables at 15, creating a migration ceiling for highly customized SMB environments
  • October 2024 pricing increases of $15 per user across all tiers apply to existing customers upon renewal
  • Implementation typically requires costly certified partners, adding 30–50% to total project cost
  • Updates and platform releases can disrupt customizations and plugins, requiring regression testing after each wave
  • Non-Microsoft integrations require additional configuration or middleware, limiting flexibility for heterogeneous tech stacks

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across aACE and Microsoft Dynamics 365 Sales .

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    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

    B

    aACE doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your aACE to Microsoft Dynamics 365 Sales migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about aACE to Microsoft Dynamics 365 Sales data migrations

Answers to the questions buyers ask most during aACE to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between three and five weeks for under 10,000 Accounts and 5,000 Sales Orders with no custom objects or multi-location Account structures. Migrations with active Purchase Order history, Project records requiring a separate Finance or Project Operations engagement, more than 50 custom fields discovered from FileMaker layouts, or multi-currency pricing extend to eight to twelve weeks because of FileMaker export sequencing, address normalization, and the parallel ERP scoping work.

Adjacent paths

Related migrations to explore

Ready when you are

Move from aACE.
Land in Microsoft Dynamics 365 Sales , intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day