ERP migration

Migrate from Tuhund to Epicor Prophet 21

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

Tuhund logo

Tuhund

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

67%

8 of 12

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

Complexity

BStandard

Timeline

6-10 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Tuhund to Epicor ERP is a structural migration from a single-instance multi-branch Indian mid-market ERP to a manufacturing-first platform built for discrete, make-to-order, and engineer-to-order operations. Tuhund organizes entities (customers, vendors, products, users) across branches and departments with branch-level custom fields that require schema inspection before mapping. Epicor ERP uses a separate Customer and Supplier model for accounts, a dedicated Part and Lot/Serial inventory structure, and UD (user-defined) fields that must be provisioned before transactional imports begin. We resolve the branch-to-company mapping, design the Epicor UD field schema against the Tuhund field inventory, migrate financial documents (quotations, invoices, POs) with their line items intact, and flag the approval workflow and department-scoped logic that does not carry over. Epicor Kinetic's announcement of ending on-premise development in late 2024 makes cloud deployment the primary path for new Epicor implementations.

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

Tuhund logo

Tuhund

What's pushing teams away

  • Significant licensing, maintenance, and implementation cost positions Tuhund toward mid-market and enterprise rather than SMB — small organizations may find total cost of ownership prohibitive.
  • Typical 3-6 month implementation timeline is a meaningful project commitment compared with SaaS-first ERPs that promise faster time-to-value.
  • Limited public reviewer presence on G2 and Capterra makes peer validation difficult, especially for buyers outside ECS's existing customer regions.
  • Custom module deployment on top of the core means vendor services are typically required, increasing dependency on ECS for ongoing changes.
  • Pricing is not published, making early-stage budget conversations difficult without a sales engagement.

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

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

Tuhund

Company

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

Tuhund Company records (B2B) map to Epicor Customer. The Company name becomes Customer.CustID and Customer.Name. Billing and shipping addresses from Tuhund map to CustomerBillTo and CustomerShipTo respectively. Branch associations on Tuhund Companies require resolution: a Tuhund Company scoped to Branch-A may need to become a separate Epicor Customer or a Customer with a site in a specific Plant/Warehouse. We determine this during scoping based on whether the Tuhund branches represent separate legal entities or operational divisions of the same customer.

Tuhund

Person

maps to

Epicor Prophet 21

Customer or Contact

1:1
Fully supported

Tuhund Person records (B2C or individual contacts) map to Epicor Customer if they represent a billing entity, or to Contact records attached to a Customer if they represent an individual within an existing account. The Tuhund person_type property determines whether the record is a standalone customer or a linked contact. Email, phone, and address fields migrate directly; Tuhund's branch association maps to the Contact's Plant or Department reference in Epicor if used.

Tuhund

Sales Quotation

maps to

Epicor Prophet 21

Quote

1:1
Fully supported

Tuhund Sales Quotations map to Epicor Quote. The quotation header (quotation number, date, validity, terms) migrates directly. Line items with product references, quantity, pricing, and discounts map to QuoteLine. We resolve the PartNum reference from Tuhund's product code to Epicor's Part master during the line-item phase. Open/closed quotation status maps to a Quote status flag in Epicor.

Tuhund

Commercial Invoice

maps to

Epicor Prophet 21

AR Invoice

1:1
Fully supported

Tuhund Commercial Invoices map to Epicor AR Invoice (InvcHead and InvcDtl). Invoice number, date, tax amounts, and totals migrate from the Tuhund commercial_invoice endpoint. Line items map to InvcDtl with PartNum resolved to Epicor's Part master. Tax calculation logic in Tuhund is destination-side; we preserve the base amounts, tax rate, and tax jurisdiction code, and flag any invoices where the Tuhund tax calculation may need to be recomputed in Epicor's tax engine.

Tuhund

Inventory / Product

maps to

Epicor Prophet 21

Part

1:1
Fully supported

