CRM migration

Migrate from Propertybase to Microsoft Dynamics 365 Sales

Field-level mapping, validation, and rollback between Propertybase and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .

Propertybase logo

Propertybase

Source

Microsoft Dynamics 365 Sales

Destination

Microsoft Dynamics 365 Sales  logo

Compatibility

100%

13 of 13

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

Complexity

BStandard

Timeline

48–96 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Propertybase is a real-estate-focused CRM built on Salesforce that stores Listings, Offers/Contracts, and Enquiries as custom Salesforce objects alongside standard Contacts and Companies. Microsoft Dynamics 365 Sales uses a standard CRM schema built on Dataverse: Accounts, Contacts, Leads, Opportunities, Quotes, and Orders, with custom tables available under the Sales Enterprise license. We map Propertybase Company records to D365 Accounts (direct mapping), Propertybase Contacts to D365 Contacts, and Propertybase Listings to custom Dataverse tables that require pre-creation in your D365 instance. Propertybase Offers/Contracts map to D365 Opportunities or Quote entities depending on your deal structure. Enquiries route to D365 Leads or Contacts based on the enquiry status field. FlitStack AI preserves all standard and custom field values, original timestamps, owner assignments resolved by email match, activity history (calls, emails, meetings, notes), and file attachments. Workflows, automation rules, and email templates do not migrate — these require manual rebuild using D365 Power Automate flows or model-driven app logic. We deliver a workflow audit export from Propertybase as a reference document for your D365 admin to use during the rebuild phase. The migration uses Propertybase's Salesforce API for data extraction and D365's Dataverse Web API for ingestion, with Bulk API for record sets exceeding 10,000 rows. A 24–48 hour delta pickup window captures in-flight changes during the cutover window.

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

Propertybase logo

Propertybase

What's pushing teams away

  • Customers report recurring billing issues where the company charges unexpectedly, with one reviewer stating the platform 'literally steals money' through billing disputes.
  • The onboarding experience is described as basic and unhelpful — teams report needing to build their own features to make the software usable, suggesting inadequate initial setup support.
  • A steep learning curve makes the platform difficult to adopt — reviews indicate 'you have to learn how to make it do it all' rather than it working out of the box.
  • Alternative platforms like BoomTown (4.7/5) and BoldTrail (4.5/5) score higher on G2, prompting teams to evaluate options with more modern UX and simpler configuration.
  • Enterprise pricing at $89/user/month is cost-prohibitive for larger teams compared to flat-rate alternatives in the real estate CRM market.

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 Propertybase objects map to Microsoft Dynamics 365 Sales

Each row shows how a Propertybase 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.

Propertybase

Company

maps to

Microsoft Dynamics 365 Sales

Account

1:1
Fully supported

Propertybase Company maps directly to D365 Account. Company name, address, phone, website, industry, and employee count transfer as Account field values. Parent-child company hierarchies in Propertybase map to the Account.ParentId lookup in D365; parent records must migrate before child records for referential integrity.

Propertybase

Contact

maps to

Microsoft Dynamics 365 Sales

Contact

1:1
Fully supported

Propertybase Contact maps 1:1 to D365 Contact. Name, email, phone, job title, and address fields transfer directly. All D365 Contacts require an AccountId (primary company lookup) — contacts without a primary company in Propertybase receive a placeholder 'Unassigned' Account record to satisfy the Dataverse required-field constraint.

Propertybase

Contact (Individual)

maps to

Microsoft Dynamics 365 Sales

Contact

1:1
Fully supported

Propertybase Individual Contact records (where SystemIsIndividual = TRUE) map directly to D365 Contact. The individual-flag distinction is preserved as a custom 'Is_Individual_Contact__c' field on the Contact record since D365 does not have a native individual-vs-company contact distinction at the object level.

Propertybase

Enquiry / Request

maps to

Microsoft Dynamics 365 Sales

Lead

1:1
Fully supported

