CRM migration
Field-level mapping, validation, and rollback between Naviga and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Naviga
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
4 of 8
objects map 1:1 between Naviga and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from Naviga to Microsoft Microsoft Dynamics 365 Sales is a publishing-to-standard-CRM migration with several structural adjustments. Naviga organizes around Publications, Subscribers, Solicitors, and Offer Groups with no direct Lead-Contact split; Dynamics 365 expects unqualified prospects as Leads and qualified contacts as Contacts attached to Accounts. We resolve that split during scoping using subscription type and audience profile, preserve solicitor IDs as custom fields on CRM User records, and map Offer Group hierarchies to reconstruct acquisition attribution. Print Edition artifacts from Naviga Publisher's Sophi.io print manufacturing workflows cannot migrate. We use the Microsoft Dynamics 365 Sales Data API and Bulk API with parent-record lookup resolution and rate-limit handling to move Contacts, Accounts, Opportunities, and Activity history. We do not migrate Naviga workflows, sequence automations, or forms; we deliver a written inventory for the customer's admin to rebuild.
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
Naviga platform overview
Scorecard, SWOT, gotchas, and pricing for Naviga.
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 Naviga 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.
Naviga
Publication
Microsoft Dynamics 365 Sales
Account
1:1Naviga Publications (news titles or media brands) map directly to Microsoft Dynamics 365 Sales Account records. The Publication name becomes Account Name; edition types and publication domain map to standard Account fields. Publication serves as the top-level organizational anchor for all content, subscriber, and advertiser data. We create Accounts before any related Contact import so that the AccountId Lookup relationship is satisfied at the moment of Contact insert.
Naviga
Subscriber
Microsoft Dynamics 365 Sales
Contact or Lead (split by subscription status)
1:manyNaviga Subscribers with active paid or free subscription status map to Dynamics 365 Contact records attached to the relevant Account. Subscribers with trial-only status or no confirmed acquisition source map to Lead records. We apply the split during the export transform based on the subscription status and billing history fields. The original Naviga subscription tier and billing status are preserved in custom fields on the destination Contact or Lead for reporting continuity.
Naviga
Solicitor
Microsoft Dynamics 365 Sales
User (custom field link)
1:1Naviga Solicitors (field sales representatives) map to Microsoft Dynamics 365 Sales User records. We match by email during migration. The solicitor ID is preserved in a custom field solicitor_id__c on the User record so that Offer Group attribution can be reconstructed. Any Solicitor without a matching Dynamics 365 User is placed in a reconciliation queue for the customer's admin to provision before Contact import resumes.
Naviga
Offer Group
Microsoft Dynamics 365 Sales
Custom Object + Junction
lossyNaviga Offer Groups bundle pricing structures and solicitor assignments for subscriber acquisition campaigns. We map Offer Groups to a custom Offer_Group__c object with fields for group name, pricing structure, and campaign period. The solicitor-to-subscriber linkage is reconstructed by exporting the full Offer Group hierarchy including solicitor IDs and linked subscriber records, then populating a junction object Offer_Group_Member__c that links each Contact to its acquiring Offer Group. This preserves the acquisition attribution that Naviga maintains through Offer Group membership rather than a direct foreign key.
Naviga
Audience Member
Microsoft Dynamics 365 Sales
Lead or Contact (split by engagement profile)
1:manyNaviga Audience Members represent the broader reader population including non-subscribers tracked for engagement. We split by engagement depth: highly engaged readers with behavioral data map to Lead; readers with established subscription or conversion intent map to Contact. The Naviga behavioral segmentation tags migrate to custom multi-select picklist fields or Topics in Dynamics 365 so the customer's marketing team can continue audience segmentation post-migration.
Naviga
Article
Microsoft Dynamics 365 Sales
Task or Custom Activity Object
1:1Naviga Articles with authored text, metadata, and linked photos map to Dynamics 365 Task records or a custom Article_Activity__c object, depending on whether the customer needs to preserve editorial output as a sales engagement artifact. Article body migrates as rich text; author name resolves to a CRM User; publish date maps to ActivityDate. Articles with no engagement or revenue attribution become read-only historical records in the destination.
Naviga
Advertisement
Microsoft Dynamics 365 Sales
Opportunity (campaign-linked)
1:1Naviga Ad manages print, digital, and broadcast ad campaigns with order management and production workflows. We map active ad campaign records to Dynamics 365 Opportunity objects with a custom record type for advertising revenue. Campaign start and end dates map to Opportunity Close Date and a custom field campaign_period_start__c. Line-item ad units map to OpportunityLineItems against a Product2 record representing the ad inventory. Completed campaigns become historical Opportunities with Closed Won or Closed Lost stage.
Naviga
Photo (with custom metadata)
Microsoft Dynamics 365 Sales
SharePoint/OneDrive + Custom Fields
lossyNaviga Photos with XMP, IPTC, and EXIF metadata map to SharePoint or OneDrive document libraries linked to the relevant Account, Contact, or Opportunity via Microsoft Graph. Standard photo metadata fields map to custom fields on the document record. Per-installation custom metadata fields on Photos are discovered during schema mapping, and each custom field is recreated as a typed custom field in Dynamics 365 before migration. Any custom field that cannot be represented by a Dynamics 365 field type is flagged for the customer's admin to resolve.
| Naviga | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Publication | Account1:1 | Fully supported | |
| Subscriber | Contact or Lead (split by subscription status)1:many | Fully supported | |
| Solicitor | User (custom field link)1:1 | Fully supported | |
| Offer Group | Custom Object + Junctionlossy | Fully supported | |
| Audience Member | Lead or Contact (split by engagement profile)1:many | Fully supported | |
| Article | Task or Custom Activity Object1:1 | Fully supported | |
| Advertisement | Opportunity (campaign-linked)1:1 | Fully supported | |
| Photo (with custom metadata) | SharePoint/OneDrive + Custom Fieldslossy | 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.
Naviga gotchas
Open Content API has no publicly documented rate limits
Print edition assets are inaccessible via API
Solicitor-to-subscriber linkages require Offer Group export
Custom metadata schemas vary by installation
No public pricing tiers complicates scope estimation
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 schema audit
We audit the Naviga source environment across the Open Content API and Subscribe API. This includes documenting the object inventory (Publications, Articles, Subscribers, Solicitors, Offer Groups, Advertisements, Audience Members, Photos), identifying any per-installation custom metadata schemas on Photos, and assessing the solicitor-to-subscriber linkage depth through Offer Group exports. We also map the Publication-to-Account target structure and define the Contact-Lead split rules based on subscription status and audience engagement profile. The discovery output is a written migration scope and a Microsoft Dynamics 365 Sales edition recommendation (Professional for straightforward migrations, Enterprise if custom objects or advanced pipeline features are required).
Schema design and custom field provisioning
We design the destination schema in a Microsoft Dynamics 365 Sales sandbox. This includes creating custom fields to hold Naviga solicitor IDs (solicitor_id__c on User), original subscription tiers (subscription_tier__c on Contact/Lead), Offer Group references, and any custom photo metadata fields discovered during schema audit. We configure the Lead-Contact split rule, create the Opportunity record type for advertising campaigns, and provision any custom objects required for Offer Group reconstruction. Schema is deployed via the Dynamics 365 admin center or Power Platform dataflows into the sandbox for validation before production migration begins.
Sandbox migration and reconciliation
We run a full migration into the Dynamics 365 sandbox using representative data volume. The customer's admin reconciles record counts (Publications in vs. Accounts in, Subscribers in vs. Contacts in vs. Leads in, Offer Groups reconstructed vs. junction records created) and spot-checks 25-50 random records against the Naviga source. We validate that solicitor attribution is correctly linked via the Offer_Group_Member__c junction object and that custom metadata fields are populated on migrated records. Any mapping corrections are documented and applied to the production migration scripts before cutover.
User provisioning and owner reconciliation
We extract every distinct Naviga Solicitor and map by email against the Dynamics 365 destination org's User table. Any Solicitor without a matching Dynamics 365 User is placed in a reconciliation queue. The customer's admin provisions missing Users (active or inactive depending on whether the solicitor is still active in the organization). Migration cannot proceed past Contact and Opportunity import because OwnerId references are required on standard objects in Microsoft Dynamics 365 Sales .
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Publications), then Leads and Contacts with the subscription-type split applied, then Users (solicitor mapping validated), then Opportunities (with AccountId, OwnerId, and RecordTypeId resolved), then Offer_Group__c and Offer_Group_Member__c (junction reconstruction), then Article activity records, then Photo metadata with SharePoint attachment. Each phase emits a row-count reconciliation report before the next phase begins. We use Dynamics 365 Bulk API with batch chunking and exponential backoff on rate-limit responses.
Cutover, validation, and automation handoff
We freeze Naviga writes during the cutover window, run a final delta migration for any records modified during the migration window, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver a written inventory of Naviga workflow artifacts, sequence automations, and forms requiring rebuild in Microsoft Dynamics 365 Sales Flow. We do not rebuild these as code inside the migration scope; that work belongs to the customer's admin or a Dynamics 365 partner. We support a one-week hypercare window to resolve reconciliation issues raised by the customer's sales and publishing teams.
Platform deep dives
Naviga
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 Naviga 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
Naviga: Not publicly documented.
Data volume sensitivity
Naviga exposes a bulk API — large-volume migrations stream efficiently.
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 Naviga to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Naviga 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 Naviga
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.