Tuhund Product records map to Epicor Part. Product code becomes Part.PartNum; description and category map to Part.SearchDescription and Part.PMGClass. Stock levels per Tuhund stock location map to PartWhse records across Epicor sites and warehouses. Lot/Serial tracking in Epicor is enabled per Part; if Tuhund uses lot numbers on inventory transactions, we map them to Epicor's PartLot table. Stock balances are migrated as a static snapshot; we flag to the customer that Epicor will recompute on-hand quantities from transactional history post-migration.

Tuhund

Purchase Order

maps to

Epicor Prophet 21

PO Header + PO Release

1:1
Fully supported

Tuhund Purchase Orders map to Epicor POHeader and POLine. The vendor reference from Tuhund resolves to a Supplier in Epicor. Open and closed PO status migrates with the current approval status preserved in a custom field. POLine items carry PartNum (for stocked parts) or a description-only line (for non-stocked items). Tuhund's GRN (Goods Receipt Note) association is preserved as a reference comment on the POLine since Epicor's receiving process generates its own receipt records.

Tuhund

Goods Receipt Note

maps to

Epicor Prophet 21

Receipt Entry

1:1
Fully supported

Tuhund GRN records map to Epicor Receipt Entry (RcvHead/RcvDtl). The GRN-to-PO linkage in Tuhund resolves to Epicor's PO Receipt reference. Received quantity, unit cost, and warehouse assignment map from the Tuhund goods_receipt API response to RcvDtl. If Tuhund stores inspection status or lot numbers on the GRN, these map to RcvDtl.UserData fields that we configure as part of the UD field provisioning phase.

Tuhund

Service Request

maps to

Epicor Prophet 21

Support Case

lossy
Fully supported

Tuhund Service Requests do not have a direct Epicor equivalent outside of the optional Service Module. If Epicor Service is licensed, Service Requests map to Cases with status mapping (Open to Open, In Progress to In Process, Resolved to Resolved). If Epicor Service is not licensed, we map Service Requests to a custom UD table or to the Cases table via an extension. Warranty information from Tuhund's warranties database migrates to Case fields or UD fields on the Case record.

Tuhund

Job Card

maps to

Epicor Prophet 21

Job Entry

lossy
Fully supported

Tuhund Job Cards map to Epicor Job Entry (JobHead/JobMtl/JobOpr) only if Epicor Manufacturing is licensed. Job card status (Open, In Progress, Closed) maps to JobHead.JobReleased, JobHead.JobComplete, and JobHead.JobClose. Tuhund's linking of job cards to service requests maps to Epicor's LinkToContract/LinkToCase fields if the Service Module is active. If Epicor Manufacturing is not in scope, Job Card data is migrated to a custom UD table with a written schema definition for the customer's admin.

Tuhund

Expense Claim

maps to

Epicor Prophet 21

Expense Entry (AP)

lossy
Fully supported

Tuhund Expense Claims map to Epicor's AP Expense Entry or to a custom UD table depending on whether the Epicor Financials module handles per-diem and receipt-based expenses. Expense line items (amount, category, currency) migrate to expense detail records. Approval status from Tuhund migrates as a read-only field; the actual approval workflow is Epicor BPM-driven and must be rebuilt. Tuhund's department-scoped approval rules are documented in the workflow inventory for the customer's admin.

Tuhund

Project / Task

maps to

Epicor Prophet 21

Project

lossy
Fully supported

Tuhund Project records map to Epicor Project if the Project Management module is licensed. Task hierarchies, assignees, milestones, and due dates migrate to ProjectPhase and ProjectTask. If Epicor Project is not licensed, Project data migrates to a custom UD table. Tuhund's custom fields at project level require schema inspection before import; these map to UD fields on the Epicor Project record that we provision during the UD field scoping phase.

Tuhund

User

maps to

Epicor Prophet 21

User

1:1
Fully supported

Tuhund User records map to Epicor User by email address match. Branch and department associations on Tuhund users map to Epicor Plant and Department references, or to UD fields if the organizational structure is more complex. Any Tuhund user without a matching Epicor User is held in a reconciliation queue; the customer's Epicor admin provisions the User in Epicor before record migration proceeds. Role and permission mappings are destination-dependent and documented as a written role map for the customer's admin.

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.

