ERP migration

Migrate from Flectra to Epicor Prophet 21

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 logo

Flectra

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

86%

12 of 14

objects map 1:1 between Flectra and Epicor Prophet 21.

Complexity

BStandard

Timeline

8-12 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Flectra logo

Flectra

What's pushing teams away

  • Community edition provides no security patches, version upgrades, or functional support, leaving self-hosted instances exposed to unpatched vulnerabilities over time.
  • The XML-RPC API lacks the documentation depth and tooling ecosystem of REST-based ERPs, making integrations and migrations harder to automate.
  • Small vendor ecosystem compared to established ERPs means limited third-party consultants, integrators, and certified implementation partners are available.
  • Performance degrades on large transaction volumes (100k+ records) without the infrastructure optimization that commercial ERPs provide out of the box.
  • Version upgrade process for on-premise installations is manual and error-prone, often requiring developer involvement to resolve module incompatibilities.

Choosing

Epicor Prophet 21 logo

Epicor Prophet 21

What's pulling them in

  • Industry-specific design for wholesale distributors, not a general-purpose ERP repurposed for distribution — distributors choose P21 because it matches their replenishment, kitting, and counter-sale workflows out of the box.
  • Strong inventory control with automated replenishment, lot and serial tracking, and multi-warehouse management appeals to distributors with complex stock requirements and tight margin pressure.
  • Responsive customer support cited across G2 and Gartner reviews, with Epicor's 90% retention rate reflecting long-term customer satisfaction in a market where switching costs are high.
  • Cloud deployment on Microsoft Azure provides the flexibility to scale user counts and warehouse locations without on-premise infrastructure investment.
  • The Software Development Kit lets distributors personalize P21 to their specific business processes without modifying the application source code, preserving upgrade paths.

Object mapping

How Flectra objects map to Epicor Prophet 21

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)

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

Flectra'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)

maps to

Epicor Prophet 21

Contact

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

OrderHed

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

OrderDtl

1:1
Fully supported

Flectra 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)

maps to

Epicor Prophet 21

InvcHead

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

Part

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

PartPlant

1:many
Fully supported

Flectra 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

maps to

Epicor Prophet 21

POHeader

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

PODetail

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

Project

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

Task

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

Employee

1:1
Fully supported

Flectra 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

maps to

Epicor Prophet 21

DocumentRef

1:1
Fully supported

Flectra 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)

maps to

Epicor Prophet 21

UD Fields

lossy
Fully supported

Flectra 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.

Gotchas + challenges

What specifically takes care here

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 logo

Flectra gotchas

High

XML-RPC API format requires non-standard serialization

High

No official migration utility or dedicated export tooling

Medium

Community edition lacks functional support and hosting

Medium

Large imports can trigger timeouts without batching

Epicor Prophet 21 logo

Epicor Prophet 21 gotchas

High

Third-party bolt-on integrations complicate migration scope

High

Dirty data without standardized processes compounds migration risk

Medium

SDK customizations and BPMs may not survive platform upgrades

Medium

Report-based export only for non-technical users

Low

Per-user pricing model requires accurate user count before migration planning

Pair-specific challenges

  • XML-RPC to REST endpoint translation requires custom adapter

    Flectra exposes all data via XML-RPC using the execute_kw(db, uid, password, model, method, args) call pattern. Epicor ERP exposes data via REST and OData endpoints with JSON payloads and OAuth 2.0 bearer token authentication. Our migration engine cannot connect these directly. We implement an XML-RPC client adapter that translates Flectra read operations into the standard format our engine processes, then transforms output to Epicor's REST API payload structure before writing. Without this adapter layer, every Flectra field access and write must be hand-coded for the specific migration, increasing timeline and error risk significantly.

  • res.partner company-contact split must resolve before transactional import

    Flectra stores companies and individual contacts in a single res.partner table differentiated by is_company boolean. Epicor uses separate Customer, Contact, and ShipTo tables with referential integrity requirements. If Flectra contact records carry a parent_id pointing to a company, we must create the Epicor Customer first, obtain the CustomerNum, then create the Epicor Contact with that CustomerNum linkage. Loading contacts without this dependency order results in orphan records and failed foreign-key validation. We enforce a two-pass import: Companies to Customer first, then Contacts to Contact with CustomerNum resolved.

  • Flectra custom x_custom_model objects have no Epicor native equivalent

    Flectra's Odoo-style modular architecture allows any module to define a custom x_custom_model table in the Flectra database. Epicor ERP does not have a generic custom object creation tool equivalent to Odoo's x_custom_model; instead it uses User Defined Fields (UD01-UD10) and UD Column Maps per table, plus Epicor Kinetic's REST Custom Entities for more complex structures. We enumerate all custom Flectra models during discovery and produce a gap analysis mapping each to either a UD column or a Custom Entity configuration before migration. Any Flectra custom module with no Epicor equivalent is flagged in the delivered inventory for manual rebuild or custom development.

  • Epicor UOM class and PartClass must pre-exist before Product import

    Epicor enforces referential integrity on Part.ClassID linking to PartClass. Flectra's product_category_id maps to Epicor PartClass, but Flectra does not have a PartClass equivalent; it uses product category records. We create Epicor PartClass records for each Flectra product category before Part import, mapping the category name and description. If Flectra used a large number of product categories (100+), this pre-creation step adds scope. UOM Class resolution similarly requires that the target Epicor company has UOMClass records matching the Flectra uom_id categories before any product or order line imports can succeed.

  • Flectra's analytic accounting tags require manual Epicor cost category mapping

    Flectra carries analytic accounting tags on sale.order.line and account.move.line via the account.analytic.account model. Epicor ERP handles cost categorisation via Project and Phase WBS, or via GL Account segments for direct posting. Flectra analytic tags that were used purely for internal cost-centre reporting have no direct Epicor equivalent and must be mapped to GL segments or Project cost codes. We flag all Flectra analytic.account records during discovery and deliver a mapping table to the customer's Epicor admin, who configures the GL segment structure before migration load begins.

