ERP migration
Field-level mapping, validation, and rollback between Flectra and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Flectra
Source
Epicor Prophet 21
Destination
Compatibility
12 of 14
objects map 1:1 between Flectra and Epicor Prophet 21.
Complexity
BStandard
Timeline
8-12 weeks
Overview
Moving from Flectra to Epicor ERP is a migration from a general-purpose open-source ERP+CRM to a verticalised manufacturing and distribution platform. Flectra uses a flat res.partner model where individual contacts and companies share one object with a subtype flag; Epicor separates Customer, Contact, and ShipTo records across distinct tables with a parent-child hierarchy that must be resolved before any transactional data loads. Flectra's XML-RPC External API requires conversion to Epicor's REST/OData endpoints, and its Odoo-style product template-to-variant model maps to Epicor's Part and PartPlant structures with UOM handling that requires a pre-load PartClass resolution. We preserve fiscal positions, multi-currency rates, and custom x_ prefixed fields during transfer, flag any Flectra custom modules that have no Epicor equivalent, and sequence the migration in dependency order so that UOM classes, chart of accounts segments, and customer hierarchies are in place before transactional imports begin. Workflows, automations, and Flectra's internal note-based pipeline stages do not migrate; we deliver a written inventory of every automation requiring rebuild in Epicor BPM and a data-cleanse checklist for records that exceed Epicor's field-length constraints.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Flectra object lands in Epicor Prophet 21, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Flectra
res.partner (is_company=true)
Epicor Prophet 21
Customer
1:1Flectra's res.partner records flagged is_company=true map to Epicor Customer. The Flectra partner name becomes Customer.CustID (short code) and Customer.Name. We resolve the parent-child relationship so that Flectra child contacts under a company map to Epicor Contact records linked to the Customer via CustomerNum. VAT number from Flectra's vat field maps to Customer.TaxPayerID. Website maps to CustomerTerritory reference if Territory management is active.
Flectra
res.partner (is_company=false)
Epicor Prophet 21
Contact
1:1Flectra contacts flagged is_company=false map to Epicor Contact. Name, email, phone, street, city, state, zip, country map to Contact fields. The parent_id relationship to the company res.partner resolves to the Epicor CustomerNum linkage. Multiple addresses per Flectra contact map to ContactAddress records. If Flectra contact has no email, we set Contact.PerConOK=false per Epicor validation.
Flectra
sale.order
Epicor Prophet 21
OrderHed
1:1Flectra sale.order maps to Epicor OrderHed. Order date, customer reference, and fiscal position carry across. The Flectra sale.order.state (draft/confirmed/done/cancel) maps to Epicor OrderHed.OpenLine and OpenRelease flags; confirmed orders set OrderHeld=false. The currency_id maps to OrderHed.CurrencyCode, and the Flectra pricelist_id determines the Epicor PriceLstCode for line pricing.
Flectra
sale.order.line
Epicor Prophet 21
OrderDtl
1:1Flectra sale.order.line maps to Epicor OrderDtl. Product, quantity, unit of measure, unit price, and tax map across. The Flectra product.product variant ID resolves via SKU to Epicor PartNum. If Flectra used product.template (master product) with no variant, we look up the default variant in Epicor or create a PartMaster placeholder during migration. Discount percent and amount map to OrderDtl.DiscountPercent and DiscountAmount.
Flectra
account.move (out_invoice)
Epicor Prophet 21
InvcHead
1:1Flectra account.move with move_type=out_invoice maps to Epicor InvcHead. Invoice number, date, due date, partner, and amount transfer. Flectra's payment_state (posted/pending) maps to InvcHead.InvoiceType and InvcHead.Settled=false. Line items map to InvcDtl with PartNum resolved via SKU lookup. Flectra's analytic tag lines (account AnalyticAccount mapping) translate to Epicor InvcDtl.ExtMtlUnitCost for cost-accounting visibility if the target Epicor org uses Project Costing.
Flectra
product.template
Epicor Prophet 21
Part
1:1Flectra product.template maps to Epicor Part (the product master). The Flectra product_type (consumable/storable/service) maps to Part.TypeCode. Default code, sales description, list price, standard cost, and the template's product_category map to Part.ClassID via a PartClass pre-created in Epicor. The x_ prefixed custom fields on product.template migrate as Part UD (User Defined) fields we pre-create in Epicor UD Column Map.
Flectra
product.product
Epicor Prophet 21
PartPlant
1:manyFlectra product.product variants under a product.template split into multiple Epicor PartPlant records (one per Flectra variant). The variant attributes (size, colour, dimension) from Flectra attribute_line_value map to Epicor PartDim dimensions if PartDim tracking is enabled, or to Part character UD fields. The template's standard price and cost inherit to each PartPlant row, overridable per site. We resolve the Flectra template-to-variant relationship during the split so that no variant is orphaned.
Flectra
purchase.order
Epicor Prophet 21
POHeader
1:1Flectra purchase.order maps to Epicor POHeader. Vendor partner (supplier), order date, and payment terms map across. The Flectra purchase.order.state maps to Epicor POLine.OpenRelease flags. Vendor part number from Flectra purchase.order.line.vendor_part_number maps to PODetail.VendorPN if present.
Flectra
purchase.order.line
Epicor Prophet 21
PODetail
1:1Flectra purchase.order.line maps to Epicor PODetail. Product, ordered quantity, unit of measure, and unit cost transfer. The Flectra product SKU resolves to Epicor PartNum. Receipt status flags from Flectra (from done state) map to PODetail.ReceivedQty tracking. Line taxes map to PODetail.TaxExempt and TaxCatID.
Flectra
project.project
Epicor Prophet 21
Project
1:1Flectra project.project maps to Epicor Project (ProjectMgmt module or PSA depending on Epicor edition). Project name, date, and stage status transfer. The Flectra analytic_account_id links to Epicor's Project Phase and WBS structure. If the customer uses Epicor's Project Billing module, Flectra's project billing rules map to Epicor billings groups. We note that Flectra's project.timesheet and project.milestone are not native Epicor Project objects and require manual rebuild or Project BPA configuration.
Flectra
project.task
Epicor Prophet 21
Task
1:1Flectra project.task maps to Epicor Task linked to the Project. Task name, planned hours, effective hours, stage, and user_id (assignee) transfer. Sub-tasks nested via Flectra's child_ids relation map to Epicor Task.ParentTaskNum. Task state maps to Epicor Task.TaskStatus. Assignee resolves via email match to Epicor User.
Flectra
hr.employee
Epicor Prophet 21
Employee
1:1Flectra hr.employee maps to Epicor Employee. Name, department, job title, work email, and phone transfer. Flectra's department_id resolves to Epicor Employee.Dept if the target Epicor company has HRM module active. Bank account and salary history remain in Flectra's payroll module and do not migrate; we flag these as HR module objects requiring manual payroll rebuild in Epicor HCM.
Flectra
ir.attachment
Epicor Prophet 21
DocumentRef
1:1Flectra binary attachments in ir.attachment export as base64-encoded files. We re-attach in Epicor as DocumentRef records linked to the parent entity (OrderHed, InvcHead, Part) via DocType and DocKey. If the Epicor org uses Epicor Docs (formerly EDMS), attachments link via DocType and the corresponding DocLink. We flag any attachment exceeding Epicor's maximum file size and deliver those as a separate archive package.
Flectra
Custom Fields (x_ prefix)
Epicor Prophet 21
UD Fields
lossyFlectra custom fields defined via ir.model.fields with state='manual' enumerate during discovery and pre-create in Epicor UD Column Map (UD01-UD10 or table-specific UD columns). We map each x_ prefixed field to the equivalent Epicor UD column, apply the same data type (character, date, decimal, integer, checkbox), and flag any Flectra custom field with no clear Epicor UD analog as requiring a gap analysis before migration load.
| Flectra | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| res.partner (is_company=true) | Customer1:1 | Fully supported | |
| res.partner (is_company=false) | Contact1:1 | Fully supported | |
| sale.order | OrderHed1:1 | Fully supported | |
| sale.order.line | OrderDtl1:1 | Fully supported | |
| account.move (out_invoice) | InvcHead1:1 | Fully supported | |
| product.template | Part1:1 | Fully supported | |
| product.product | PartPlant1:many | Fully supported | |
| purchase.order | POHeader1:1 | Fully supported | |
| purchase.order.line | PODetail1:1 | Fully supported | |
| project.project | Project1:1 | Fully supported | |
| project.task | Task1:1 | Fully supported | |
| hr.employee | Employee1:1 | Fully supported | |
| ir.attachment | DocumentRef1:1 | Fully supported | |
| Custom Fields (x_ prefix) | UD Fieldslossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Flectra gotchas
XML-RPC API format requires non-standard serialization
No official migration utility or dedicated export tooling
Community edition lacks functional support and hosting
Large imports can trigger timeouts without batching
Epicor Prophet 21 gotchas
Third-party bolt-on integrations complicate migration scope
Dirty data without standardized processes compounds migration risk
SDK customizations and BPMs may not survive platform upgrades
Report-based export only for non-technical users
Per-user pricing model requires accurate user count before migration planning
Pair-specific challenges
Migration approach
Discovery and Epicor edition assessment
We audit the source Flectra instance via XML-RPC discovery script enumerating ir.model, ir.model.fields, sale.order, account.move, product.product, product.template, purchase.order, project.project, and hr.employee record counts and states. We assess which Epicor edition is in scope (Epicor Kinetic Cloud, Prophet 21, or BisTrack on-premise), confirm the target company in Epicor has the relevant modules activated (Order Management, Inventory Control, Purchasing, Project Management), and identify any Flectra custom x_custom_model extensions. The discovery output is a written migration scope document with record counts, dependency map, and Epicor edition and module recommendation.
Schema pre-creation in Epicor
Before any data moves, we create the Epicor schema foundations: PartClass records for each Flectra product category, UD Column Map entries for every x_ prefixed Flectra custom field, Customer records for Flectra is_company=true partners (in bulk with a Customer staging import), and Project records for each Flectra project. We also configure UOMClass and UOMUnit entries to match Flectra's uom.category structure. All schema work is deployed to a Epicor Sandbox company first for validation and sign-off before production schema creation begins.
Sandbox migration and reconciliation
We run a full migration into an Epicor Sandbox using production-like data volumes. The customer's Epicor administrator reconciles record counts across all entities, spot-checks random records for field accuracy (particularly PartNum to SKU lookup, CustomerNum to Flectra company name, and Contact email accuracy), and validates that Flectra analytic tags appear as mapped in the GL segment or Project cost code handoff document. Sign-off on the sandbox migration is required before production migration begins. Any schema corrections are made during this phase.
Owner and employee User reconciliation
We extract every distinct Flectra user referenced on sale.order, purchase.order, project.task, and hr.employee records and match by email against the Epicor destination company's User table. Any Flectra user without a matching Epicor User is placed in a reconciliation queue. The customer's Epicor administrator provisions missing Users in Epicor (active or inactive status depending on whether the original Flectra user is still employed). OwnerId references on Flectra records must resolve to an Epicor User before transactional imports can proceed.
Production migration in dependency order
We run production migration in record-dependency order: UOMClass and UOMUnit (prerequisite for all product and order line imports), PartClass (prerequisite for Part), then Part (from Flectra product.template and product.product with variant split), then Customer (from Flectra is_company=true), then Contact (from Flectra is_company=false with CustomerNum resolved), then OrderHed and OrderDtl (with PartNum and CustomerNum resolved), then InvcHead and InvcDtl, then POHeader and PODetail, then Project and Task, then Employee, then Attachments (as DocumentRef), then Custom Fields data loaded into Epicor UD columns. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, delta migration, and automation rebuild handoff
We freeze Flectra writes during cutover, run a final delta migration of any records modified during the migration window, then declare Epicor the system of record. We deliver the Flectra automation and workflow inventory (Flectra Server Actions, Automated Actions, and ir.cron triggers) as a written document with recommended Epicor Business Process Management (BPM) equivalents, so the customer's Epicor administrator or implementation partner can rebuild automations post-migration. We provide a one-week hypercare window for reconciliation issues. We do not rebuild Flectra automations as Epicor BPM inside the migration scope; that is a separate engagement.
Platform deep dives
Flectra
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Flectra and Epicor Prophet 21.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Flectra: Not publicly documented.
Data volume sensitivity
Flectra doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Flectra to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Flectra to Epicor Prophet 21 migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Flectra
Other ways to arrive at Epicor Prophet 21
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.