CRM migration
Field-level mapping, validation, and rollback between Referrizer and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Referrizer
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
7 of 10
objects map 1:1 between Referrizer and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
3-5 weeks
Overview
Referrizer is a referral-first CRM built for small multi-location businesses that bundles SMS, email, loyalty, and reputation tools in one subscription. Microsoft Microsoft Dynamics 365 Sales is an enterprise-grade CRM backed by the Dataverse platform that integrates with Office 365, Power Platform, and Azure. The two platforms have fundamentally different data models: Referrizer stores loyalty points as contact properties and has no bulk export API, while Microsoft Dynamics 365 Sales exposes Accounts, Contacts, Leads, and Opportunities with full Bulk API support. We extract Referrizer data through paginated API pages stitched into a transformation layer, separate loyalty fields from standard contact fields, scope exports by location ID to prevent cross-contamination, and load into Dataverse using the Bulk API. We do not migrate Smart Inbox conversations, automations, referral link configurations, or review request logs as these are not accessible via documented API endpoints. We deliver a written inventory of any active Referrizer automations and loyalty program rules for the customer's admin to rebuild in Dynamics 365 or a complementary tool.
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
Referrizer platform overview
Scorecard, SWOT, gotchas, and pricing for Referrizer.
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 Referrizer 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.
Referrizer
Contact
Microsoft Dynamics 365 Sales
Contact
1:1Referrizer Contacts map directly to Dynamics 365 Contact records. We preserve firstname, lastname, email, phone, address, custom fields, labels, and visit history during extraction. For contacts that represent businesses rather than individuals, we may create a parent Account first and link the Contact to it. Multi-select label assignments from Referrizer migrate to a custom multi-select picklist field on Contact or to TopicAssignment records depending on the customer's segmentation preference. Location association is preserved as a custom field if the destination org does not use the Sites entity.
Referrizer
Custom Fields
Microsoft Dynamics 365 Sales
Custom Fields on Contact
lossyReferrizer custom fields are key-value properties on the Contact record. We enumerate all custom field names and data types via the GET /contacts endpoint during scoping, then provision matching custom fields on the Dynamics 365 Contact entity before migration. Number fields, date fields, and text fields map directly. Multi-select or checkbox custom fields map to Dynamics multi-select picklist or boolean fields. Any custom field that has no equivalent Dynamics type is documented and placed in a custom field namespace on Contact.
Referrizer
Pipeline / Lead
Microsoft Dynamics 365 Sales
Lead
1:1Referrizer Pipeline stages map to Dynamics 365 Lead Status values or to Opportunity stages depending on the customer's sales process. If Referrizer contacts include a lead qualification status, we map that to the Dynamics Lead entity with a custom field capturing the original Referrizer pipeline stage name. Lead records are created before Contact records to allow WhoId resolution during activity migration.
Referrizer
Pipeline / Deal
Microsoft Dynamics 365 Sales
Opportunity
1:1Referrizer Deals map to Dynamics 365 Opportunity records. The deal amount, close date, stage name, and owner map to estimatedvalue, estimatedclosedate, stageName, and ownerid respectively. If Referrizer uses multiple pipelines, we create corresponding Opportunity Record Types and Sales Processes in Dynamics 365 before migration. The Deal-to-Opportunity association with the parent Contact and any linked Company is resolved via WhoId and WhatId lookups during the load phase.
Referrizer
Campaign
Microsoft Dynamics 365 Sales
Campaign
1:1Referrizer Regular and Automated campaigns map to Dynamics 365 Campaign records. Campaign type, status, scheduled dates, and target audience (contact list) migrate. We do not migrate campaign HTML content or templates; these are documented separately for the customer's marketing team to rebuild in Dynamics 365 Marketing or a comparable email platform. Campaign member responses (sent, delivered, opened) migrate as CampaignMember records with Status values mapped from Referrizer engagement metrics.
Referrizer
Offer / Referral
Microsoft Dynamics 365 Sales
Custom Entity or Note on Contact
lossyReferrizer Offers and referral relationship data do not have a native Dynamics 365 equivalent. We export offer codes, reward structures, and referral link associations as related records. Depending on the customer's data model, we create a custom ReferralOffer entity in Dataverse with a lookup to Contact, or we store the referral relationship as structured notes on the Contact record with a custom field for the referral type. The customer chooses the approach during scoping.
Referrizer
Loyalty Points
Microsoft Dynamics 365 Sales
Custom Number Field on Contact
lossyReferrizer loyalty points are stored as numeric custom fields on contact records rather than as a distinct object. We separate these fields from standard contact properties during transformation and remap them to a custom number field on the Dynamics 365 Contact entity named loyalty_points_balance__c. The customer may alternatively choose to integrate Dynamics 365 Customer Insights - Journeys for a native loyalty program; we document the migration approach and flag that any loyalty tier or points redemption rules require rebuild in the destination system.
Referrizer
Review Requests
Microsoft Dynamics 365 Sales
Custom Entity or Note
1:1Referrizer review request history (which contacts received requests, when, and to which platform) is stored as activity data on the contact record. We export this as a list of activity entries and load into a custom ReviewRequest entity in Dataverse linked to the Contact, or as structured notes with a custom field for the review platform (Google, Yelp, Facebook). We do not migrate actual reviews or ratings as these reside on third-party platforms and are not stored in Referrizer.
Referrizer
Activity / Engagement Feed
Microsoft Dynamics 365 Sales
Task, EmailMessage, or Note
1:1Referrizer contact activity feed events including campaign opens, link clicks, and UTM tracking data migrate as Note records on the Contact in Dynamics 365. Each activity entry is stored as a Note with a custom field capturing the activity type, timestamp, and source (campaign name). We do not migrate Smart Inbox conversational threads as no public API endpoint exposes this data. The Note-based approach preserves a historical record for audit purposes without requiring the activity timeline to be reconstructed from incomplete source data.
Referrizer
User / Team Member
Microsoft Dynamics 365 Sales
User
1:1Referrizer team member records (name, email, role) migrate as a lookup table against the Dynamics 365 destination org's User records. We match by email address. Any Referrizer owner without a matching Dynamics User is placed in a reconciliation queue for the customer's admin to provision before record import resumes, as OwnerId references are required on most standard object loads.
| Referrizer | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Custom Fields | Custom Fields on Contactlossy | Mapping required | |
| Pipeline / Lead | Lead1:1 | Fully supported | |
| Pipeline / Deal | Opportunity1:1 | Fully supported | |
| Campaign | Campaign1:1 | Fully supported | |
| Offer / Referral | Custom Entity or Note on Contactlossy | Fully supported | |
| Loyalty Points | Custom Number Field on Contactlossy | Fully supported | |
| Review Requests | Custom Entity or Note1:1 | Mapping required | |
| Activity / Engagement Feed | Task, EmailMessage, or Note1:1 | Fully supported | |
| User / Team Member | User1: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.
Referrizer gotchas
No bulk export API — migration relies on Zapier or CSV
Smart Inbox conversations are not accessible via API
Loyalty points stored as contact properties, not a distinct object
Rate limits not publicly documented
Multi-location scoping required to avoid cross-contamination
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 extraction planning
We audit the Referrizer account across all locations, custom field schemas, pipeline stages, campaign records, loyalty program data, and owner assignments. We enumerate custom fields via the paginated GET /contacts endpoint and capture all unique field names and data types. We confirm with the customer which locations are in scope, whether inactive contacts should be excluded, and whether loyalty point balances are required in the destination system. We also confirm whether Smart Inbox data needs a manual export. The discovery output is a written extraction plan and a source-to-destination field mapping document.
Schema provisioning in Dynamics 365
We provision the destination schema in the customer's Dynamics 365 org before migration begins. This includes creating any custom fields on the Contact entity (loyalty_points_balance__c, location_id__c, original_referrizer_id__c), configuring Opportunity Record Types and Sales Processes that correspond to Referrizer pipeline stages, and creating a custom ReferralOffer or ReviewRequest entity if the customer chose that approach during scoping. Schema is deployed into a Sandbox org first for validation, then into production. We coordinate with the customer's Dynamics admin on field-level security and validation rule suspension during the load phase.
Data extraction and transformation
We extract Referrizer data through paginated API requests, stitching pages into complete record sets for Contacts, Campaigns, Deals, and Activity entries. We separate loyalty numeric fields from standard contact fields during transformation, apply the multi-location scoping filter by querying with location_id parameters, and build the Lead-Contact-Account relationship graph before writing to Dataverse. Any records with missing required fields are flagged in a transformation exception report for the customer to resolve before load.
Sandbox migration and reconciliation
We run a full migration into a Dynamics 365 Sandbox (Full Copy or Partial Copy) using production-like data volume. The customer's admin or operations lead reconciles record counts (Contacts in, Leads in, Accounts in, Opportunities in), spot-checks 25-50 random records against the Referrizer source, and validates that custom field values (including loyalty points) are correctly populated. Any mapping corrections, missing fields, or data quality issues surface here and are resolved before the production migration begins.
Owner reconciliation and user provisioning
We extract every distinct Referrizer owner referenced on Contact, Campaign, and Deal records and match by email against the Dynamics 365 destination org's User table. Owners without a matching User go to a reconciliation queue. The customer's Dynamics 365 admin provisions any missing Users and confirms their roles and security roles before we proceed to production. Migration cannot proceed past this step because OwnerId references are required on Opportunity and Campaign records.
Production migration in dependency order
We run production migration in record-dependency order: Users (validated), Accounts (from Referrizer location or company data), Contacts (with AccountId resolved), Leads, Opportunities (with AccountId, OwnerId, and RecordTypeId resolved), Campaigns (with CampaignMember responses), Custom entities (ReferralOffer, ReviewRequest), and finally Activity notes. Each phase emits a row-count reconciliation report before the next phase begins. We use Dataverse Bulk API for high-volume Contact and Opportunity loads with batch chunking and exponential backoff on throttling responses.
Cutover, validation, and automation handoff
We freeze Referrizer writes during cutover, run a final delta migration of any records modified during the migration window, then enable Dynamics 365 as the system of record. We validate record counts against the pre-migration baseline and confirm custom field populaton across a statistical sample. We deliver a written inventory of Referrizer automations, campaign rules, and loyalty program structures that require rebuild in Dynamics 365 or a complementary tool. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's team. We do not rebuild Referrizer automations as Salesforce Flow or Power Automate flows inside the migration scope; that is a separate engagement.
Platform deep dives
Referrizer
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 Referrizer 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
Referrizer: Not publicly documented; API returns 429 TOO_MANY_REQUESTS on overages.
Data volume sensitivity
Referrizer 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 Referrizer to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Referrizer 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 Referrizer
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.