Migration approach

Six steps for a successful Flectra to Epicor Prophet 21 data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

Flectra logo

Flectra

Source

Strengths

  • Community edition is free with no per-user licensing cost, removing financial barrier to adoption.
  • On-premise hosting option provides full data sovereignty for regulated-industry customers.
  • Modular architecture means customers deploy only the modules they need, reducing system complexity.
  • XML-RPC External API allows programmatic data access across all business objects via standard ORM methods.
  • Open-source codebase can be audited and extended by the customer's own developers without vendor dependency.

Weaknesses

  • Community edition receives no security patches or version upgrades from the vendor, creating long-term maintenance risk.
  • XML-RPC API is less widely documented and supported by third-party integration tools compared to REST alternatives.
  • Smaller community and partner ecosystem than Odoo means fewer pre-built modules and fewer implementation consultants.
  • Performance on large datasets (100k+ records) is not optimised without significant infrastructure tuning.
  • Version upgrade path for on-premise installations requires manual testing of all custom modules for compatibility.
Epicor Prophet 21 logo

Epicor Prophet 21

Destination

Strengths

  • Purpose-built for wholesale distribution with industry-specific replenishment, kitting, and counter-sale workflows out of the box.
  • Multi-warehouse management with bin locations, cross-docking, and real-time inventory visibility across all warehouse locations.
  • Automated replenishment engine with demand-based and min-max planning reduces stockouts and overstock carrying costs.
  • AI-infused reporting via Epicor Prism provides Gen AI-driven insights into ERP data without requiring a BI team.
  • Strong customer retention at 90% and a 50-year track record in the distribution vertical provides long-term vendor stability.

Weaknesses

  • High total cost of ownership — per-user pricing of $150-200/month plus $10K-$500K implementation creates significant budget commitment for small and mid-market distributors.
  • Customization via SDK requires technical expertise and introduces upgrade risk when custom code conflicts with new P21 releases.
  • Report generation performance is a known pain point — multiple users report system freezes during large or complex report exports.
  • Third-party bolt-on reliance for functionality that competitors include natively increases integration complexity and total solution cost.
  • Limited public API documentation — developers building custom integrations report difficulty finding P21 API authentication methods and endpoint specifications.

Complexity grading

How hard is this migration?

Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Flectra and Epicor Prophet 21.

  • Object compatibility

    B

    2 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Flectra: Not publicly documented.

  • Data volume sensitivity

    B

    Flectra doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Flectra to Epicor Prophet 21 migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Flectra to Epicor Prophet 21 data migrations

Answers to the questions buyers ask most during Flectra to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between eight and twelve weeks for accounts under 20,000 Flectra partners and 5,000 Sales Orders with no complex custom object extensions. Migrations with active multi-line Purchase Orders, large Product catalogs (over 30,000 SKUs), Bill of Materials structures, multi-site Plant configurations, or extensive x_custom_model extensions move to fourteen to twenty-two weeks because of PartClass pre-creation, BOM tree traversal, and custom object gap analysis work. Epicor's own implementation timelines (typically 3-9 months for a greenfield Epicor deployment) run in parallel with our data migration scope.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Flectra.
Land in Epicor Prophet 21, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day