Migrate from Stride ERP to Microsoft Dynamics 365 Business Central

Stride organizes accounts into a standard COA with parent-child hierarchy and account codes. We map Stride account numbers and names directly to Dynamics 365 G/L Account records, preserving the parent account reference. The destination's dimension structure (Financial Dimensions in Finance and Operations or Analysis dimensions in Business Central) may differ from Stride's segment model, so we flatten the Stride hierarchy into a flat account list and flag any multi-segment accounts that require reconstruction using destination dimension defaults.

Customer records including contact details, billing addresses, shipping addresses, and credit terms transfer to Dynamics 365 Customer. We preserve Stride lifecycle stage flags as custom fields since Dynamics 365 uses a different status model. Payment terms, discount codes, and credit limits map directly. We flag any soft-deleted customer records in Stride to avoid importing inactive customers into the destination.

Vendor master data with AP aging balances transfers cleanly to Dynamics 365 Vendor. We preserve vendor-specific payment terms, bank account details, and W-9/W-8 tax information where present. Any vendor records flagged as inactive in Stride are excluded from the primary import but listed in a reconciliation report for the customer's AP team to review.

Outstanding invoices and credit memos require careful sequencing to preserve aging. We map Stride invoice numbers to Dynamics 365's number sequence format and preserve payment terms, discount codes, due dates, and partial payment history. Each open invoice is created as a pending customer or vendor transaction in the destination, with the original invoice date and due date maintained for accurate aging reports after cutover.

Asset records include location assignments, depreciation schedules, accumulated depreciation balances, and assignment history. We extract Stride's depreciation history table separately from the asset master and reconstruct book value in Dynamics 365 using the destination's native depreciation engine. Country-specific depreciation methods (Nigeria vs Canada tax rules embedded in Stride) must be identified during export and mapped to the destination's supported depreciation profiles, which vary by Fixed Asset Group configuration.

SKU-level items with warehouse locations, reorder points, and current stock quantities map to the destination's Item (Inventory SKU) or Product (non-inventory) schema. Stride's multi-location inventory requires us to request the detailed inventory ledger with warehouse codes; we reconstruct the multi-warehouse structure in Dynamics 365 using location codes as Warehouse IDs. We flag any items where the sum of location quantities does not match the aggregate total reported in the standard export.

Employee records transfer as Dynamics 365 Human Resources Worker records, preserving department assignments, job titles, employment status (active, terminated, on leave), and hire dates. Active and terminated employees are handled separately to preserve the HR history without disrupting reporting on headcount. We map Stride's department codes to the destination's HR Business Unit structure.

Payroll runs and compensation history require parsing Stride's proprietary deduction codes and mapping them to Dynamics 365 Human Resources benefit enrollment and deduction categories. We load compensation history as a separate historical record (Compensation History in HR) rather than live payroll entries, since live payroll requires active benefit enrollment setup in the destination. Each pay period from Stride becomes a compensation history entry with the original pay date and gross/net amounts.

Project records with status, assignees, milestones, task hierarchies, billable rates, and project budgets transfer to Dynamics 365 Project Management. Custom fields on Stride projects map to the destination's custom properties. We preserve billable/non-billable flags and project type classification. Projects with open WIP (work-in-progress) transactions are flagged for the customer's project accountant to review before closing the migration window.

Purchase requests are a Stride add-on module and may not exist on Basic tier accounts. Where they exist, we map approval workflows and line items to the destination's Purchase Requisition schema, preserving approval status and requester assignment. We flag any pending purchase requests for the customer's purchasing team to re-enter or re-approve in Dynamics 365 since approval workflows do not migrate.

Document Management System attachments are file-level exports that we associate with their parent object (Project, Customer, Vendor, Employee) in Dynamics 365 via SharePoint integration or Dataverse document storage. File naming conventions in Stride vary by use case, so we apply a consistent naming pattern during import: [ObjectType]_[RecordID]_[OriginalFilename]. We do not migrate folder hierarchies as code; these are reconstructed by the customer's admin in SharePoint.

Ticket records including status, assignee, customer association, conversation history, and SLA configuration map to Dynamics 365 Customer Service Case. Stride's SLA configuration does not transfer and must be re-established in Dynamics 365 Customer Service as Service Level Agreements linked to Case types. Conversation history migrates as Email Messages or Notes attached to the Case record.

Open and historical sales orders from Stride's Sales module transfer to Microsoft Dynamics 365 Sales Orders or Purchase Orders depending on the order direction (customer-facing vs vendor-facing). Order status, line items, pricing, and discounts are preserved. We map Stride's order pipeline stages to Dynamics 365 status values. Fully invoiced and closed orders are imported as historical records; pending orders are flagged for the sales team to confirm before processing in the destination.