Propertybase Enquiry records route to D365 Lead if the enquiry has not been qualified into a deal. Enquiry status, source, and interest-level fields map to Lead custom fields. Qualified enquiries that have converted to offers in Propertybase map to Opportunity records instead.

Propertybase

Listing (Project / Individual)

maps to

Microsoft Dynamics 365 Sales

Custom Property__c Dataverse Table

1:1
Fully supported

Propertybase Listing records require a custom 'Property__c' table in D365 Dataverse. This table must be pre-created before migration with fields matching Propertybase Listing schema: address components, list price, property type, status (Active, Pending, Sold), bedrooms, bathrooms, square footage, and media URLs. We deliver a Dataverse table creation specification as part of the migration plan.

Propertybase

Listing

maps to

Microsoft Dynamics 365 Sales

Property__c

1:1
Fully supported

Listing-level fields (ListingName, Address, ListPrice, PropertyType, Status, Beds, Baths, SqFt) map field-by-field to the custom Property__c Dataverse table columns. Media URLs (property images) store as text fields pointing to re-uploaded file locations in D365 SharePoint or Dataverse file storage. Property media files are downloaded from Propertybase prior to migration and re-uploaded to maintain the original file references, ensuring that all property images remain accessible in the destination system.

Propertybase

Offer / Contract

maps to

Microsoft Dynamics 365 Sales

Opportunity

1:1
Fully supported

Propertybase Offer/Contract records map to D365 Opportunity entities. The offer amount maps to Opportunity.Amount, offer status (Pending, Accepted, Declined) maps to Opportunity.StageName using a value-mapping table. The linked Listing lookup requires resolution to the Property__c table custom ID after Listings are migrated.

Propertybase

Offer / Contract

maps to

Microsoft Dynamics 365 Sales

Quote / Order

1:1
Fully supported

Accepted Propertybase Offers that represent binding contracts can optionally map to D365 Quote or Order entities if the destination uses Dynamics 365's quote-to-cash workflow. This requires a separate mapping decision based on your D365 configuration — we surface the choice in the pre-migration planning call.

Propertybase

Favourite / Listing Association

maps to

Microsoft Dynamics 365 Sales

Custom Junction Entity

1:1
Fully supported

Propertybase Favourite records (linking Contact to Listing for buyer interest tracking) map to a custom Dataverse junction table between Contact and Property__c. This relationship does not have a native D365 equivalent and requires a custom 'Property_Interest__c' junction entity with ContactId and PropertyId lookup fields.

Propertybase

Activity (Call, Email, Meeting, Note)

maps to

Microsoft Dynamics 365 Sales

Task / Appointment / Note

1:1
Fully supported

Propertybase activity records (calls logged, emails tracked, meetings scheduled, notes attached) map to D365 Task and Appointment entities using the same ActivityPointer model. Original timestamps, owners, and regarding-object links (Contact, Account, or Property__c) are preserved. Notes migrate as D365 Note (annotation) records with original create dates.

Propertybase

Attachment / File

maps to

Microsoft Dynamics 365 Sales

SharePoint / Dataverse Files

1:1
Fully supported

Propertybase file attachments on any record (listings, contacts, companies, offers) are downloaded and re-uploaded to D365's SharePoint document management or Dataverse file storage. File size limits (default 128MB per file in Dataverse) apply; files exceeding this threshold are flagged for manual handling.

Propertybase

Custom Objects

maps to

Microsoft Dynamics 365 Sales

Custom Dataverse Tables

1:1
Mapping required

Propertybase custom objects (any __c Salesforce objects beyond standard Company/Contact/Listing/Offer) map 1:1 to custom Dataverse tables in D365. Each custom object requires pre-creation of a corresponding Dataverse table with appropriate column types before migration. We deliver a schema specification for each custom object during the planning phase.

Propertybase

Owner / User

maps to

Microsoft Dynamics 365 Sales

SystemUser

1:1
Fully supported

