Migrate from PHP CRM to Microsoft Dynamics 365 Sales

Discovery and custom field enumeration

We audit the PHP CRM instance via admin panel and, where available, direct API access. We enumerate every active object (Contacts, Companies, Deals, Tasks, Notes, Activities), count records per object, identify all user-defined custom fields and their data types, and extract the pipeline and stage definitions. If API access is unavailable, we request CSV exports from the PHP CRM admin panel for each object. The discovery output is a written schema inventory and a migration feasibility assessment identifying any objects that cannot be extracted automatically.

Schema design and Microsoft Dynamics 365 Sales configuration

We design the destination Microsoft Dynamics 365 Sales schema based on the discovered PHP CRM field inventory. This includes creating custom fields in the target org (mapped by data type to Dynamics 365 field types), configuring Sales Processes and Record Types to match PHP CRM pipeline definitions, setting up the Lead and Contact split logic based on the customer's Company association patterns, and coordinating with the customer's Dynamics 365 admin to grant the migration user the necessary Dataverse roles. Schema is validated in a Dynamics 365 Sandbox before production migration begins.

Sandbox migration and reconciliation

We run a full migration into a Dynamics 365 Sandbox using production-like data volumes extracted from PHP CRM. The customer's CRM lead reviews record counts (Accounts, Contacts, Opportunities, Tasks, Notes), spot-checks 25-50 records against the PHP CRM source for field-level accuracy, and validates the pipeline stage mapping. Any field mapping corrections, missing picklist values, or schema gaps are resolved in the Sandbox before production migration begins. This step also confirms the attachment file inventory and flags any records with attachments that require post-migration re-attachment.

Owner reconciliation and User provisioning

We extract every distinct PHP CRM owner referenced on Deals, Tasks, and Activity records and match by email against the destination Dynamics 365 User table. Any PHP CRM owner without a matching Dynamics 365 User is added to a reconciliation queue. The customer's Dynamics 365 admin provisions missing Users (and deactivates any former employees) before record import resumes. This step is a prerequisite for all subsequent phases because OwnerId references are required on Opportunity and Task records.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from PHP CRM Companies), then Contacts and Leads (with AccountId resolved for Contacts), then Opportunities (with AccountId, OwnerId, and Sales Process resolved), then Tasks and Activities (with parent record IDs resolved via lookup), then Notes (with parent record references resolved). Each phase emits a row-count reconciliation report showing source count, destination count, and error count before the next phase begins. We use the Dynamics 365 Dataverse REST API with batch chunking and exponential backoff on throttle responses.

Cutover, validation, and workflow handoff

We freeze PHP CRM writes during cutover, run a final delta migration of records modified during the migration window, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver the written workflow and automation inventory to the customer's admin team for Power Automate rebuild. We provide a 72-hour hypercare window for reconciliation issues raised by the sales team. We do not rebuild PHP CRM workflows as Power Automate flows inside the standard migration scope; that is a separate engagement.