Migrate from D-Tools to Salesforce Sales Cloud

D-Tools has no Lead object — all deal records are Projects that must be classified at migration time

D-Tools tracks every client interaction as a Project regardless of where it sits in the sales cycle — from initial estimate through contracted installation. Salesforce separates pre-qualified Leads from active Opportunities, and these objects have different fields, lifecycles, and page layouts. FlitStack AI classifies each D-Tools Project at migration time based on its status field: Estimate and Proposal stages route to Salesforce Lead records; Contracted, In Progress, and Completed stages route to Salesforce Opportunity records. This classification decision affects which Salesforce fields receive data and which custom fields need to be created on both Lead and Opportunity objects before the migration runs. Your team should review the classification logic against your Salesforce record-type configuration before the full migration commits.

D-Tools i3 product library requires a separate Product2 migration and CPQ rebuild for quote generation

D-Tools' i3 Integrated Product Library contains manufacturer part numbers, compatibility data, pricing tiers, and relationship data that lives outside the standard D-Tools data model. Salesforce has no native i3 equivalent — the closest native structures are Product2 records with PricebookEntry records. FlitStack migrates the i3 product data as Product2 reference records with their list prices, manufacturers, and part numbers intact. However, the compatibility rules, dynamic pricing logic, and product-configuration rules that D-Tools handles natively must be rebuilt in Salesforce CPQ. We export the i3 compatibility data as a structured CSV that your CPQ admin can use as the CPQ product rule input. This gap is pair-specific: it applies to every D-Tools migration regardless of size.

D-Tools middleware API rate limits constrain export throughput and require careful load sequencing

D-Tools Cloud uses a middleware-based API with a hard limit of 120 API calls per minute and 10,000 API calls per day per API key. This rate limit applies to all data types — Projects, Clients, Companies, Change Orders, and Service Plans — combined. FlitStack AI distributes export requests across the D-Tools API within these limits, using pagination (up to 500 records per GetClients call) to maximize data retrieved per request. For D-Tools SI on-premises instances, a separate export path via D-Tools SI's CSV and XML export tools bypasses the API limits entirely. The API rate limit is a pair-specific constraint: it does not apply to migrations from other platforms and must be accounted for in timeline estimation.

D-Tools service plan billing logic has no Salesforce equivalent and requires a rebuild in Revenue Cloud or CPQ

D-Tools service plans store dynamic pricing (calculated from project value), fixed monthly/annual pricing, billing frequencies, tax rates, and plan feature flags in a proprietary model. Salesforce has no native service plan object — recurring service agreements map to Salesforce Contracts with custom fields for plan type and billing frequency, but the billing calculation engine (dynamic pricing based on project scope) must be rebuilt. We preserve all service plan data (plan names, frequencies, feature flags, effective dates, and expiration dates) as Contract records. Dynamic pricing rules and tax calculation logic need to be rebuilt in Salesforce CPQ or as Apex triggers. The plan feature text is stored as a custom long-text field on Contract for reference.

D-Tools workflow definitions must be exported as reference documents for Salesforce Flow rebuild

D-Tools workflow rules (notifications, field-update actions, approval chains) are stored in D-Tools' proprietary format and have no export mechanism that is directly compatible with Salesforce Flow. FlitStack AI extracts workflow definitions from D-Tools as structured JSON documents that list each rule's trigger entity, criteria conditions, and action sequence. Your Salesforce admin uses these documents as a functional specification for rebuilding equivalent flows in Salesforce's Flow Builder. The D-Tools workflow export is pair-specific because D-Tools' workflow trigger model (entity-based with field-level criteria) differs from Salesforce's Flow trigger model (Record-Triggered, Scheduled, Platform Event). We do not attempt a direct translation; we provide the rebuild brief instead.