Migrate from Priority ERP to Microsoft Dynamics 365 Business Central

Priority Customer records map to D365 Account (the organization) and Contact (the individual). Priority's pay-to and ship-from address hierarchies map to separate D365 address roles on Account. Credit limits, price lists, and payment terms from the Priority customer header become fields on Account, with primary contact details mapped to the Contact record. We resolve the parent Account before Contact insert to satisfy D365's required AccountId lookup on Contact.

Priority Vendors map to D365 Vendors with a similar address hierarchy (pay-to, ship-from) and purchasing-specific fields. Payment terms, tax vendor group, and W-9 information from Priority map to D365 Vendor fields. We extract the full vendor hierarchy and note that D365 Vendors are used in both the purchasing and accounts payable contexts, unlike Priority which separates vendor purchasing data from AP tracking.

Priority Items carry part numbers, BOM links, stocking dimensions, and warehouse-specific quantities. We extract item headers and variant attributes, mapping to D365 Released Products with type (Item or Service), product number, and storage dimensions. Multi-warehouse quantities from Priority map to D365 on-hand inventory by warehouse site. Standard cost and price are extracted from Priority item pricing for D365 Trade Agreement setup.

Priority Sales Orders with status open map to D365 Sales Orders; confirmed or fulfilled orders map to Sales Order with updated status. Header fields (customer reference, terms, freight charges) and multi-line details with pricing, discounts, and tax allocation migrate directly. We map Priority's order hold and approval status to D365 Document Status fields. D365 Sales Order lines require a Released Product reference resolved at migration time from the item mapping.

Priority Purchase Orders follow a mirror structure to Sales Orders but belong to the Vendors dimension. We extract PO headers and lines, mapping to D365 Purchase Order with Vendor reference, terms, and line items for product, quantity, and cost price. Freight and charges from Priority PO headers map to Purchase Order header charges in D365. Approval workflow status from Priority PO becomes D365 Document Status and workflow state.

Priority's multi-segment account codes (01-100-320 representing company, department, and cost center) require structural decomposition into D365's flat account code model with separate Financial Dimension fields. We decompose each segment during the mapping phase, extract the full account tree, and validate segment semantics against the destination's dimension model. Any accounts where segment semantics cannot be cleanly represented in D365 dimensions are flagged for customer approval before mapping proceeds. D365 Financial Dimension framework is configured before any GL or journal migration begins.

Outstanding payables and receivables carry aging calculated from document due date in Priority. Loading open AP/AR before Customers and Vendors in D365 causes incorrect aging because D365 calculates due dates from invoice date and payment terms. We sequence the load: Customers and Vendors first, then open AP/AR documents, then GL entries. Total open invoice amounts are validated post-load against Priority's open invoice aging report. Credit memos and prepayments map to separate document types in D365 with appropriate positive/negative amounts.

Priority GL journal entries consist of debit and credit lines linked to account codes, with support for reversing entries and recurring templates. We extract full entry details including posting date, period, and description, then map to D365 General Journal lines. Each line carries a Ledger Dimension (the account) and optional Financial Dimension values. Recurring templates in Priority map to D365 Journal Templates for periodic journal creation. Reverse entry logic (effective date and reversing date) migrates as separate journal batches in D365.

Priority Projects track budgets, assignments, billing records, and milestones. We extract project headers and associated WBS rows, time entries, and billing details, mapping them to D365 Projects. Note that Priority's project billing structures and WBS conventions differ from D365's project hierarchy and dimension model. Projects in D365 require Financial Dimensions assigned at the project level, which we configure during the chart of accounts mapping phase and validate in sandbox before production migration.

Employee records include org unit assignments and role-based permissions. We extract employee headers and map to D365 Worker in the Human Resources module. Note that salary, compensation history, and benefits data require explicit customer sign-off before migration due to data sensitivity. D365 HR requires the Human Resources module to be provisioned; if the destination tenant does not include HR, we migrate employee contact and organization data only as Contact or Project resource records.

Priority stores document attachments as file references linked to parent records (Customers, Orders, Projects). We export Priority attachment blobs to Azure Blob Storage, then create SharePoint document libraries in D365 or Dataverse annotations on the relevant entity. Each file receives a metadata record preserving the original filename, upload date, and parent record reference. Attachment paths referencing soft-deleted or archived Priority records result in orphaned files logged in the final validation report with a count of affected files.

Priority's form generator and workflow builder create business logic that lives only in the UI layer and cannot be extracted via API or export tools. We document the existence of every custom form and workflow during the discovery phase and deliver a written inventory specifying the business logic each carries, the recommended D365 replacement approach (Power Automate cloud flow, model-driven app form, or business rule), and an estimated rebuild effort. We do not rebuild Priority forms or workflows as part of the migration scope; that work is a separate engagement.

Priority's open architecture supports custom tables that hold supplementary business data not modeled in standard Priority forms. We extract custom table schemas and data during the technical audit, then pre-create equivalent Dataverse custom tables in D365 before migration. All custom fields, lookup relationships, and validation logic are replicated in D365. Any custom tables with foreign key references to standard Priority objects (Customer, Vendor, Item) require those standard records to be migrated first to satisfy the lookup constraint.