CRM migration

Migrate from Naviga to Microsoft Dynamics 365 Sales

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 logo

Naviga

Source

Microsoft Dynamics 365 Sales

Destination

Microsoft Dynamics 365 Sales  logo

Compatibility

50%

4 of 8

objects map 1:1 between Naviga and Microsoft Dynamics 365 Sales .

Complexity

BStandard

Timeline

2-4 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Naviga logo

Naviga

What's pushing teams away

  • Steep learning curve and feature density — reviewers consistently report Naviga is 'tricky to use' and 'full of features' with users struggling to get full benefit without formal training and ongoing investment.
  • Limited flexibility for packaging and discounting — sales teams report difficulty configuring discounted packages and bundles that their market requires, pushing some publishers to keep separate billing tools.
  • Closed print production workflow — Naviga Publisher's InDesign blueprints and Sophi.io print outputs live in a proprietary production system not accessible via the Open Content API, creating vendor lock-in for print-heavy operations.
  • Headline editing limitations — some content modules reportedly disallow post-publication headline edits, which is a real operational pain for newsrooms that correct copy regularly.
  • Opaque pricing — no public pricing tiers are surfaced on the website, Capterra, or G2, forcing buyers through a sales process even for sizing exercises and complicating internal budget reviews.

Choosing

Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales

What's pulling them in

  • Deep Microsoft 365, Teams, and Outlook integration makes Microsoft Dynamics 365 Sales a natural fit for Microsoft-first organizations already invested in that ecosystem
  • Sales Enterprise and Premium tiers offer unlimited custom tables and advanced AI-driven forecasting and predictive analytics not available in lower tiers
  • Professional tier pricing at $65 per user per month offers a lower entry cost than Salesforce for SMB teams with straightforward CRM needs
  • Flexible customization options allow businesses to build bespoke apps, tailor forms and views, and integrate with other Dynamics 365 modules
  • Microsoft Copilot AI tools are embedded directly into the sales workflow on Enterprise and Premium, automating routine tasks and providing deal intelligence

Object mapping

How Naviga objects map to Microsoft Dynamics 365 Sales

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

maps to

Microsoft Dynamics 365 Sales

Account

1:1
Fully supported

Naviga 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

maps to

Microsoft Dynamics 365 Sales

Contact or Lead (split by subscription status)

1:many
Fully supported

Naviga 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

maps to

Microsoft Dynamics 365 Sales

User (custom field link)

1:1
Fully supported

Naviga 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

maps to

Microsoft Dynamics 365 Sales

Custom Object + Junction

lossy
Fully supported

Naviga 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

maps to

Microsoft Dynamics 365 Sales

Lead or Contact (split by engagement profile)

1:many
Fully supported

Naviga 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

maps to

Microsoft Dynamics 365 Sales

Task or Custom Activity Object

1:1
Fully supported

Naviga 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

maps to

Microsoft Dynamics 365 Sales

Opportunity (campaign-linked)

1:1
Fully supported

Naviga 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)

maps to

Microsoft Dynamics 365 Sales

SharePoint/OneDrive + Custom Fields

lossy
Fully supported

Naviga 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.

Gotchas + challenges

What specifically takes care here

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 logo

Naviga gotchas

Medium

Open Content API has no publicly documented rate limits

High

Print edition assets are inaccessible via API

Medium

Solicitor-to-subscriber linkages require Offer Group export

Low

Custom metadata schemas vary by installation

Low

No public pricing tiers complicates scope estimation

Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales gotchas

High

Professional tier 15-table custom table limit blocks migrations

High

October 2024 pricing increase applies at renewal for all customers

Medium

Custom fields must be created in the UI before API writes

Medium

Power Platform request limits apply to bulk migrations

Medium

Activity records orphaned to inactive owners fail silently

