CRM migration
Field-level mapping, validation, and rollback between Divalto weavy and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Divalto weavy
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
9 of 10
objects map 1:1 between Divalto weavy and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Divalto weavy to Microsoft Microsoft Dynamics 365 Sales is a structural migration that begins with a no-API constraint: Divalto weavy does not publish a public REST reference, and integrations rely on Zapier with no bulk export endpoint documented. We resolve this by coordinating full data exports through the vendor portal or manual CSV extraction during discovery, then mapping every record type into the Dataverse-backed Dynamics 365 data model. Divalto Companies map to Accounts, Contacts attach to Accounts via a parent lookup, and Leads are created from Divalto's suspect and prospect lifecycle stages. Pipeline stages translate into Dynamics Sales Processes, and Development Studio custom objects become Dataverse custom tables with explicit field-type mapping. Route and itinerary data have no Dynamics 365 equivalent and are flagged as out-of-scope with a manual export option offered separately. Workflows built in the Development Studio do not migrate as automation code; we deliver a written inventory of every active workflow for the customer's admin to rebuild in Dynamics 365.
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
Divalto weavy platform overview
Scorecard, SWOT, gotchas, and pricing for Divalto weavy.
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 Divalto weavy 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.
Divalto weavy
Company
Microsoft Dynamics 365 Sales
Account
1:1Divalto weavy Company records map to Microsoft Microsoft Dynamics 365 Sales Account. We extract the company name, industry classification, billing and shipping addresses, and any reference fields during the vendor-coordinated export, then map to Account fields (Name, Industry, Address fields). The Account is the first object imported because all Contact records require an AccountId parent lookup. Address handling flags the scenario where Divalto allows multiple address types per company and Dynamics 365 stores a single primary address per type; we collapse to the primary and flag any secondary addresses for the customer admin to decide on placement.
Divalto weavy
Contact
Microsoft Dynamics 365 Sales
Contact
1:1Divalto weavy Contact records map to Dynamics 365 Contact, with the AccountId resolved at import time by matching the Divalto Company name or domain to the Account created in the first phase. Standard fields (FirstName, LastName, Email, Phone, JobTitle) map directly. Any custom fields from the Divalto Development Studio are flagged for explicit mapping to either existing Contact fields or new custom fields on the Contact table in Dataverse.
Divalto weavy
Lead
Microsoft Dynamics 365 Sales
Lead
1:1Divalto weavy's suspect-to-prospect lifecycle stages map to Salesforce-equivalent Dynamics 365 Lead records. The Divalto lead status and source attribution fields migrate to Lead Status and LeadSource on Dynamics Lead. We preserve the original Divalto lifecycle stage in a custom field weavy_original_lifestage__c for reporting continuity. The customer's admin decides whether to convert migrated Leads to Contacts immediately or let them remain as Leads for assignment routing.
Divalto weavy
Deal
Microsoft Dynamics 365 Sales
Opportunity
1:1Divalto weavy Deals map to Dynamics 365 Opportunity. The deal name, estimated value, expected close date, stage, and owner migrate to Opportunity Name, Amount, EstimatedCloseDate, StageName, and OwnerId respectively. Stage values are extracted from the Divalto pipeline configuration during discovery and mapped to a Dynamics Sales Process that the customer configures in their destination org before migration begins.
Divalto weavy
Pipeline Stage
Microsoft Dynamics 365 Sales
Sales Process + Stage
lossyDivalto weavy pipeline stages are configurable per organization with no standardized names. We extract the full stage list from the source during discovery and present it as a stage mapping table during scoping. Each Divalto stage maps to a Microsoft Dynamics 365 Sales Process stage value, with the probability percentage from Divalto carried into the StageProbability field. Custom stages that do not fit a standard sales process are mapped to a catch-all process or flagged for the customer to define.
Divalto weavy
Activity
Microsoft Dynamics 365 Sales
Task and Event
1:1Divalto weavy Activity records (calls, meetings, action items) linked to Contacts or Deals map to Dynamics 365 Task and Event records. Call activities with disposition and duration fields map to Task with TaskSubtype=Call. Meetings map to Event with StartDateTime, EndDateTime, and Location preserved. Each Activity's original timestamp is preserved in the ActivityDate field so the timeline ordering in Dynamics matches the Divalto history. Activity type classification from Divalto is stored in a custom field for any activity types that do not map cleanly to Task or Event subtypes.
Divalto weavy
User
Microsoft Dynamics 365 Sales
User
1:1Divalto weavy User profiles (Standard, Sales, Technician, Full) are extracted and mapped to Dynamics 365 User records. Matching is performed by email address. The Divalto profile assignment migrates to a custom field weavy_profile__c on the User record so the customer can reference original access levels during the transition. Users without a matching Dynamics 365 User go to a reconciliation queue for the customer's admin to provision before the Contact and Deal imports proceed.
Divalto weavy
Custom Object (Development Studio)
Microsoft Dynamics 365 Sales
Custom Table (Dataverse)
1:1Organizations with custom CRM objects built in the Divalto Development Studio have non-standard schemas with no documented export format. We handle this by running a pre-migration schema audit in the source environment, manually cataloguing every custom object name, field name, field type, and relationship. Each custom object is then pre-created as a Dataverse custom table with matching field types before data import begins. Lookup relationships from Divalto custom objects to standard objects (Company, Contact, Deal) are resolved at migration time using the primary keys from the previously imported standard records.
Divalto weavy
Attachment
Microsoft Dynamics 365 Sales
Annotation (Note) or SharePoint
1:1Divalto weavy document attachments linked to Companies, Contacts, and Deals are extracted as files and mapped to Dynamics 365 Annotation records (Notes with file attachments) attached to the corresponding Account, Contact, or Opportunity. If the customer's Dynamics 365 org has SharePoint integration enabled, we can alternatively route files to SharePoint document libraries and link them via SharePoint document locations on the Account or Opportunity. The choice between Annotation and SharePoint is made during scoping based on the destination org's configuration.
Divalto weavy
Route/Itinerary Data
Microsoft Dynamics 365 Sales
None
1:1Divalto weavy route planning and itinerary data are mobile-first features designed for field workforce management and have no standard equivalent in Microsoft Microsoft Dynamics 365 Sales . The Field Service hub has a Resource Scheduling Optimization add-on that handles route optimization, but that is a separate product and license tier. We do not include route or itinerary data in the standard migration package. We offer a manual export of this data as a standalone CSV deliverable for the customer to archive or load into a separate system.
| Divalto weavy | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Company | Account1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Lead | Lead1:1 | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Pipeline Stage | Sales Process + Stagelossy | Fully supported | |
| Activity | Task and Event1:1 | Fully supported | |
| User | User1:1 | Fully supported | |
| Custom Object (Development Studio) | Custom Table (Dataverse)1:1 | Fully supported | |
| Attachment | Annotation (Note) or SharePoint1:1 | Fully supported | |
| Route/Itinerary Data | None1:1 | Not 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.
Divalto weavy gotchas
No public API documentation for direct migration
Per-user pricing model inflates cost with headcount
Development Studio customizations are non-standard and require explicit mapping
Route and itinerary data has no destination equivalent
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
Vendor export coordination and discovery
We begin by coordinating the full data export from Divalto weavy. Because no public API exists, we contact the Divalto vendor team to request a complete data export in CSV or Excel format covering Companies, Contacts, Leads, Deals, Activities, Users, and any custom objects. While waiting for the export, we run a Development Studio schema audit to catalogue every custom object, field, and relationship in the source environment. We also extract the pipeline stage configuration and user profile list. The discovery output is a written data inventory and a source schema catalogue that drives the mapping design.
Schema design and Dataverse custom table provisioning
We design the destination Microsoft Microsoft Dynamics 365 Sales schema before any data moves. This includes provisioning any required custom tables in Dataverse to receive Development Studio custom objects, creating custom fields on the standard Account, Contact, Lead, and Opportunity tables, and configuring the Sales Process and Stage definitions that correspond to the Divalto pipeline stages. Schema is deployed into a Dynamics 365 Sandbox environment first for validation. We coordinate with the customer's Dynamics admin to ensure the migration user has the appropriate Dataverse table privileges and that validation rules are identified for potential temporary relaxation during data load.
Sandbox migration and reconciliation
We run a full migration into the Dynamics 365 Sandbox using production-like data volume. The customer's operations lead reviews the migrated record counts against the Divalto export, spot-checks 25-50 records across object types for field-level accuracy, and signs off the schema and mapping before production migration begins. Any field mapping corrections, stage mapping adjustments, or custom table schema corrections happen in the Sandbox phase. This step prevents corrections in production, which would require re-importing affected record batches.
Owner reconciliation and User provisioning
We extract every distinct Divalto weavy user referenced as an owner on any record and match them by email address against the Dynamics 365 destination org's User table. Users without a matching Dynamics User go to a reconciliation queue. The customer's Dynamics admin provisions any missing Users (active or inactive depending on whether the original Divalto user is still employed and using the system). Migration cannot proceed past the Account, Contact, and Deal import phases because OwnerId references on Opportunity require a valid Dynamics User ID. This step is a gating checkpoint.
Production migration in dependency order
We execute the production migration in strict record-dependency order: Account (from Company), Contact (with AccountId resolved from the Account phase), Lead, Opportunity (with AccountId, OwnerId, and the Sales Process and Stage resolved), Activities (Task and Event via Dataverse API with chunking for large datasets), Custom Tables (with lookup references resolved to the standard records created in earlier phases), and Attachments (as Annotation records or SharePoint documents). Each phase produces a row-count reconciliation report and a field-completeness report before the next phase begins. We use Dataverse batch API with exponential backoff on rate-limit responses.
Cutover, validation, and Dev Studio workflow handoff
We freeze writes in Divalto weavy during cutover, run a final delta migration of any records created or modified during the migration window, then mark Microsoft Dynamics 365 Sales as the system of record. We deliver the Development Studio workflow inventory to the customer's admin team as a written document listing each active automation, its trigger conditions, actions, and a recommended Power Automate or Dataverse workflow equivalent. We do not rebuild Development Studio automations as Power Automate flows inside the migration scope. We support a one-week post-cutover window for reconciliation issues raised by the customer's team.
Platform deep dives
Divalto weavy
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 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 Divalto weavy and Microsoft Dynamics 365 Sales .
Object compatibility
2 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
Divalto weavy: Not publicly documented.
Data volume sensitivity
Divalto weavy 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 Divalto weavy to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Divalto weavy 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 Divalto weavy
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.