ERP migration

Migrate from Total ETO to Epicor Prophet 21

Field-level mapping, validation, and rollback between Total ETO and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.

Total ETO logo

Total ETO

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

100%

13 of 13

objects map 1:1 between Total ETO and Epicor Prophet 21.

Complexity

BStandard

Timeline

4-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Total ETO to Epicor ERP is a migration from a purpose-built ETO desktop application with no public API into a cloud-native manufacturing ERP with a full REST API and deep discrete manufacturing capabilities. The fundamental challenge is that Total ETO holds all ETO data in a single SQL Server database without a published API, while Epicor expects data through its API or data import tools with proper schema enforcement. We extract from Total ETO via database export or structured CSV, then load into Epicor Kinetic in dependency order: Part master first, then multi-level BOMs with each revision preserved as a distinct version, then open purchase orders and RFQs, then Work Orders with their operation routing, then Quality records (NCRs and Inspections), then inventory quantities with location and project reservation data, then employee and time-entry records. We flag the accounting boundary explicitly—Total ETO integrates with QuickBooks or Sage rather than maintaining its own GL, so account balances and open AP/AR may need to be reconciled from the connected accounting system simultaneously. Workflows, custom reports, and CAD integrations do not migrate; we deliver written inventories for the customer's team to rebuild in Epicor.

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

Total ETO logo

Total ETO

What's pushing teams away

  • The Windows desktop interface is described as dated by multiple reviewers, and Total ETO has acknowledged a web-based version is in development but not yet available.
  • Organizations that expand beyond pure ETO into higher-volume production find the platform's single-industry focus becomes a constraint rather than a strength.
  • Permission granularity is excessive — without deliberate configuration the system exposes too many controls to users who do not need them, creating compliance and data-integrity risk.
  • Support responsiveness, while generally excellent, cannot compensate when bugs require significant engineering fixes; one reviewer waited while the president of the company handled a user-error case personally.
  • Companies seeking to consolidate onto platforms like NetSuite or SAP for broader operational visibility eventually migrate their project histories, BOMs, and job costs into systems with different data architectures.

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 Total ETO objects map to Epicor Prophet 21

Each row shows how a Total ETO 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.

Total ETO

Project

maps to

Epicor Prophet 21

Job or Project (Job Manager)

1:1
Fully supported

Total ETO organizes all ETO activity under Projects with a lifecycle from quote through delivery. Epicor Kinetic uses Jobs (manufacturing) and the Project module for extended project costing. We map Total ETO Projects to Epicor Jobs for manufacturing work and to the Epicor Project billing module for project-centric revenue recognition where applicable. Project status, owner, and dates migrate as metadata on the Job or Project record. If the customer uses Epicor Project for revenue recognition on long-cycle builds, we configure the Project setup before migrating the first Project record.

Total ETO

Part

maps to

Epicor Prophet 21

Part Master (Part table)

1:1
Fully supported

Total ETO Part records carry description, unit of measure, standard cost, supplier link, and a complete usage history trail. We map these to Epicor Part records, preserving PartNumber as the primary key and stocking type (stocked, manufactured, or purchased). Part safety stock, lead time, and costing method migrate as PartPlant and PartCost records. We flag any Total ETO parts with duplicate numbers during extraction so that the Part master is deduplicated before BOM creation, preventing downstream assembly errors.

Total ETO

Bill of Materials (BOM)

maps to

Epicor Prophet 21

Job BOM / Engineering Workbench BOM

1:1
Fully supported

Total ETO BOMs are multi-level structures with distinct revision history that must not be collapsed into a single BOM at the destination. We treat each BOM revision as a separate Job BOM in Epicor, importing in sequence with revision dates preserved. The parent-component relationships, quantity-per, and operation associations transfer as individual BOM lines. Epicor's Engineering Workbench holds the approved BOM; Job BOMs hold the as-built version for each production run. We map Total ETO's approved BOM revisions to Epicor Engineering BOMs and each build-specific BOM to Job BOMs, maintaining the distinction between design intent and production execution.

Total ETO

Customer

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

Total ETO Customer records include contact details, address, and account balance. We map these to Epicor Customer records, preserving the account balance as open AR. Ship-to addresses migrate as Customer ShipTo records linked to the parent Customer. Open sales orders from Total ETO (if applicable) map to Epicor Orders. Customer credit limits and payment terms transfer to Epicor's Customer credit and terms fields.

