Migrate from Grade to Acumatica

Grade contacts map to Acumatica customer locations (the CR.Location table). Acumatica requires a Customer (CR.BAccount) record to exist before locations can be attached, so the parent Company from Grade must migrate first. Multiple Grade contacts sharing one primary company become a primary Location plus secondary contacts on the Customer's Contact sub-tab.

Grade companies map 1:1 to Acumatica Customers (BAccount). Company name becomes Customer Name, domain maps to Website, industry maps via value-mapping to the Acumatica Industry pick-list, and employee count or revenue maps to custom fields or notes since Acumatica does not store these on the Customer by default.

Grade companies flagged as suppliers or vendors map to Acumatica Vendors (AP.Vendor). The mapping requires a decision flag in Grade — if the Company record has no deal history and is used purely for procurement, it routes to Vendor; otherwise it routes to Customer. We surface this flagging rule in the migration plan before execution.

Grade deals map directly to Acumatica Opportunities (CR.CROpportunity). Each deal pipeline from Grade maps to an Acumatica Sales Process; the pipeline stages in Grade map value-by-value to Acumatica StageName values within that process. Probability and forecast category are re-applied from Grade's stage metadata or set to defaults in Acumatica.

Grade deal pipelines become Acumatica Sales Processes. Each pipeline requires a corresponding Sales Process in Acumatica before deals can import, because stage values are scoped to the process. We deliver a pipeline-to-sales-process mapping plan as part of the pre-migration schema setup, and Acumatica admins create the processes before data lands.

Grade activities (calls, emails, meetings, notes) map to Acumatica Activities (CR.CRActivity). Original timestamps, owners, and subject lines are preserved. Acumatica's ActivityType field distinguishes calls from emails from meetings using a pick-list that we set up during schema configuration. Note body maps to the Note text field.

Grade products map to Acumatica Inventory Items (IN.InventoryItem). Item type, description, and SKU carry over. Acumatica requires an Inventory Item Class before items can be created — we derive the class from Grade's product category or create a default class, and the admin confirms or adjusts the class assignment before the import.

Grade custom objects map 1:1 to Acumatica custom fields attached to the nearest standard object. Acumatica has no concept of standalone custom objects — if Grade's custom object stored independent records, we flatten them into custom fields on Customer or Opportunity, or surface the data as a Generic Inquiry (saved search) for reporting purposes.

Grade owner records resolve by email match against Acumatica Employees (EP.Employee). Unmatched owners are flagged before migration — teams either create Acumatica employee records for missing owners or assign their records to a fallback owner. No Opportunity or Activity lands in Acumatica without a resolved OwnerId.

Grade file attachments re-upload to Acumatica Files (SM.SM202020). File size limits apply — Acumatica's default is 25 MB per file, and inline images embedded in Grade notes are downloaded and rehosted as standalone files. Large files that exceed the limit are flagged for manual handling.

Grade workflows, sequences, and automation rules have no equivalent in Acumatica. Acumatica's automation layer uses Business Events, Actions, and Screens rather than CRM-style if-this-then-that rules. We export Grade's workflow definitions as a reference document for the Acumatica admin to rebuild using Acumatica's automation framework.

Grade's built-in reports on CRM objects map to Acumatica's Generic Inquiries (GI) and Saved Searches. The underlying data migrates, but the report definitions must be rebuilt — our team documents each Grade report's object, filters, and groupings so Acumatica's GI designer can reconstruct them after go-live.