Migrate from KulaHub to Microsoft Dynamics 365 Sales

Discovery and API access authorization

We scope the source KulaHub portal: contact volume, activity count, email campaign history, document attachment size, user count, and any known custom fields or form submissions. Because KulaHub requires assisted API access, we submit the access authorization request on the customer's behalf and coordinate a discovery call with KulaHub support. We probe the API with a small batch of requests to measure response headers, page-size limits, and pagination behavior, then document the throughput findings. We pair this with a destination Dynamics 365 edition review: Sales Professional ($65/user) covers most KulaHub replacements; Sales Enterprise ($105/user) adds advanced AI, custom controls, and territory management if required.

Schema design and Account grouping strategy

We design the destination Dynamics 365 schema based on the inferred Account-Contact hierarchy. We define the Account grouping rule (by domain, by exact company_name match, or by manual mapping table provided by the customer), create the custom field kulahub_id__c on Account and Contact, configure any required custom entities for form submission data, and set up the Dynamics 365 email integration settings to match the GDPR preference transfer. Schema is deployed into a Dynamics 365 Sandbox via the environment lifecycle tools before any data moves.

Sandbox migration and reconciliation

We run a full migration into the Dynamics 365 Sandbox using a sample of 500-1,000 production-equivalent records. The customer reconciles record counts (Accounts created, Contacts linked, Activities loaded, Documents attached), spot-checks 25-50 records against the KulaHub source, and reviews the Account grouping output for accuracy. We correct any grouping logic errors, adjust custom field mappings, and finalize the transformation scripts before production migration begins. Any unmapped form submission fields are held in a staging table and reviewed with the customer.

User provisioning and owner reconciliation

We extract every distinct KulaHub user referenced on Contact, Activity, and Task records and match by email against the Dynamics 365 destination User table. If the customer is provisioning a new Dynamics 365 tenant, the admin creates the corresponding users before the production migration phase. Users without a match go to a reconciliation queue. Owner reconciliation must complete before any records that reference owners are loaded because OwnerId is a required field on most standard objects.

Production migration in dependency order

We run production migration in record-dependency order: Users (manually provisioned and validated first), Accounts (from inferred KulaHub company data), Contacts (with Parent Account lookup resolved), Activities (chronologically ordered via Dataverse Bulk API with WhoId and WhatId resolved), Documents (as Note or SharePoint linked records), Tasks, Email Templates, Campaigns, CampaignMembers (for unsubscribe and engagement history), and Form Submission data (as custom entity records). Each phase emits a row-count reconciliation report before the next phase begins.

Cutover, validation, and automation handoff

We freeze KulaHub writes during the cutover window, run a final delta migration of any records modified during the migration run, then enable Dynamics 365 as the system of record. We deliver the Workflow and Automation Inventory document to the customer's admin team: KulaHub workflows do not migrate to Dynamics 365 Flow because the trigger models differ structurally, and the inventory documents every automation requiring manual rebuild. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's team. We do not rebuild KulaHub automations as Dynamics 365 Flow inside the migration scope; that is a separate engagement or an internal admin task.