Total ETO

Vendor

maps to

Epicor Prophet 21

Supplier

1:1
Fully supported

Total ETO Vendor records include purchasing terms, contact information, and any active RFQs or POs. We map vendors to Epicor Supplier records, preserving PO terms and preferred carrier information. Active RFQs become Epicor Request for Quotation records; open POs become Epicor Purchase Orders. Supplier part numbers and lead times migrate as Supplier Price records linked to the Part master for each supplier-part combination.

Total ETO

Purchase Order (open)

maps to

Epicor Prophet 21

Purchase Order

1:1
Fully supported

Open POs and RFQs in Total ETO reference live part numbers and vendor commitments. They cannot be imported before the Part master is established at Epicor because line-item part references would resolve to null. We sequence migration: Part master first, then Supplier, then open POs. Any PO lines referencing parts not yet in Epicor are flagged in a pre-migration report and held until the part master is confirmed. Closed POs migrate as historical records if the customer requires AP reconciliation from Total ETO against Epicor's AP module.

Total ETO

Work Order

maps to

Epicor Prophet 21

Job / Labor Detail

1:1
Fully supported

Total ETO Work Orders link to Projects and BOMs, tracking manufacturing operations by shop-floor routing. We map Work Orders to Epicor Jobs, preserving the Work Order-to-Project linkage as the Job's ProjectCode reference. Operation sequences and labor class assignments transfer to JobOper and LaborDtl records. If Total ETO tracks sub-operations or outside operations, these map to Epicor JobOper with the Subcontract checkbox and outside processing reference. We validate that the routing operations in Total ETO have matching work centers in Epicor before migration.

Total ETO

Non-Conformance Record (NCR)

maps to

Epicor Prophet 21

Non-Conformance (Quality Management)

1:1
Fully supported

Total ETO NCRs reference specific parts, inspections, and quality issues logged from the shop floor, engineering, or procurement. We map NCRs to Epicor's Quality Non-Conformance record type, preserving the part number reference, the disposition (scrap, re-work, use-as-is), and the NCR cause code. The NCR-to-inspection linkage maps to related Non-Conformance records in Epicor Quality. We flag NCR records with unresolved dispositions for the customer's quality team to close post-migration, since Epicor's workflow enforces disposition resolution before closing.

Total ETO

Inspection

maps to

Epicor Prophet 21

Inspection / Quality Detail

1:1
Fully supported

Inspections in Total ETO record quality checks against parts and link to inspectors. We import inspection results as Quality records tied to the relevant Part and Non-Conformance. Inspection type (incoming, in-process, final), measurement data, and pass/fail status map to Epicor's Quality Detail record fields. Inspector names resolve to Epicor Employee records by name or employee number match.

Total ETO

Inventory

maps to

Epicor Prophet 21

PartBin (On-hand quantity)

1:1
Fully supported

Total ETO tracks on-hand quantities by location and linked to projects via reservation. We import inventory quantities, locations, and project reservations into Epicor PartBin records, flagging any negative or over-reserved quantities that would cause inventory discrepancies post-migration. Warehouse and bin locations map to Epicor Warehse and PartBin bin references. Project reservations migrate as JobMtl reserved quantities linked to the corresponding Epicor Job.

Total ETO

Employee

maps to

Epicor Prophet 21

Employee

1:1
Fully supported

Total ETO Employee records include labor class, department, and time-entry data. We map employees to Epicor Employee records, preserving labor class as the Epicor Resource Group or Labor code assignment. Employee status (active, inactive) migrates, and inactive employees are set to the inactive flag in Epicor to prevent time-entry assignment errors post-migration.

Total ETO

Time Entry

maps to

Epicor Prophet 21

Labor Detail (LaborDtl)

1:1
Fully supported

Time entries in Total ETO are project-based with clock-in/clock-out data and geolocation where applicable. We import time logs against the relevant Epicor Job and JobOper using the Employee mapping for labor class resolution. Clock-in/clock-out timestamps map to LaborDtl StartDate, EndDate, and PayHours fields. Any Total ETO time entries without a matching Epicor Job are flagged and held for the customer's project team to resolve, since LaborDtl requires a valid JobNum reference.

