Migrate from STEL Order to Microsoft Dynamics 365 Sales

STEL Order has no native work-order entity in Dynamics 365 Sales — a custom table is required

STEL Order's Work Order is the central operational record in the platform, containing job type, assigned technician, scheduled date, status, and line items. Dynamics 365 Sales does not include a work-order table in its standard CRM schema — it ships with Leads, Opportunities, Accounts, Contacts, Cases, Quotes, Orders, and Invoices. The Field Service module adds the msdyn_workorder table, but that requires a separate $95/user/month license on top of the Sales Enterprise license. Without Field Service, FlitStack creates a custom WorkOrder Dataverse table and maps all STEL Order work order data into it. This means a custom Dataverse table must be provisioned and published before migration data lands, and any D365 views or dashboards referencing work orders need to be built post-migration.

STEL Order's one-client-per-record model splits into Account and Contact in D365

STEL Order embeds the customer contact (name, phone, email, address) directly on the Client record. Dynamics 365 separates Accounts (companies) from Contacts (people), with Contact holding the individual's name, email, phone, and an AccountId lookup pointing back to the parent Account. This means every STEL Order client record generates two D365 records — an Account and a Contact — and the Contact's AccountId must be populated after the Account is created. For STEL Order clients with multiple contact persons (e.g., a main contact and a billing contact), FlitStack creates additional Contact records under the same Account. This is a common source of migration error when the AccountId relationship is not sequenced correctly.

Scheduling and dispatch automations have no Dynamics 365 equivalent and must be rebuilt

STEL Order's job scheduling engine assigns technicians to work orders based on availability, location, and skill set, and triggers notifications when schedules change. Dynamics 365 Sales does not include scheduling or technician dispatch — those capabilities live in the Dynamics 365 Field Service Resource Scheduling Optimization (RSO) add-in, which is a separate product with its own licensing and configuration. FlitStack migrates work order data (technician assignments, scheduled dates, job types) but cannot move the scheduling algorithm. After migration, teams must either configure the Field Service scheduling module or rebuild scheduling logic using Power Automate.

D365 Power Platform API request allocation limits affect large-volume migration runs

Dynamics 365 (Dataverse) enforces request allocation limits per user or delegated admin per 24-hour rolling window — the exact number depends on the license tier (Sales Professional vs. Enterprise). A STEL Order migration with tens of thousands of work orders and invoice line items can exhaust the default API allocation in a single run, causing 429 Too Many Requests responses that pause the migration. FlitStack handles this by monitoring for throttling responses, backing off dynamically, and resuming from the last checkpoint — but this extends migration wall-clock time. For migrations exceeding 50,000 total records, FlitStack pre-qualifies the target D365 environment's API allocation before the first batch runs.

STEL Order custom fields require manual provisioning in D365 before data loads

STEL Order allows custom fields on clients, products, work orders, and invoices — and real-world STEL Order setups frequently have 10–30 custom fields tracking things like VAT registration numbers, product barcodes, job priority tiers, or technician cost-center codes. Dynamics 365 requires custom columns to be explicitly created in the target Dataverse table before data can be written to them — the API rejects writes to undefined custom columns. FlitStack's pre-migration schema scan identifies all STEL Order custom fields and their data types, then provisions the corresponding custom columns in D365 via the Power Platform admin API before the data migration phase begins. Fields that have no D365 equivalent are flagged for admin decision on mapping strategy.