ERP migration
Field-level mapping, validation, and rollback between iCast and Acumatica. We move data and schema; workflows are rebuilt natively in Acumatica.
iCast
Source
Acumatica
Destination
Compatibility
10 of 12
objects map 1:1 between iCast and Acumatica.
Complexity
CModerate
Timeline
5–10 business days
Overview
iCast stores manufacturing data in an on-premises ERP schema centered on work orders, BOMs, inventory items, and multi-ledger cost tracking. Acumatica exposes a cloud-native REST and SOAP API with import-by-scenario tools and user-defined fields for custom attributes. The migration path requires exporting iCast data via CSV or direct database query, then loading into Acumatica's GL, AR, AP, IN, and SO screens in dependency order — accounts before transactions, inventory before orders, locations before contacts. We preserve original create and update timestamps on every record. Workflows, approval chains, and custom alerts are not migrated; we deliver a workflow-rebuild reference document so your Acumatica admin can reconstruct automation logic in Acumatica's Screen-Based Workflow engine. A sample import of 100–300 records runs first with a field-level diff before the full dataset commits. After the sample validates, we execute the full load, followed by a delta-pickup window of 24–48 hours to capture any iCast activity occurring during cutover. All imports are logged, and a rollback snapshot can revert the target company to its pre‑migration state if reconciliation uncovers issues.
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 iCast object lands in Acumatica, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
iCast
Customer
Acumatica
Customer + Location
many:1iCast customer maps to Acumatica Customer (AR303000) with the primary billing address as LocationID=PRIMARY. If iCast stores separate shipping addresses, each becomes a Location record under the same CustomerID. During import, we also map the customer’s credit limit and tax registration number to the corresponding Acumatica fields, and set the status flag to Active if the iCast record is active. Location-level address validation is performed to match Acumatica's format requirements.
iCast
Vendor
Acumatica
Vendor + Location
many:1iCast vendor maps to Acumatica Vendor (AP303000). The vendor's main address lands as LocationID=PRIMARY. Payment terms and Tax ID on the vendor header map to TermsID and TaxRegistrationID respectively. If the vendor has multiple remittance addresses, each is imported as a separate Location record linked to the same VendorID, preserving the address purpose in the Location description. Vendor class and payment hold status are also transferred.
iCast
GL Account
Acumatica
Account + Subaccount
1:1iCast account number maps to AccountCD; iCast account description maps to AccountDescr. If iCast uses a two-segment code (e.g., 4000-000), the first segment becomes the Acumatica account and the second becomes a SubID subaccount. Active flag, currency, and account type are also transferred to set the correct account class in Acumatica. For accounts without a subaccount segment, a default subaccount (e.g., 000) is created to satisfy Acumatica's required subaccount field.
iCast
Inventory Item
Acumatica
Non-Stock Item / Stock Item
1:1iCast item with Stocked=Y maps to Stock Item (IN202000) with ItemStatus=Active and ValMethod set per iCast cost method. Non-stocked items map to Non-Stock Item with the same screen. During import, we also map the item’s unit of measure, default warehouse, and any user-defined fields. If the iCast item has a BOM, the BOM is imported separately after the item is present in Acumatica.
iCast
Bill of Materials
Acumatica
BOM + Material Line
1:1iCast BOM header maps to BOM (AM201020) with BillStatus=Active. Each BOM component line becomes an AMMatl record referencing the component Stock Item, QtyPer, and OperationsSeq. If the BOM has multiple revisions, the active revision is imported first, and alternate revisions are added as separate BOM versions linked to the same output item. BOM routing information is mapped to AM Operation records for scheduling.
iCast
Work Order
Acumatica
Production Order
1:1iCast work order maps to Production Order (AM201000). Acumatica captures the output item, quantity,物料清单, and operations. Actual labor and machine time entered post-completion maps to labor and machine overhead on the order. If the work order includes a BOM revision, we link the active revision to the production order and set the operation sequence. The work order’s status (Open, Completed, Cancelled) is reflected in the production order’s status field.
iCast
Sales Order
Acumatica
Sales Order
1:1iCast sales order maps to Acumatica Sales Order (SO301000). Header fields (order number, date, customer, terms, warehouse) map directly. Each line maps to SOLine with the inventory item, quantity, and UOM. If the sales order includes discounts, they are transferred as line-level discount codes mapped to Acumatica's discount engine. Tax calculation settings and freight terms are also carried over from the iCast order header.
iCast
Customer Payment
Acumatica
Payment / Application
1:1iCast cash receipts map to Cash Sale or Payment (AR302000). If the receipt references an invoice, it becomes an Application record linking the Payment to the AR Invoice. Payment method, cash account, and currency code are also transferred from iCast to the Acumatica payment record. If the receipt includes a reference number, it is stored in the ExtRefNbr field for reconciliation.
iCast
Vendor Payment
Acumatica
Check / Payment
1:1iCast disbursements map to Checks (AP302000). Payment method, cash account, and vendor location all resolve from the corresponding iCast payment record. If the iCast payment includes a discount taken, the discount amount is recorded as a separate adjustment line in Acumatica. The check date and effective period are set to match the iCast transaction date, and any memo text is preserved in the check’s reference note.
iCast
Project / Job
Acumatica
Project + Task
1:1iCast project records map to Acumatica Project (PM301000). Each phase or cost category in iCast becomes a ProjectTask (PM3010PL). Original project dates and cost budgets are preserved as attributes on the project. If the project includes retainage terms, we map retainage percentages to the project’s billing settings. Project status (Active, Completed, On Hold) is synchronized with the iCast project state.
iCast
Quote
Acumatica
Quote
1:1iCast quotes map to Acumatica Quotes (SO3010PL). Quote status in iCast determines whether the record lands as Draft, Open, or Closed in Acumatica. The quote expiration date and any discount percentages are transferred to the Acumatica quote header. If the quote references a customer location, we link it to the appropriate LocationID in Acumatica.
iCast
Attachment / File
Acumatica
Note / File Attachment
1:1iCast file attachments are extracted and re-uploaded as Note records linked to the parent entity. File size and format are preserved. Inline images in notes are downloaded and re-hosted in Acumatica's file storage. During extraction, we verify the file’s MIME type and ensure it does not exceed Acumatica's 25 MB per‑file limit. Any attachments that cannot be automatically migrated are logged for manual upload.
| iCast | Acumatica | Compatibility | |
|---|---|---|---|
| Customer | Customer + Locationmany:1 | Fully supported | |
| Vendor | Vendor + Locationmany:1 | Fully supported | |
| GL Account | Account + Subaccount1:1 | Fully supported | |
| Inventory Item | Non-Stock Item / Stock Item1:1 | Fully supported | |
| Bill of Materials | BOM + Material Line1:1 | Fully supported | |
| Work Order | Production Order1:1 | Fully supported | |
| Sales Order | Sales Order1:1 | Fully supported | |
| Customer Payment | Payment / Application1:1 | Fully supported | |
| Vendor Payment | Check / Payment1:1 | Fully supported | |
| Project / Job | Project + Task1:1 | Fully supported | |
| Quote | Quote1:1 | Fully supported | |
| Attachment / File | Note / File Attachment1: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.
iCast gotchas
No self-service data export mechanism
Custom fields and reports do not migrate automatically
Historical data volume complicates migration timelines
Limited third-party integrator ecosystem
Acumatica gotchas
API user licenses cap concurrent sessions and request throughput
Multi-tenant filtering requires CompanyID awareness
Custom fields require separate discovery before field mapping
Notes and attachments use a separate linked table structure
Implementation timelines frequently run 3–9 months end-to-end
Pair-specific challenges
Migration approach
Profile and clean source data
FlitStack AI connects to iCast via export CSV or direct database query. We profile the record counts, identify duplicate customer names, inconsistent address formats, inactive items still referenced in open orders, and orphaned GL entries pointing to deleted accounts. A data-quality report goes to your team for remediation before any load begins. The profiling also checks for missing required fields, validates date ranges, and flags any record that exceeds typical size thresholds for attachments or notes.
Map and sequence the chart of accounts
The GL account import is the first data load because every transaction record references at least one account. We generate an account dependency graph from all iCast transaction records, identify any accounts missing from the master list, and create placeholder accounts with a naming convention that flags them for review. Accounts load in sequence order before any journal entry batch imports.
Load master data: inventory, customers, vendors, projects
Master data loads in dependency order: inventory items first, then BOMs, then customers with their location records, then vendors with location records, then projects and tasks. Each entity runs as a separate Acumatica import-by-scenario job. We verify row counts and validation errors between each load before proceeding to the next entity. If a load encounters more than a predefined error threshold, the job pauses and a correction worksheet is generated for your team to resolve before retrying the import.
Run a sample import with field-level diff
A representative slice of 100–300 records — spanning customers, inventory, orders, and a few GL batches — migrates against a test Acumatica company. We generate a field-level diff between the iCast source values and the Acumatica destination values for every mapped field. Your team reviews the diff and signs off before the full dataset commits. The diff report highlights any field where the destination value differs from the source, including trimmed whitespace, case changes, or format conversions, so your team can confirm the transformation logic.
Execute full migration with delta-pickup window
The full dataset loads in sequence order. A delta-pickup window of 24–48 hours after the initial load captures any records created or modified in iCast during the cutover. All operations are logged in an audit trail. One-click rollback reverts the Acumatica company to its pre‑migration snapshot if reconciliation uncovers data integrity issues. During the delta window, any record that appears in iCast but not in the initial load is exported, transformed, and appended to the corresponding Acumatica entity, ensuring a continuous data chain.
Platform deep dives
iCast
Source
Strengths
Weaknesses
Acumatica
Destination
Strengths
Weaknesses
Complexity grading
Moderate ERP migration. 4 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across iCast and Acumatica.
Object compatibility
4 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
iCast: Not publicly documented..
Data volume sensitivity
iCast 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 iCast to Acumatica migration scoping. Not seeing yours? Book a call.
Walk through your iCast to Acumatica migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave iCast
Other ways to arrive at Acumatica
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.