Total ETO

Document (file reference)

maps to

Epicor Prophet 21

Document Management (EDMS)

1:1
Fully supported

Total ETO stores documents linked to projects, parts, and quality records. We extract document references and file paths from Total ETO and map them to Epicor Document Management. Actual file migration depends on the destination's document management configuration — if Epicor EDMS is not enabled, we deliver a file mapping inventory listing source paths and recommended destination paths for the customer's IT team to implement post-migration. PDFs of inspection reports and NCR documents migrate as linked attachments to the corresponding Quality records.

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.

Total ETO logo

Total ETO gotchas

High

No public API means migrations are database-centric

High

Dynamic BOM versioning is not a flat list

Medium

Open POs and RFQs require pre-migration cleanup

Medium

Accounting data may live outside Total ETO

Low

Permission over-granularity creates data-integrity risk

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

  • No Total ETO API means database-centric extraction

    Total ETO publishes no REST or SOAP API for third-party data access. All data extraction requires either a direct SQL Server database export (cloud or on-premise) or manual CSV extracts from the application interface. Cloud-hosted Total ETO customers typically need vendor-assisted database access; on-premise customers can provide backup files directly. We assess the hosting model during scoping and factor vendor coordination time into the migration timeline. This fundamentally shapes the extraction approach and requires the customer's Total ETO team to produce or approve database exports before migration begins.

  • BOM revision history must not be collapsed into a flat list

    Total ETO BOMs are multi-level, versioned structures that evolve as engineering change requests propagate during the build phase. Each BOM revision carries a distinct revision date, engineering change description, and component substitution history. Importing these as a single flat BOM in Epicor would destroy the revision context and break downstream production planning. We treat each BOM revision as a distinct Epicor Job BOM, importing them in sequence with revision dates preserved and parent-component relationships maintained. The customer reviews the BOM revision sequence during sandbox validation to confirm the engineering change history is legible at the destination.

  • Open PO import blocked by Part master dependency

    Active purchase orders and RFQs in Total ETO reference live part numbers and vendor commitments. If these are imported before the Part master is established in Epicor, line-item foreign-key references resolve to null and the PO import fails or creates orphaned records. We sequence migration explicitly: Part master first, then Supplier records, then open POs and RFQs. Any PO lines referencing parts not yet migrated are flagged in a pre-migration gap report for the customer's procurement team to reconcile before the PO phase begins.

  • Accounting boundary requires concurrent QuickBooks or Sage reconciliation

    Total ETO integrates with QuickBooks, Sage, or XERO rather than maintaining its own general ledger. Account balances, open AP, and open AR may reside partially or entirely in the connected accounting system rather than in Total ETO. If Epicor ERP is the customer's destination for financials, we scope the accounting boundary explicitly during discovery: which records live in Total ETO, which live in the connected accounting system, and whether AP and AR balances need to be entered as opening balances in Epicor GL or reconciled against the existing accounting tool post-migration. Skipping this boundary definition results in duplicate AP or AR after cutover.

  • Epicor validation rules and required fields can reject imported records

    Epicor enforces data integrity through field-level validation rules, required field enforcement, and picklist whitelists that are absent from Total ETO's database. Parts without valid stocking types, Work Orders without valid job dates, or Employees without valid labor codes will be rejected during import. We profile the destination Epicor configuration during scoping, identify the validation rules that apply to each migrating object, and either temporarily relax them during the migration window or pre-load the required reference data (work centers, labor codes, UOMs) before record import begins.

Migration approach