Pair-specific challenges

  • Naviga Open Content API has undocumented rate limits

    Naviga's Open Content API is described as well-documented and REST-based, but specific rate limits, quota tiers, and throttling thresholds are not publicly published. We request rate limit details during the discovery call and configure our extraction workers with conservative polling intervals to avoid triggering undocumented throttling. For large content repositories or bulk subscriber exports, we batch requests and monitor response headers for 429 signals. This is a known constraint when migrating from Naviga to any destination platform; we handle it through polling discipline rather than exposing the risk to the customer.

  • Print Edition artifacts are inaccessible via API

    Naviga Publisher's Sophi.io-powered print manufacturing workflows generate InDesign blueprints, page layouts, and print PDFs that live in a proprietary production system, not the Open Content repository. These artifacts cannot be extracted via the standard API. We flag Print Edition records during scoping and exclude them from the CRM migration scope entirely, notifying the customer that these assets require a separate print-to-print migration workflow. If the customer needs print edition metadata as reference data (edition date, print run size, page count), we migrate that as a custom object rather than the binary assets themselves.

  • Solicitor-to-subscriber linkages require Offer Group reconstruction

    Naviga Subscribe maintains solicitor assignments through Offer Groups rather than a direct many-to-many relationship between Solicitor and Subscriber. To preserve which solicitor acquired which subscriber, we must export the full Offer Group hierarchy including solicitor IDs and their linked subscriber records. We reconstruct the relationship during import using the solicitor ID as a foreign key mapped to the CRM User record, with a junction object linking each Contact to its acquiring Offer Group. This adds a migration phase that a direct record-to-record mapping would not require.

  • Custom metadata schemas vary by Naviga installation

    Naviga Photos allows each deployment to configure unique custom metadata fields with custom labels, field types, and required flags. There is no standard field dictionary. We perform schema discovery on the source environment before mapping, and we flag any custom fields that cannot be represented in Dynamics 365's native field types (for example, complex conditional logic fields or multi-level hierarchy fields). The customer's admin decides whether to create equivalent custom fields in Dynamics 365 or simplify the metadata model during migration.

  • Dynamics 365 data migration requires entity sequencing and dependency resolution

    Microsoft Dynamics 365 Sales enforces referential integrity during import. Accounts must exist before Contacts can reference them; Contacts must exist before Activities can link to them; Users must be provisioned before any record can be assigned to them. We sequence the migration in dependency order and maintain a reconciliation queue for records that fail due to missing parent references. Skipping entity sequencing or running parallel phases without dependency checking results in orphaned records or silent import failures that surface only during user acceptance testing.

Migration approach

Six steps for a successful Naviga to Microsoft Dynamics 365 Sales data migration

  1. 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).

  2. 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.

  3. 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.

  4. 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 .

  5. 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.

  6. 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

Context on both ends of the pair

Naviga logo

Naviga

Source

Strengths

  • End-to-end publishing suite covering content creation through monetization
  • Print and digital workflow parity within a single vendor
  • AI-powered print layout automation via Sophi.io integration
  • Real-time audience behavior analytics and segmentation
  • Modular architecture allowing publishers to adopt specific solutions independently

Weaknesses

  • Limited third-party integrations noted in customer reviews
  • Steep learning curve with complex feature set requiring formal training
  • Profile and settings corruption risk reported by long-term users
  • Headlines cannot be edited after creation in some content modules
  • Sales teams underusing advanced CRM features without enforced adoption
Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales

Destination

Strengths

  • Native integration with Microsoft 365, Teams, Outlook, and SharePoint for unified productivity workflow
  • Unlimited custom tables and complex workflows on Enterprise tier enable deep customization for complex sales processes
  • AI-driven predictive analytics and deal intelligence on Enterprise and Premium tiers help sales teams prioritize pipeline
  • Dataverse unified data layer provides a consistent API and data model across all Dynamics 365 and Power Platform apps
  • Strong security model with Field-Level Security and Record Ownership rules for governance-conscious enterprises

Weaknesses

  • Sales Professional tier caps custom tables at 15, creating a migration ceiling for highly customized SMB environments
  • October 2024 pricing increases of $15 per user across all tiers apply to existing customers upon renewal
  • Implementation typically requires costly certified partners, adding 30–50% to total project cost
  • Updates and platform releases can disrupt customizations and plugins, requiring regression testing after each wave
  • Non-Microsoft integrations require additional configuration or middleware, limiting flexibility for heterogeneous tech stacks

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Naviga and Microsoft Dynamics 365 Sales .

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Naviga: Not publicly documented.

  • Data volume sensitivity

    A

    Naviga exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your Naviga to Microsoft Dynamics 365 Sales migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Naviga to Microsoft Dynamics 365 Sales data migrations

Answers to the questions buyers ask most during Naviga to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between two and four weeks for accounts under 10,000 Subscribers and Audience Members with no complex custom metadata or multi-publication structures. Migrations with per-installation Photo custom metadata, Offer Group hierarchies exceeding 500 groups, multi-Publication organizational structures, or large Article-to-Activity histories move to four to eight weeks because of schema discovery, Offer Group reconstruction, and API polling conservatism around Naviga's undocumented rate limits.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Naviga.
Land in Microsoft Dynamics 365 Sales , intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day