Migrate from Apollo ERP to Microsoft Dynamics 365 Sales

Direct 1:1 map for Apollo contacts that have a primary organization. Dynamics 365 Contact requires an AccountId lookup — contacts without a linked organization in Apollo are attached to a placeholder Account record or routed to Lead based on lifecycle criteria.

Apollo contacts without a primary organization or with a domain flagged as prospective map to Dynamics 365 Lead. Lead conversion creates the Account and Contact records post-migration if the contact enters an active sales cycle. The routing logic evaluates the organization_id field and domain pattern matching to determine whether a contact qualifies as a Lead or should be attached to an existing Account.

Apollo organizations map directly to Dynamics 365 Accounts. Industry, employee count, revenue, and website fields translate to Account.IndustryCode, NumberOfEmployees, AnnualRevenue, and WebsiteUrl respectively. Parent-child hierarchies in Apollo use Account.ParentAccountId in Dynamics. Address data from Apollo organization records maps to Address1_* and Address2_* fields on the Account entity, preserving city, state, country, and postal code information.

Apollo deals map to Dynamics 365 Opportunities. Deal name becomes Opportunity.Name, amount maps to Amount, close date to CloseDate, and owner to OwnerId. Pipeline stage from Apollo requires mapping to Opportunity.StageName picklist values per business process flow. The deal description field, if populated in Apollo, migrates to the Opportunity.Description field to preserve internal notes and context.

Apollo deal stages (e.g., Qualified, Demo Scheduled, Proposal Sent, Closed Won, Closed Lost) map value-by-value to Dynamics 365 Opportunity StageName picklist. If Apollo uses custom stage names, a value mapping table is required during migration setup. The mapping defines which Apollo stage corresponds to each StageName value in Dynamics 365, including the probability percentage associated with each stage for forecasting purposes.

Apollo enrichment data (seniority_level, intent_score, twitter_followers, tech_stack, etc.) has no Dynamics 365 native equivalent. Each attribute requires a new_* custom column created in Dataverse before migration. FlitStack delivers a field creation manifest as part of the pre-migration schema plan. The manifest specifies the display name, data type, and field security level for each custom attribute.

Apollo sequence steps (email sent, replied, call made, meeting booked) translate to Dynamics 365 Activity entities. Each sequence outcome becomes an Activity with Type, Status, and regarding_objectid linking to the Contact or Lead. Sequence cadence metadata (step order, delay days) is stored as custom fields on the activity.

Apollo custom fields on Contact, Organization, and Deal objects map 1:1 to Dynamics 365 custom fields (new_* columns). Custom field data types (text, number, date, boolean) map to corresponding Dataverse attribute types. Custom fields on Deal with pick-list values require value mapping in Dynamics.

Apollo file attachments on contacts and organizations migrate to Dynamics 365 Annotations (notes with file attachments). Files are downloaded from Apollo storage and re-uploaded to Dynamics 365 SharePoint integration or Dataverse file storage.

Apollo user records are matched to Dynamics 365 SystemUser by email address. Unmatched owners are flagged before migration — records are assigned to a fallback owner or a dedicated migration service account until the user is provisioned in Dynamics 365. The pre-migration exception report lists all unmatched owners with their Apollo user details so you can create corresponding SystemUser records or adjust the matching criteria before the migration run.