Propertybase owner IDs (Salesforce User records) are resolved against D365 SystemUser records by email address match. Unmatched owners are flagged before migration — your team either provisions the D365 user account first or assigns records to a designated fallback owner. No record lands without a valid D365 owner.

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.

Propertybase logo

Propertybase gotchas

High

Formula and roll-up summary fields excluded from exports

Medium

Ghost company records for Individual Contacts

Medium

Workflow rules do not export — automations must be rebuilt

Medium

Media Loader assets require separate migration path

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

  • Propertybase Listings require custom Dataverse table creation before data lands

    Propertybase stores listings as a native Salesforce object with real-estate-specific fields (price, bedrooms, bathrooms, property type, status). Microsoft Dynamics 365 Sales has no built-in property or listing entity. Migrating Listings requires pre-creating a custom 'Property__c' Dataverse table in your D365 instance before the migration run. Sales Professional licenses limit you to 15 custom tables total — if your Propertybase setup has more than 15 custom objects including Listings, Offers, and any custom real-estate fields, you need Sales Enterprise ($105/user/month) to accommodate them all. We deliver a custom table schema specification during planning so your D365 admin can create the tables before data extraction begins.

  • All D365 Contacts require a primary Account lookup — ghost accounts resolve individual contacts

    Salesforce allows contacts to exist without a company association (Individual Contacts where SystemIsIndividual = TRUE, representing buyers rather than company representatives). Microsoft Dynamics 365 Contact records require a ParentCustomerId lookup pointing to an Account. Propertybase individual contacts without a primary company get attached to a placeholder 'Unassigned Account' record in D365. This is a known D365 schema constraint — we handle it automatically during migration by creating the placeholder account and linking individual contacts to it, but you should review the mapping plan to confirm the placeholder account naming convention works for your reporting.

  • Offer status value-mapping requires D365 StateCode and StatusCode coordination

    Propertybase Offer status is a single pick-list field (Pending, Accepted, Declined, Withdrawn). D365 Opportunity uses two coordinated option-sets: StateCode (Open/Won/Lost) and StatusCode (the granular reason within each state). Mapping Propertybase offer status to D365 StateCode and StatusCode requires a value-mapping table that your team validates before the migration runs. Accepted offers map to StateCode = Won, Declined/Withdrawn map to StateCode = Lost, and Pending maps to StateCode = Open with a StatusCode of Pending. Incorrect mapping causes all Opportunities to land in the wrong stage on day one.

  • Workflow rules and Process Builder automations do not migrate and must be rebuilt in Power Automate

    Propertybase workflows built in Salesforce Workflow Rules or Process Builder — such as listing-status-change triggers, offer-notification alerts, or agent-assignment rules — have no equivalent in D365 and cannot be migrated automatically. They must be rebuilt using D365 Power Automate flows or the classic workflow engine. We export your Propertybase workflow definitions as a documented reference so your D365 admin has a rebuild blueprint. Failing to rebuild critical automations before go-live is the most common source of post-migration process disruption in Propertybase-to-D365 projects.

  • D365 per-table API request limits apply during migration ingestion

    Microsoft Dataverse enforces API request limits per user per day (typically 40,000 requests per user per 24 hours for Enterprise licenses). Ingesting large Propertybase record sets into D365 custom tables during migration can approach these limits on high-volume migrations. We throttle API calls to stay within limits and use Dataverse Bulk API for record sets exceeding 10,000 rows, but very large migrations (500,000+ records) may require multi-day ingestion windows. Your D365 tenant's specific API limits depend on your license tier and any add-on Power Platform requests — we confirm these during the planning phase.

