Migrate from Guardian Software to Epicor Prophet 21

Guardian Customer records with address, contact details, and customer type classification map to Epicor's Customer (CustCnt) and Customer Ship To (CustShip) entities. The customer's primary contact person becomes the CustCnt record with the company-level details in CustForm. We remap Guardian customer type codes (foundry-specific classifications) to Epicor customer groups via a mapping table created during scoping.

Guardian Production Orders map to Epicor Job records with order status, quantity, schedule dates, and work center assignments. Each Production Order's material requirements map to JobMtl lines and its routing steps map to JobOper records. We validate that Guardian work center codes exist in Epicor's Resource Group table before migration; any unmapped work centers are flagged for the customer's Epicor admin to provision before the production order phase begins.

Guardian raw materials, alloys, and finished castings map to Epicor Part records with the Part Type set to Mfg (manufactured) or Purchased as appropriate. Inventory balances by location map to PartBin or WarehouseBin entries. Unit-of-measure conversions (Guardian's foundry-specific UOMs for weight and volume) are resolved via Epicor's UOMClass and UOMConv tables. Alloys and scrap materials require Part-plant configuration to ensure costing applies correctly in Epicor's inventory layer.

Guardian Quality Records with inspection results, non-conformance reports, and certificates of conformance map to Epicor's Engineering Change Order (ECO) structure for non-conformance tracking or to Kinetic Quality module entities if that module is licensed. Quality codes and disposition statuses require a mapping table because Guardian uses foundry-specific quality codes that Epicor models as either inspection types or UD (user-defined) custom fields. We recommend validating whether the customer licenses Epicor Kinetic Quality before migration so we scope UD table creation versus native quality object mapping accordingly.

Guardian Equipment and Asset records (machines, furnaces, tooling) map to Epicor Asset and Equip records with maintenance schedules, depreciation data, and location assignments. Tooling assets with wear tracking map to Equip records with linked EquipMeter entries for cycle counts. Depreciation data migrates as AssetMaintenance records. We verify that Guardian asset classifications map to Epicor asset groups and that any insurance or location data in Guardian moves to custom fields or UD tables in Epicor.

Guardian Work Center Routing (step-by-step routing of production orders through work centers with labor hours, machine hours, and sequence) maps to Epicor JobOper records with Operation Sequence, Work Center Group assignment, and Resource requirement. Foundry process types (molding, melting, pouring, finishing) are mapped to Epicor Resource Groups. Cycle-time and setup-time fields migrate to OpStds (operation standards) records. Routing structures vary by foundry process type, so we validate step count and cycle-time totals against Guardian's reported values during the sandbox migration.

Guardian Chart of Accounts with foundry-specific cost pools (scrap, rework, tool wear, alloy loss) requires a multi-level account mapping to Epicor's GL Account structure. Each Guardian cost pool maps to one or more Epicor GL accounts depending on the customer's desired granularity in Epicor reporting. We create a written account mapping matrix during scoping that the customer's accountant reviews before migration; Epicor GL accounts are created before any transaction data loads to ensure referential integrity.

Guardian custom fields on standard objects (foundry-specific tracking properties) migrate to Epicor User-Defined (UD) fields on the corresponding tables or to EF extended field tables if the kinetic schema supports it. Custom field data types are mapped to Epicor field types (character, numeric, date, checkbox). Complex formula fields from Guardian are flagged for manual rebuild in Epicor Kinetic calculated fields or Epicor Functions. We extract the full custom field manifest from Guardian during discovery and pre-create the destination fields in Epicor before any record migration begins.

Guardian historical journal entries for cost accounting and period closes migrate to Epicor GLJrnDtl records with entry headers mapped to GLJrnGrp. We extract entry headers and line items, preserving reversing entries and adjustment flags. Foundry-specific journal types (alloy variance, scrap journal, tool wear amortization) require account mapping to Epicor's GL code structure. Period-close status from Guardian is preserved as a reference note on the migrated entries. We recommend migrating a rolling 24-month window of open and recent closed periods to limit migration scope and archive older periods to a separate data store.

Guardian Purchase Order headers with line items, quantities, prices, and vendor assignments map to Epicor PODetail records. Vendor cross-references are remapped to Epicor's Vendor table (VendCnt) based on a vendor mapping table built during scoping. Open PO releases map to PORel records with scheduled dates and quantities. Closed POs migrate as reference records only; we do not recreate closed PO lifecycle events in Epicor. Any Guardian-specific PO types (alloy PO, tooling PO, maintenance PO) are mapped to Epicor's PO types via a classification lookup.

Guardian Documents (engineering drawings, batch sheets, compliance certificates) are exported as file attachments and re-associated in Epicor through DocReference records linked to the parent entity (Part, Job, Customer, or Vendor). File names and version metadata are preserved in the DocReference description and URL fields. For customers using Epicor's EDMS (Electronic Document Management System), we map documents to EDMS folders with the appropriate classification. PDF/A compliance certificates are stored as-is; binary formats are converted to PDF where Epicor rendering requires it.

Guardian User accounts with role-based access control map to Epicor User records with UserCodes for role classification. Role names and permission sets vary between Guardian and Epicor, so we map Guardian role hierarchies to Epicor Kinetic Security Groups during scoping. We recommend a post-migration access review workshop where the customer's Epicor admin aligns Guardian roles to Epicor Kinetic security groups with reference to the written role inventory we deliver. Active and inactive status is preserved; inactive users are migrated with status set to inactive and migrated login disabled pending reactivation by the admin.