ERP migration
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
Source
Epicor Prophet 21
Destination
Compatibility
8 of 12
objects map 1:1 between Tuhund and Epicor Prophet 21.
Complexity
BStandard
Timeline
6-10 weeks
Overview
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.
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 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
Epicor Prophet 21
Customer
1:1Tuhund 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
Epicor Prophet 21
Customer or Contact
1:1Tuhund 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
Epicor Prophet 21
Quote
1:1Tuhund 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
Epicor Prophet 21
AR Invoice
1:1Tuhund 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
Epicor Prophet 21
Part
1:1Tuhund 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
Epicor Prophet 21
PO Header + PO Release
1:1Tuhund 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
Epicor Prophet 21
Receipt Entry
1:1Tuhund 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
Epicor Prophet 21
Support Case
lossyTuhund 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
Epicor Prophet 21
Job Entry
lossyTuhund 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
Epicor Prophet 21
Expense Entry (AP)
lossyTuhund 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
Epicor Prophet 21
Project
lossyTuhund 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
Epicor Prophet 21
User
1:1Tuhund 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.
| Tuhund | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Company | Customer1:1 | Fully supported | |
| Person | Customer or Contact1:1 | Fully supported | |
| Sales Quotation | Quote1:1 | Fully supported | |
| Commercial Invoice | AR Invoice1:1 | Fully supported | |
| Inventory / Product | Part1:1 | Fully supported | |
| Purchase Order | PO Header + PO Release1:1 | Fully supported | |
| Goods Receipt Note | Receipt Entry1:1 | Fully supported | |
| Service Request | Support Caselossy | Fully supported | |
| Job Card | Job Entrylossy | Fully supported | |
| Expense Claim | Expense Entry (AP)lossy | Fully supported | |
| Project / Task | Projectlossy | Fully supported | |
| User | User1:1 | 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.
Tuhund gotchas
Per-customer module configuration creates schema drift
No publicly documented developer API
Long implementation cycles imply long extraction cycles
Geographic vendor presence affects support cadence
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 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.
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.
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.
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.
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.
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
Tuhund
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 Tuhund 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
Tuhund: Not publicly documented.
Data volume sensitivity
Tuhund 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 Tuhund to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
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 consultationAdjacent paths
Other ways to leave Tuhund
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.