Migrate from Apto to Microsoft Dynamics 365 Sales

Direct object-to-object map. Dynamics 365 Contact requires an AccountId lookup for most business logic. Apto contacts without a primary company land with a null AccountId or against a designated placeholder Account — your admin specifies the fallback rule before migration runs.

Apto contacts at early lifecycle stages (if the Apto instance uses a lifecycle model) route to Dynamics 365 Lead. Fully qualified customers route to Contact. FlitStack evaluates the Apto contact status field at migration time to determine the split boundary. The split boundary is configurable; you can adjust the status threshold in the migration plan to align with your specific lifecycle definition.

Direct map with name transformation. Dynamics 365 Account requires a primary contact or AccountId linkage for most related records. Apto company hierarchies (parent/child) map to the ParentAccountId field on the Account record — circular references are flagged before insertion. If your data includes orphaned companies with no parent, FlitStack can assign a placeholder parent account to maintain referential integrity.

Direct map. Dynamics 365 Opportunity stores the deal name in the Name field, amount in EstimatedValue, and stage in StatusCode. Apto deal probability percentages are preserved as a custom field on the Opportunity since Dynamics 365 calculates probability from stage mapping tables.

Apto pipelines become Dynamics 365 Business Process Flows. Each Apto pipeline stage maps to a process stage in the BPF, and the stage pick-list values become Option Set values in Dynamics 365 with the same display labels but new integer values — value-by-value mapping is required.

Apto activity types are disaggregated: calls and emails map to Dynamics 365 Task records with Type='PhoneCall' or 'Email'; meetings map to Appointment; notes map to Annotation (Note). All preserve original created-on timestamps and owner ID from Apto. Each migrated record retains the original Apto identifier in a custom Source_System_ID__c field, enabling downstream reconciliation and delta-sync with any post-migration updates.

Apto custom objects migrate 1:1 to Dynamics 365 custom tables on the Dataverse. The publisher prefix (configured in your Dynamics 365 solution) is prepended to the custom table name. Custom-object associations that are N:N in Apto require junction tables in Dynamics 365 — FlitStack generates the junction schema in the migration plan.

Every Apto custom field requires a corresponding custom column in Dynamics 365. The column logical name is prefixed by the publisher (e.g., new_) and must be created in a solution before data loads. FlitStack delivers the list of required custom columns as a setup checklist.

Apto owner IDs are resolved against Dynamics 365 users by email address match. Unmatched owners are flagged before migration — you either invite them to Dynamics 365 first or assign their records to a fallback user. No record is inserted without a valid OwnerId.

Apto file attachments are re-uploaded to Dynamics 365 SharePoint document locations tied to the parent record. If SharePoint is not configured, attachments are stored as Note annotations. File size limits of the Dataverse apply — files over 25 MB are chunked or flagged for manual handling.

Apto workflows and automations do not transfer to Dynamics 365 Sales. The workflow definitions are exported as JSON reference documents so your admin can rebuild equivalent logic using Power Automate, Business Rules, or Dynamics 365 workflows after go-live. These JSON files include trigger conditions, action steps, and any associated field references, providing a clear blueprint for rebuilding each workflow in the new environment.