Migrate from Property Shell to Microsoft Dynamics 365 Sales

Property Shell contacts migrate as Dataverse Contacts. Standard fields (name, email, phone, address) map directly. Custom contact properties (enquiry source, preferred contact method, email subscription status) migrate as custom fields on the Contact table. Owner resolved by email match against Microsoft 365 users.

Property Shell's Company object maps to Dynamics 365 Account. Developer-type property companies preserve their developer_type as a custom pick-list field (DeveloperType__c) on the Account. Primary contact links are resolved after the Contact records are created, using the primary_contact_id lookup from Property Shell.

Property Shell Projects map to a custom Project__c Dataverse table in addition to a standard Opportunity record per project. The Opportunity captures deal-level financial fields (contract_value, budget_amount, deposit_amount); the Project__c table captures property development fields (development_address, settlement_date, project_stage) that have no native Opportunity equivalent.

Property Shell's Lot or Unit object has no direct Dynamics 365 equivalent — it requires a custom LotUnit__c Dataverse table. Fields like lot_number, area_sqm, lot_price, and sales_status migrate as custom columns. The sales_status pick-list maps to a custom pick-list defined in Dynamics 365, not to the native Opportunity Stage field.

Property Shell stores development stages (DA Approved, Site Works Complete, On Market, Under Contract, Settled) as a pick-list on each Unit record. These stages are not equivalent to Dynamics 365 Opportunity stages — they map to a custom pick-list field (DevelopmentStage__c) on the LotUnit__c table, with value-by-value mapping. Stage-entry timestamps migrate as custom datetime fields.

Property Shell contract records contain both structured fields (contract_number, title, parties, dates) and file attachments. The structured fields merge into a custom Contract__c Dataverse table linked to the LotUnit__c record. Contract documents are re-uploaded as Dataverse Files attached to the Contract__c record — original filenames and MIME types are preserved.

Contract PDF files and display-suite assets attached to Property Shell contract records are downloaded and re-uploaded to Dataverse Files linked to the Contract__c record. Files exceeding Dynamics 365's 128 MB per-file limit are flagged for chunked upload. The original file size and creation date are stored as metadata on the file record.

Property Shell owner records are resolved by email match against Microsoft 365 user accounts in Dynamics 365. Unmatched owners are flagged before migration — the team either creates a Microsoft 365 account first or assigns records to a designated fallback owner. Property Shell user metadata (role, last_login) is preserved as custom fields on the Contact record for reference.

Property Shell enquiries that have not been converted to contacts map to Dynamics 365 Lead records. The enquiry_source property migrates as a custom field (EnquirySource__c) to preserve the origin channel for each lead. Lifecycle stage equivalents are stored as a custom pick-list (LeadType__c) on the Lead record, allowing segmentation by enquiry status without relying on the native lead quality scoring fields.

Property Shell's built-in marketing automation, enquiry funnels, and nurture journeys do not have a migration path to Dynamics 365. They must be rebuilt in Power Automate or Dynamics 365 Customer Insights Journeys. FlitStack exports the workflow definitions and trigger/action logs as a JSON reference document for the rebuild project.

Property Shell's reporting and metrics dashboards do not carry over. The underlying data migrates, but the report definitions, chart configurations, and scheduled delivery settings require rebuilding using Dynamics 365's native report designer or Power BI. FlitStack provides a data dictionary of the migrated schema to accelerate the rebuild.

Property Shell integrations with third-party tools (Zapier, PropertyGuru, Campaign Monitor, Mailchimp) must be disconnected before migration and re-established in Dynamics 365 using Power Automate connectors or native integration settings. Integration endpoints, authentication credentials, and trigger configurations are documented during discovery so your team can rebuild each connection in the Power Platform admin center after go-live.