Migrate from Amwork to Microsoft Dynamics 365 Sales

Amwork Contacts with lifecycle stage of lead, prospect, or unqualified map to Microsoft Dynamics 365 Sales Lead. Lifecycle stage of customer, active client, or evangelist map to D365 Contact tied to an Account. We compute the split at migration time using Amwork's lifecycle_stage property, and preserve the original value in a custom field amwork_original_lifecycle__c on both Lead and Contact for audit. If Amwork lifecycle stages do not cleanly distinguish qualification, we use the has_linked_company flag as a secondary signal: contacts with a linked company map to Contact, those without map to Lead.

Amwork Company records map directly to D365 Account. The Amwork company domain or website field becomes the Account's Website attribute and serves as a dedupe key during import. We create the Account record before any Contact import so that the CustomerId lookup is satisfied at the moment of Contact insert. Amwork's industry and address fields map to standard D365 Account attributes.

Amwork Deals map to Microsoft Dynamics 365 Sales Opportunity. The Amwork deal stage property maps to D365 StageName via a pre-configured Sales Process that we create before migration. Deal value maps to Amount, and the associated pipeline maps to a D365 Record Type. Closed-won and closed-lost reasons from Amwork custom fields become D365 custom fields for loss and win analysis.

Each Amwork pipeline stage becomes a D365 stage value within a Sales Process. We create a Sales Process matching your Amwork pipeline structure, set stage probability percentages, and configure the stage order before deal migration. Any Amwork stages that do not exist in D365 are created during the schema configuration phase.

Amwork's separate Leads section maps directly to D365 Lead if the contact has not yet been qualified or linked to a company. The Amwork lead_status property maps to D365 Lead Status. Any scoring value in Amwork migrates to a custom field amwork_lead_score__c on the D365 Lead.

Amwork custom fields (text, number, date, choice types activated at the project level) migrate to D365 custom attributes on the corresponding entity. We pre-create the attribute definitions in the target D365 environment during the schema configuration phase, matching Amwork's data types to D365 attribute types. Attributes that cannot map directly (for example, Amwork multi-select choice fields) are flagged for customer decision during scoping.

Amwork Projects are workspace containers that do not have a direct D365 equivalent in the Sales module. We migrate project name and description as a D365 Note attached to the primary Account or Opportunity. If the customer licenses D365 Project Service Automation, we map Projects to Projects in that module as a separate engagement scope.

Amwork Tasks map to D365 Task. Assignee maps via email-to-User resolution. Due date, priority, and status migrate directly. Checklist sub-items on Amwork tasks become D365 subtasks or are appended to the Task description as structured text. Parent-child task hierarchy is preserved where D365 task relationships support it.

Amwork time entries attach to tasks and projects, not directly to contacts or companies. We preserve time entries as D365 Notes on the parent Task or (if project mapping is in scope) on the related Account. The Note body includes the original duration, date, description, and billable flag in a formatted structure. We flag this model difference so the customer's team understands that time entries do not appear as a separate CRM object post-migration.

Amwork Users map to D365 Users by email address match. We extract every distinct owner referenced on Contact, Company, Deal, and Task record and reconcile against the destination D365 User table. Users without a matching D365 account go to a reconciliation queue for the customer's admin to provision before record import resumes. Active and inactive status carries over from Amwork.