Migrate from Swivl Tech to Microsoft Dynamics 365 Sales

Swivl stores both individual customers and business entities in a single Customer object with an is_company flag. We split these: individuals map to Contact records; businesses map to Account records with the primary contact linked via AccountId. Company name and billing address land in Account; individual contact details land in Contact.

Swivl's Property object tracks service locations tied to customers. Dynamics 365 Sales has no native Property equivalent. We create a new_Property custom table in Dataverse with a lookup to Account, storing address, property type, and access notes. Property-to-customer associations migrate as relationship records.

Swivl's Work Order is the core record — it holds line items, technician assignments, status, timestamps, and cost. Dynamics 365 Sales uses Case for service incidents. We recommend creating a new_WorkOrder custom table on Dataverse mapped 1:1 from Swivl, preserving job status, scheduled date, assigned technician, and all line items. If your team uses Cases for service management, we can alternatively split work orders into Cases with custom product-line fields for line items.

Swivl line items (parts, labor, flat fees) map to Opportunity Product records if routing to Opportunity, or to a new_WOLineItem custom table if using the custom Work Order approach. Each line item gets its own record with product reference, quantity, unit price, and cost. Tax handling requires a custom field since Dynamics stores tax on invoice-level configurations.

Paid Swivl invoices migrate as Dynamics Invoice records when using the Business Central attachment model. Without Business Central, we create a new_Invoice custom table storing invoice number, date, amount, status, and linked customer reference. Open invoices at migration time require your team to decide whether to carry them as open records or treat them as historical.

Swivl technicians are users in the system. In Dynamics 365 Sales Core, technicians become User records. If you attach Field Service Premium, they become Bookable Resource records with skill profiles. We map technician email to OwnerId in Dynamics and preserve their Swivl role (dispatch role, certifications) as new_TechnicianRole custom fields on the User record.

Any Swivl custom properties on Customer, Property, Work Order, or Line Item objects require corresponding new_ fields in Dataverse. We inspect the Swivl API schema during discovery, create each field in the Dynamics solution with appropriate type (text, number, picklist, date), and then map values during the import. Picklist values in Swivl require manual value-mapping against Dynamics picklist options.

Swivl notes, logged calls, and email records linked to customers or work orders migrate as Dynamics ActivityPointer records with the regarding object pointing to the mapped Account or Contact. Original timestamps and created-by user resolve via email match to Dynamics users. Attachments stored as Swivl file references re-upload to Dynamics Notes or SharePoint.

Swivl leads convert to Dynamics Lead with direct field mapping. Lead status, source, and custom scoring fields map to new_ prefixed custom fields. Upon conversion in Dynamics, the Lead creates both Account/Contact and Opportunity records per your business process configuration.

Swivl user records map to Dynamics SystemUser by email address match. We flag any Swivl owner without a corresponding Dynamics user before migration and assign their records to a fallback owner. User active/inactive status, role, and team membership do not transfer — your Dynamics admin recreates these in the Security settings post-migration.