Migrate from Aidoo Mobile to Microsoft Dynamics 365 Sales

Aidoo Mobile customer records map to Dataverse Account. Account name, address, and industry fields map directly. Multi-site customers in Aidoo Mobile require a parent-account link in Dynamics 365 — we preserve the site hierarchy by linking each site as a child Account record.

Named contacts within an Aidoo Mobile customer map to Dataverse Contact records linked via the AccountId lookup. Primary site contact becomes the primary Contact on the Account; additional contacts are created as related Contact records with appropriate roles. Role metadata such as JobTitle, Department, and IsPrimary flag from Aidoo Mobile carries over into corresponding Dataverse fields. Relationship types between contacts and the parent customer are preserved in the Contact's ParentCustomerId field so that account managers see the correct hierarchy in Dynamics 365 after migration.

Aidoo Mobile site records are represented as either child Account records (when the site functions as a separate service location) or as a custom Site custom table with a lookup to the parent Account. We create the custom Dataverse table before migration and configure the relationship.

Aidoo Mobile work orders have no native Dataverse equivalent in Dynamics 365 Sales. We create a custom WorkOrder table with fields mirroring Aidoo Mobile's schema: WorkOrderNumber, Status, Priority, Type, ScheduledDate, CompletedDate, EstimatedCost, ActualCost, Description, and a lookup to the Account and Contact. Organizations with Dynamics 365 Field Service installed use the built-in msdyn_workorder table instead.

Work order line items in Aidoo Mobile map to a custom WorkOrderProduct table with a lookup to the parent WorkOrder, a text description of the service or part, quantity, unit cost, and total line cost. This preserves the billing breakdown from Aidoo Mobile inside Dynamics 365.

Aidoo Mobile asset records (equipment under service contracts) migrate to a custom Asset custom table linked to the Account or Site that owns the asset. If Dynamics 365 Field Service is active, we use msdyn_customerasset instead, preserving asset serial number, model, installed date, and status.

Aidoo Mobile technicians are resolved by email match against Dynamics 365 users. Matched records link to the User. Unmatched technicians are stored in a custom Technician custom table with name, phone, email, and Team lookup so scheduling data references the right person.

Aidoo Mobile status values (Open, In Progress, On Hold, Completed, Cancelled) map to a Dataverse option set on the custom WorkOrder table. We map each Aidoo Mobile status label to the corresponding integer value in the destination option set, preserving the current state of every work order.

Priority levels from Aidoo Mobile (Low, Medium, High, Critical) migrate as a custom option set field on the WorkOrder table. Each priority label is mapped to a corresponding integer value in Dataverse's option set schema, maintaining the relative urgency classification from the source system. When Dynamics 365 Field Service is installed, the built-in msdyn_priority option set on msdyn_workorder provides a pre-configured priority field that accepts the same four-tier priority model from Aidoo Mobile.

Aidoo Mobile technician appointments and scheduling windows map to custom datetime fields (ScheduledStart__c, ScheduledEnd__c, AssignedTechnician__c) on the WorkOrder table. Dynamics 365 Sales does not have a native scheduling engine — these fields give the scheduling team a reference start point for Power Automate-driven scheduling.

Files attached to work orders or assets in Aidoo Mobile are downloaded and re-hosted as Dataverse Note attachments (annotations) linked to the corresponding WorkOrder or Asset record. If the destination uses SharePoint integration, files upload to SharePoint document libraries with the record reference preserved.

Any custom entities defined in Aidoo Mobile (beyond the standard work order, asset, and site objects) are created as custom Dataverse tables in Dynamics 365. We inspect the custom entity schema during discovery, create the tables in the destination environment, and then populate them with the migrated records.