Tuhund logo

Tuhund gotchas

High

Per-customer module configuration creates schema drift

High

No publicly documented developer API

Medium

Long implementation cycles imply long extraction cycles

Low

Geographic vendor presence affects support cadence

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

  • Tuhund branch-to-Epicor company/site mapping is non-trivial

    Tuhund's multi-branch architecture allows the same customer, product, or user to exist with different configurations per branch. Epicor ERP uses a Company-Plant-Warehouse hierarchy that does not have a direct branch equivalent. We must determine during scoping whether each Tuhund branch maps to a separate Epicor Company (different legal entity), a separate Epicor Plant within the same Company (same legal entity, different operating division), or a warehouse within a Plant. This decision affects tax configuration, currency, reporting, and user access. Branch-level custom fields in Tuhund add complexity because their values may be branch-specific in ways that do not translate directly to Epicor's UD field model.

  • Epicor UD fields require provisioning before transactional import

    Epicor's user-defined (UD) field model (ZDataFields on UD tables, or extended UD fields on standard tables) requires pre-provisioning in the Epicor schema before any data referencing those fields can be imported. Tuhund's custom fields at branch and department level are not mapped in a publicly documented schema, so we inspect the field inventory during discovery and provision corresponding Epicor UD fields before the migration run. Epicor's own community forum (epiusers.help) documents multiple cases where missing UD field provisioning causes Business Layer exceptions during data load. We configure UD fields via Epicor's ZDataTable BO or via the customization tools in Epicor Kinetic before any import phase begins.

  • Tuhund approval workflows do not migrate to Epicor BPM

    Tuhund workflows and approval chains scoped to departments (expense claim approvals, PO approval hierarchies, document sign-offs) are not transferable to Epicor's Business Process Management system. Epicor BPM uses event-driven triggers and directives that are configured within the Epicor environment, not imported from external data. We document every active Tuhund workflow and approval chain in a written inventory that the customer's Epicor admin or implementation partner uses to rebuild in Epicor BPM. The approval status on migrated records (Approved, Rejected, Pending) is preserved as a read-only field, but the workflow engine itself restarts in Epicor.

  • Financial document conversion requires Epicor validation testing

    Epicor community documentation and Spiceworks forums document cases where financial data (invoices, POs, credit memos) was not converted correctly during upgrades and migrations, requiring retroactive corrections. We mitigate this by migrating all financial documents in a Epicor Sandbox first, validating totals, tax amounts, and line-item calculations against the Tuhund source before production import. Any discrepancies in tax computation are flagged because Epicor's tax engine may calculate GST/VAT differently from Tuhund's implementation.

  • Epicor on-premise development has ended; cloud-first path applies

    Epicor's late-2024 announcement ended on-premise development for Kinetic, Prophet 21, and BisTrack. New Epicor implementations default to Epicor Kinetic Cloud. Companies migrating from Tuhund to Epicor on-premise should be aware that they are adopting a product with a cloud-only forward roadmap. We confirm the deployment intent during scoping and adjust the migration target accordingly. Cloud deployments use Epicor's REST API and Data Fabric for integration; on-premise deployments can use direct SQL or the Epicor REST API with local network routing.