Migration approach

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

  1. Discover Propertybase data model and D365 schema requirements

    FlitStack AI extracts your Propertybase object schema via the Salesforce REST API — all standard and custom objects, field definitions, pick-list values, and relationship metadata. We simultaneously assess your D365 instance to confirm custom table creation capacity (Sales Professional's 15-table limit is the first gate). We deliver a pre-migration schema plan listing every Propertybase object, its D365 destination, any custom Dataverse tables that must be pre-created, and the field-by-field mapping specification. Your D365 admin creates the custom tables before Step 2 begins.

  2. Resolve owners and configure user mapping

    Propertybase owner IDs (Salesforce User records) are matched against D365 SystemUser records by email address. We generate a pre-migration owner resolution report listing every matched user, every unmatched owner, and the proposed fallback owner for each gap. Your team either provisions the missing D365 user accounts or confirms the fallback assignment. No record migrates without a confirmed D365 owner — this prevents orphaned records on day one.

  3. Sequence and execute the migration with dependency ordering

    D365 foreign-key constraints require a specific migration sequence: Accounts first, then Contacts (resolving ParentCustomerId to Account), then Property__c custom table, then Leads, then Opportunities (resolving CustomerId and Property_Id__c lookups), then Activities and Notes. We run the migration in this sequence using the Salesforce Bulk API for large record sets and the Dataverse Web API for ingestion, with throttling to respect D365 API limits. File attachments are downloaded from Propertybase and re-uploaded to D365 SharePoint document libraries with original folder structures preserved.

  4. Run a sample migration with field-level diff before full commit

    A representative sample (typically 100–500 records per object type) migrates first so your team can verify field-level accuracy. We generate a field-level diff comparing source Propertybase values against the D365 destination values for every mapped field, including pick-list value mappings, date formats, and lookup ID resolutions. You sign off on the sample before the full migration run commits. This step catches value-mapping errors (like the Offer StateCode issue) before they affect all records.

  5. Delta-pickup cutover with rollback capability

    The full migration runs against D365. A 24–48 hour delta-pickup window captures any Propertybase records created or modified during the cutover window. Your team continues working in Propertybase throughout — we use read-only API access. An audit log records every operation (create, update, link) with source record ID and timestamp. If reconciliation fails, one-click rollback reverts the D365 instance to its pre-migration state. After rollback verification, the delta window re-runs to capture the final in-flight changes before go-live.

Platform deep dives

Context on both ends of the pair

Propertybase logo

Propertybase

Source

Strengths

  • Salesforce-backed infrastructure provides enterprise-grade security, scalability, and a familiar interface for teams with Salesforce experience.
  • Comprehensive real estate feature set covering the full sales cycle from lead capture through transaction close without requiring multiple disconnected tools.
  • Native listing management with media handling allows teams to store and display property images, video links, and PDFs within a single system.
  • Per-unit pricing model scales with brokerage size, making entry affordable for small teams before requiring enterprise-level investment.

Weaknesses

  • Recurring billing disputes and perceived billing practices drive negative reviews that signal customer satisfaction risk during and after migration.
  • Basic onboarding experience forces teams to invest significant time configuring the platform before it delivers real value.
  • Formula and roll-up summary fields cannot be exported, requiring migration teams to reconstruct calculated values from underlying source data.
  • Enterprise pricing at $89/user/month makes the platform expensive for large teams compared to flat-rate real estate CRM alternatives.
  • Workflow rules and automation are not data-exportable and must be manually rebuilt on the destination platform, adding migration complexity.
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 Propertybase 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

    Propertybase: Salesforce API limits apply — not publicly documented per Propertybase tier.

  • Data volume sensitivity

    A

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

Estimator

Estimate your Propertybase 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 Propertybase to Microsoft Dynamics 365 Sales data migrations

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

Can't find your answer?

Walk through your Propertybase to Microsoft Dynamics 365 Sales migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Small migrations under 25,000 total records (contacts, companies, listings, offers) complete in 48–96 hours of clock time once D365 custom tables are pre-created. Medium migrations in the 25,000–100,000 record range typically run 3–7 days including the sample migration, sign-off, and delta-pickup window. Large migrations exceeding 100,000 records or those involving more than 10 custom Dataverse tables require 2–4 weeks. The longest planning step is pre-creating D365 custom tables for Propertybase Listings and custom objects — that schema work happens before any data moves.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Propertybase.
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