CRM migration
Field-level mapping, validation, and rollback between Method CRM and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Method CRM
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
9 of 12
objects map 1:1 between Method CRM and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from Method CRM to Microsoft Microsoft Dynamics 365 Sales is a schema rethink, not a record copy. Method CRM stores Contacts and Companies as distinct but associated records; Microsoft Dynamics 365 Sales separates Leads (unqualified prospects) from Contacts attached to Accounts. We design the split rule during scoping, create the Account hierarchy before any Contact insert, and preserve the original Method Company association in a custom field for audit. Activity history (calls, emails, meetings, tasks) migrates through the Dynamics 365 Bulk API with parent-record lookup resolution against the converted Contact and Opportunity. Method's QuickBooks-linked transactional records (Estimates, Invoices, Sales Orders) have no native Microsoft Dynamics 365 Sales equivalent; we evaluate Dataverse custom tables or a Business Central scope addition. Workflows, automations, and the Customer Portal do not migrate; we deliver a written inventory of these for the customer's admin to rebuild post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Source platform
Method CRM platform overview
Scorecard, SWOT, gotchas, and pricing for Method CRM.
Destination platform
Microsoft Dynamics 365 Sales platform overview
Scorecard, SWOT, gotchas, and pricing for Microsoft Dynamics 365 Sales .
Data migration guide
The complete Microsoft Dynamics 365 Sales migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Microsoft Dynamics 365 Sales migration checklist
Pre- and post-cutover tasks for moving onto Microsoft Dynamics 365 Sales .
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Method CRM object lands in Microsoft Dynamics 365 Sales , including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Method CRM
Contact
Microsoft Dynamics 365 Sales
Lead or Contact (split required)
1:manyMethod CRM Contact records split by qualification status into Salesforce Lead or Contact. We use Method's contact status and assigned owner properties to apply a split rule designed during scoping. Contacts from active sales relationships map to Dynamics 365 Contact tied to an Account. Unqualified or cold contacts map to Lead. The original Method Contact record ID migrates into a custom field mth_contact_id__c on both Lead and Contact for audit traceability. If the customer used Method's QuickBooks customer link, the QB entity reference is preserved in a custom field qb_customer_ref__c for accounting reconciliation.
Method CRM
Company
Microsoft Dynamics 365 Sales
Account
1:1Method CRM Company records map 1:1 to Microsoft Dynamics 365 Sales Account. Company Name becomes Account Name, and the primary address maps to the billing address fields. Company is created before Contact insert so that the AccountId lookup is satisfied at the moment of Contact write. If a Method Company has no associated Contacts, it still migrates as an Account with no Contact child records.
Method CRM
Opportunity
Microsoft Dynamics 365 Sales
Opportunity
1:1Method CRM Opportunities map to Microsoft Dynamics 365 Sales Opportunity. The stage field from Method maps to a Microsoft Dynamics 365 Sales Process (Record Type) that we configure before migration. Close date, estimated amount, and probability migrate directly. OwnerId is resolved via email match against the Dynamics 365 User table during the Owner reconciliation phase. Closed-won and closed-lost reasons from Method become custom Opportunity fields for loss analysis.
Method CRM
Activity: Call
Microsoft Dynamics 365 Sales
Task (TaskSubtype = Call)
1:1Method CRM call activities map to Dynamics 365 Task with TaskSubtype set to Call. Call disposition, duration in seconds, and any recording URL stored in custom Task fields. ActivityDate preserves the original Method timestamp for timeline ordering. The WhoId (Contact or Lead reference) and WhatId (Opportunity reference) are resolved via the mth_contact_id__c and mth_opportunity_id__c lookup fields created during the parent record migration phase.
Method CRM
Activity: Email
Microsoft Dynamics 365 Sales
EmailMessage + Task
1:1Method CRM email activities migrate as Dynamics 365 EmailMessage records (the email content and headers) linked to an Activity Task record (the timeline entry). The email direction (inbound/outbound) maps from Method's activity type field. Attachments are extracted as ContentDocument records and linked via ContentDocumentLink. We set the Regarding (WhatId) to the parent Opportunity or Account using the lookup fields established on the Contact migration.
Method CRM
Activity: Meeting
Microsoft Dynamics 365 Sales
Event
1:1Method CRM meeting activities map to Dynamics 365 Event with StartDateTime and EndDateTime preserved from the Method timestamp. Location migrates to the Event Location field. Attendees are mapped to EventRelation records linked to the corresponding Contact, Lead, or User records.
Method CRM
Activity: Task
Microsoft Dynamics 365 Sales
Task
1:1Method CRM task activities migrate to Dynamics 365 Task with Status, Priority, Subject, and ActivityDate preserved. Owner assignment migrates by resolving the Method owner email to Dynamics 365 UserId via the User mapping table built during Owner reconciliation.
Method CRM
Activity: Note
Microsoft Dynamics 365 Sales
Note
1:1Method CRM Note activities migrate to Dynamics 365 Note records linked via ContentDocumentLink to the parent Contact, Lead, Account, or Opportunity. Rich text formatting in Method notes is preserved as HTML body content in the Note. File attachments within notes migrate as separate ContentDocument records.
Method CRM
Estimates
Microsoft Dynamics 365 Sales
Quote or Dataverse Custom Table
lossyMethod CRM Estimates are QuickBooks-synced transactional documents with line items, totals, and status. Microsoft Dynamics 365 Sales does not have a native Estimates object. We evaluate two paths: (1) if the customer licenses Microsoft Dynamics 365 Sales Professional, we map Estimates to Quote records with a flag indicating QB origin; (2) if transactional fidelity is required, we design a Dataverse custom table (Estimates) with line items, totals, and status fields matching the Method schema, then link it to the parent Account or Contact via lookup. QuickBooks linkage metadata is preserved in a custom field for accounting reconciliation. Customers needing full transactional history should evaluate a parallel Business Central scope.
Method CRM
Invoices
Microsoft Dynamics 365 Sales
Dataverse Custom Table or Invoice
lossyMethod CRM Invoices are QuickBooks-synced transactional records with payment status and line items. Microsoft Dynamics 365 Sales has no native Invoice object. If the customer does not have Business Central, we create a Dataverse Invoice table with invoice number, date, amount, balance due, and payment status fields matching the Method schema, linked to the Account via lookup. QB linkage metadata is preserved in a custom field. Invoices with payment data should be considered for a Business Central scope addition if accounting-level detail is required.
Method CRM
Custom Fields
Microsoft Dynamics 365 Sales
Custom Field
1:1Method CRM custom fields on Contacts, Companies, Opportunities, and Activities vary by account configuration. We inventory every custom field name and data type during scoping, then pre-create matching custom fields in Dynamics 365 using the appropriate Dataverse field type (text, integer, decimal, datetime, picklist, bit). Custom field values migrate as flat field writes during the parent object migration phase.
Method CRM
Files / Attachments
Microsoft Dynamics 365 Sales
ContentDocument + SharePoint
1:1Method CRM file attachments (binary content via REST API Files endpoints) migrate to Microsoft Dynamics 365 Sales as ContentDocument records stored in SharePoint Online. We create a SharePoint document library linked to the Dynamics 365 organization, then create ContentDocument records with the binary content and ContentDocumentLink records connecting each file to the parent Contact, Account, or Opportunity. File metadata (name, size, created date, created by) migrates from the Method API response.
| Method CRM | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Contact | Lead or Contact (split required)1:many | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Opportunity | Opportunity1:1 | Fully supported | |
| Activity: Call | Task (TaskSubtype = Call)1:1 | Fully supported | |
| Activity: Email | EmailMessage + Task1:1 | Fully supported | |
| Activity: Meeting | Event1:1 | Fully supported | |
| Activity: Task | Task1:1 | Fully supported | |
| Activity: Note | Note1:1 | Fully supported | |
| Estimates | Quote or Dataverse Custom Tablelossy | Fully supported | |
| Invoices | Dataverse Custom Table or Invoicelossy | Fully supported | |
| Custom Fields | Custom Field1:1 | Mapping required | |
| Files / Attachments | ContentDocument + SharePoint1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Method CRM gotchas
Grid export respects active filter context
QuickBooks dependency is structural, not optional
API rate limits are undocumented
Deep customization requires Method's own services
Enterprise-only features gate case and portal data
Microsoft Dynamics 365 Sales gotchas
Professional tier 15-table custom table limit blocks migrations
October 2024 pricing increase applies at renewal for all customers
Custom fields must be created in the UI before API writes
Power Platform request limits apply to bulk migrations
Activity records orphaned to inactive owners fail silently
Pair-specific challenges
Migration approach
Discovery and export audit
We audit the source Method CRM account across tier (Quick Start/Pro/Enterprise), data volume by object, active QuickBooks sync links, custom field inventory, and any active workflows or portal configurations. We instruct the customer to export from an unfiltered grid view on every object and cross-validate export counts against API queries to confirm no records are gated by filter context. The discovery output is a written migration scope covering record counts, split rules, Dataverse custom table requirements, and a Microsoft Dynamics 365 Sales tier recommendation (Professional at $65/user or Enterprise at $105/user depending on custom object and Flow requirements).
Schema design and split rule documentation
We design the Microsoft Dynamics 365 Sales destination schema: custom fields pre-created on Account, Contact, Lead, and Opportunity objects; Record Types and Sales Processes configured for each Method pipeline; and the Contact-to-Lead-or-Contact split rule documented as a decision matrix using Method's contact status and assigned owner fields. If transactional documents (Estimates, Invoices) are in scope, we design the corresponding Dataverse custom tables with line-item tables and QB linkage preservation fields. Schema is deployed to a Dynamics 365 Sandbox first for validation.
Sandbox migration and reconciliation
We run a full migration into a Microsoft Dynamics 365 Sales Sandbox using production data volume. The customer's admin reviews record counts (Accounts in, Contacts in, Leads in, Opportunities in, Activities in), spot-checks 20-30 random records against the Method CRM source, and validates the split rule output. Any mapping corrections happen in sandbox, not in production. The split rule is signed off before the production migration plan is finalized.
Owner reconciliation and User provisioning
We extract every distinct Method CRM owner referenced on Contact, Company, Opportunity, and Activity records and match by email against the Dynamics 365 destination org's User table. Owners without a matching User are held in a reconciliation queue. The customer's Dynamics 365 admin provisions any missing Users before record migration resumes. OwnerId references must be satisfied before Opportunities and Activities can be written.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Method Companies), Contacts and Leads (with split rule applied and AccountId resolved on Contacts), Opportunities (with AccountId, OwnerId, and RecordTypeId resolved), Activities (calls, emails, meetings, tasks via Bulk API with WhoId and WhatId lookup resolution), Files (extracted from Method API, written to SharePoint, linked via ContentDocumentLink), Custom Tables for Estimates and Invoices (if applicable). Each phase emits a row-count reconciliation report before the next phase begins. QuickBooks linkage metadata is preserved in custom fields in every phase for accounting reference.
Cutover, delta sync, and rebuild handoff
We freeze writes in Method CRM during the cutover window, run a final delta migration of any records modified during the migration window, then mark Microsoft Dynamics 365 Sales as the system of record. We deliver a written inventory of Method CRM workflows and portal configurations requiring rebuild, along with Dynamics 365 Flow equivalents and a Customer Portal evaluation recommendation (Power Pages or Dynamics 365 Customer Service portal). We support a five-business-day hypercare window for reconciliation issues. Workflow rebuild, portal reconfiguration, and Business Central evaluation are outside standard migration scope and are separate engagements.
Platform deep dives
Method CRM
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Method CRM and Microsoft Dynamics 365 Sales .
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Method CRM: Not publicly documented.
Data volume sensitivity
Method CRM doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Method CRM to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Method CRM to Microsoft Dynamics 365 Sales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Method CRM
Other ways to arrive at Microsoft Dynamics 365 Sales
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.