Migration approach

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

  1. Discovery and API schema inspection

    We audit the Tuhund environment across all active modules: Companies, Persons, Products, Stock Locations, Sales Quotations, Commercial Invoices, Purchase Orders, GRNs, Service Requests, Job Cards, Expense Claims, Projects, and Users. Because Tuhund's API schema is not publicly documented, we execute field-level inspection against each entity's list and detail endpoints to build the migration field inventory. We confirm the branch structure, the number of distinct branches in scope, and which branches represent separate legal entities versus operational divisions. The discovery output is a written migration scope document and a Tuhund field-to-Epicor field mapping draft.

  2. Epicor organizational design and UD field provisioning

    We design the Epicor organizational structure to receive the Tuhund data. This includes deciding the Company-Plant-Warehouse hierarchy mapping for each Tuhund branch, provisioning UD fields on the relevant Epicor tables (Part, Customer, POHeader, RcvHead, JobHead, Project) to capture Tuhund branch and department associations, configuring the Part master with the appropriate site assignments, and setting up the Supplier records for PO migration. If Epicor Manufacturing or Service modules are in scope, we configure the Job Entry and Case schemas before transactional data is imported. All design work is deployed into a Epicor Sandbox for validation before production.

  3. Sandbox migration and data reconciliation

    We run a full migration into a Epicor Sandbox using production-like data volume. The customer's operations lead reconciles record counts (Customers in, Suppliers in, Parts in, POs in, Quotes in, Invoices in, Service Requests in, Job Cards in) against the Tuhund source system. We spot-check 30-50 random records for field-level accuracy, validate that UD fields populated correctly, and confirm that totals on financial documents match. Any mapping corrections are made before production migration begins. Epicor's Data Validation business object is used to run post-import validation queries against the Sandbox.

  4. Financial foundation and account resolution

    We migrate the financial foundation records first: Suppliers (from Tuhund vendor records), Customers (from Tuhund Companies and Persons), and the Part master (from Tuhund Products). Each record's Tuhund branch association is resolved to the correct Epicor Plant or Site. Epicor requires Suppliers to exist before POs can be imported and Customers to exist before AR Invoices can be imported, so this phase is a hard dependency gate. Any Tuhund customer or vendor that cannot be resolved to a unique Epicor account goes to a reconciliation queue for the customer's admin to resolve.

  5. Transactional migration in dependency order

    We run production migration in record-dependency order: Parts (with PartWhse stock locations), Suppliers, Customers, Purchase Orders (with POLine items), GRN records (linked to POs), Sales Quotations, Commercial Invoices, Service Requests (mapped to Cases or UD tables), Job Cards (mapped to Jobs or UD tables), Expense Claims, Projects with tasks, and User records. Each phase emits a row-count reconciliation report before the next phase begins. Epicor's Bulk API or REST endpoints are used with batch chunking, rate-limit handling, and exponential backoff. UD field values are populated after the base record is inserted.

  6. Cutover, validation, and workflow rebuild handoff

    We freeze writes to Tuhund during the cutover window, run a final delta migration of any records modified during the migration period, then mark Epicor as the system of record. We deliver the Tuhund workflow and approval chain inventory document to the customer's Epicor admin or implementation partner for BPM rebuild. We run a final post-migration validation in Epicor (total record counts, financial document totals, stock balance reconciliation) and support a one-week hypercare window. We do not rebuild Tuhund workflows as Epicor BPMs inside the migration scope; that is a separate engagement or an internal Epicor configuration task.

Platform deep dives

Context on both ends of the pair

Tuhund logo

Tuhund

Source

Strengths

  • Broad module footprint (finance, inventory, supply chain, manufacturing, PM, CRM, HRM, analytics) on a single core.
  • Core platform includes meaningful functionality out of the box.
  • Cloud and on-premise deployment for regulated and data-residency-sensitive customers.
  • Multi-region vendor presence (US, Canada, UK, Australia, India).
  • Subscription licensing that scales users and modules over time.

Weaknesses

  • High total cost of ownership positions Tuhund away from SMB.
  • 3-6 month implementation timelines.
  • Limited public reviewer presence.
  • No public developer API — integrations require vendor services.
  • Pricing not published, slowing early-stage evaluation.
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 Tuhund 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

    Tuhund: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

Walk through your Tuhund 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 six and ten weeks for environments with under 5,000 customer records, 2,000 products, and no manufacturing module equivalents. Migrations with multi-branch Tuhund configurations (each branch becoming a separate Epicor Company or Plant), large AP/AR invoice histories, custom field-heavy departments, or Epicor Manufacturing and Service module scope move to fourteen to twenty-two weeks because of UD field provisioning, organizational design work, and Epicor data validation testing.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Tuhund.
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