Six steps for a successful Total ETO to Epicor Prophet 21 data migration

  1. Discovery and hosting model assessment

    We audit Total ETO across hosting model (cloud or on-premise), database size, record volumes per object, BOM revision count, NCR and inspection history, and the connected accounting tool (QuickBooks, Sage, XERO, or ADP). We simultaneously assess the target Epicor Kinetic environment: existing configuration, company structure, installed modules, and the customer's Epicor implementation partner status. The discovery output is a written migration scope that defines the accounting boundary, the BOM versioning strategy, and a phased import order with record-count estimates per phase. If Total ETO is cloud-hosted, we coordinate with Total ETO support to arrange database export access.

  2. Database extraction and data profiling

    For on-premise Total ETO, we receive SQL Server backup files or direct database access and extract tables in dependency order. For cloud-hosted Total ETO, we work with the vendor to produce structured CSV exports or database snapshots. We run data profiling across all extracted tables to identify duplicate part numbers, orphaned records, missing foreign keys, and inconsistent date formats before transformation begins. Data quality issues are documented in a pre-migration report that the customer reviews and resolves or acknowledges before transformation logic is built.

  3. Schema preparation in Epicor

    We configure the Epicor environment before any data loads: Part master with all required Part fields and costing methods, multi-level BOM structures with revision control enabled, Work Center and Labor Code definitions to support Work Order routing, Customer and Supplier hierarchies, Quality module setup with NCR types and disposition codes, and the Employee structure with labor class assignments. If the customer uses Epicor Project for revenue recognition, we configure the Project billing setup before migrating Project records. Epicor schema changes deploy into a Sandbox environment first for validation before production migration.

  4. Sandbox migration and reconciliation

    We run a full migration into Epicor Sandbox using production-like data volumes extracted from Total ETO. The customer's operations and quality teams reconcile record counts and spot-check migrated data against source records. BOM revision history is reviewed to confirm that engineering change context is legible in Epicor. NCR records are validated for disposition status. Any mapping corrections, missing reference data, or schema adjustments are resolved in the Sandbox before production migration begins.

  5. Production migration in dependency order

    We run production migration in strict record-dependency order: Part master (with duplicate resolution), Supplier records, BOM revisions (Job BOMs), Customer records, Employee records, open POs and RFQs, Work Orders with routing, NCRs and Inspections linked to Parts and Work Orders, inventory quantities with location mapping, and time entries linked to Jobs and Employees. Each phase emits a row-count reconciliation report before the next phase begins. Epicor's Bulk API handles large record sets; batch size and rate-limit backoff are managed programmatically to avoid API throttling during high-volume phases.

  6. Cutover, validation, and workflow handoff

    We freeze Total ETO writes during cutover, run a final delta migration of any records modified during the migration window, then enable Epicor as the system of record. We deliver a written inventory of Total ETO workflows, custom reports, and CAD integration points for the customer's Epicor implementation partner or admin team to rebuild. We support a one-week post-cutover window where we resolve reconciliation issues raised by the operations team. We do not rebuild Total ETO workflows or automations as Epicor Business Activity Management rules inside the migration scope; those are a separate engagement or an internal admin task.

Platform deep dives

Context on both ends of the pair

Total ETO logo

Total ETO

Source

Strengths

  • Purpose-built for ETO manufacturing with dynamic BOMs that change throughout the design-build phase.
  • SolidWorks and Autodesk Inventor add-in integration brings BOMs directly into the CAD environment without double entry.
  • Real-time project job costing gives visibility into margin at every stage of a custom machine build.
  • Integrates with QuickBooks and Sage for accounting rather than forcing a full financial-system replacement.
  • Responsive support with hands-on manufacturing experience, including direct involvement from company leadership.

Weaknesses

  • No public API documented — migrations require database exports, CSV extracts, or custom integration work.
  • Windows desktop application with a dated UI that Total ETO itself acknowledges is being redesigned.
  • Excessive flexibility in the permission system means that without careful setup users see controls they do not need.
  • Pricing is opaque — different sources report conflicting figures ($500/user/year, $50/user/month) and the vendor requires a custom quote for anything beyond the 5-seat starter package.
  • Target customers are small-to-mid custom machine builders; the platform lacks the scalability and industry breadth that growing firms need.
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. 3 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 Total ETO and Epicor Prophet 21.

  • Object compatibility

    B

    3 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

    Total ETO: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

Estimate your Total ETO 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 Total ETO to Epicor Prophet 21 data migrations

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

Can't find your answer?

Walk through your Total ETO 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 four and eight weeks for accounts under 15,000 parts, 200 BOMs, and limited NCR history. Migrations with large BOM revision histories, active NCR and inspection records, complex multi-level routing, or concurrent QuickBooks or Sage reconciliation move to ten to eighteen weeks because of BOM-version sequencing, parent-record dependency resolution, and the accounting boundary scoping. Total ETO's cloud hosting model may add time if vendor coordination is required for database access.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Total ETO.
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