ERP migration

Migrate from iCast to Acumatica

Field-level mapping, validation, and rollback between iCast and Acumatica. We move data and schema; workflows are rebuilt natively in Acumatica.

iCast logo

iCast

Source

Acumatica

Destination

Acumatica logo

Compatibility

83%

10 of 12

objects map 1:1 between iCast and Acumatica.

Complexity

CModerate

Timeline

5–10 business days

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

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

iCast logo

iCast

What's pushing teams away

  • Foundry-specific positioning means iCast does not fit other discrete or process manufacturing verticals — companies diversifying beyond foundry operations may need to layer additional ERP modules.
  • Limited public reviewer presence on G2 and Capterra makes peer validation difficult outside the foundry industry.
  • Implementation typically requires vendor services rather than self-serve setup, increasing time-to-value.
  • Mobile and cloud-native UX lag modern SaaS ERPs.
  • No publicly documented developer API restricts integration into MES, IoT, or BI platforms common in modernized foundries.

Choosing

Acumatica logo

Acumatica

What's pulling them in

  • Unlimited user licensing lets companies add staff without per-seat billing shocks, making Acumatica cost-predictable at scale.
  • Flexibility and scalability earn consistent praise — users value a platform that adapts to vertical workflows without forcing a redesign.
  • Real-time visibility across financials, inventory, and projects gives mid-market businesses a consolidated operational view previously available only in enterprise-tier ERPs.
  • Cloud-native architecture with automatic updates removes infrastructure management burden from in-house IT teams.
  • Modular licensing lets companies start with one or two suites (Financials, Distribution) and expand into Manufacturing or CRM incrementally.

Object mapping

How iCast objects map to Acumatica

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

maps to

Acumatica

Customer + Location

many:1
Fully supported

iCast 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

maps to

Acumatica

Vendor + Location

many:1
Fully supported

iCast 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

maps to

Acumatica

Account + Subaccount

1:1
Fully supported

iCast 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

maps to

Acumatica

Non-Stock Item / Stock Item

1:1
Fully supported

iCast 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

maps to

Acumatica

BOM + Material Line

1:1
Fully supported

iCast 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

maps to

Acumatica

Production Order

1:1
Fully supported

iCast 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

maps to

Acumatica

Sales Order

1:1
Fully supported

iCast 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

maps to

Acumatica

Payment / Application

1:1
Fully supported

iCast 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

maps to

Acumatica

Check / Payment

1:1
Fully supported

iCast 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

maps to

Acumatica

Project + Task

1:1
Fully supported

iCast 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

maps to

Acumatica

Quote

1:1
Fully supported

iCast 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

maps to

Acumatica

Note / File Attachment

1:1
Fully supported

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

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.

iCast logo

iCast gotchas

High

No self-service data export mechanism

Medium

Custom fields and reports do not migrate automatically

Medium

Historical data volume complicates migration timelines

Low

Limited third-party integrator ecosystem

Acumatica logo

Acumatica gotchas

High

API user licenses cap concurrent sessions and request throughput

High

Multi-tenant filtering requires CompanyID awareness

Medium

Custom fields require separate discovery before field mapping

Medium

Notes and attachments use a separate linked table structure

Low

Implementation timelines frequently run 3–9 months end-to-end

Pair-specific challenges

  • Chart of accounts sequencing gates all downstream imports

    Acumatica requires accounts to exist before GL transactions can reference them. iCast shops that use a flat account list with implicit ordering often have transactions referencing accounts that do not yet exist in the import file. FlitStack AI resolves the dependency graph before loading, splitting the import into two phases: accounts first, then all GL batches. A circular reference check flags any account that depends on another account that itself has a pending dependency.

  • Inventory item must land before any transaction that references it

    Every SO, PO, invoice, and production order line in Acumatica carries a required InventoryID reference. If the item does not exist in IN202000 at import time, the line fails silently in some import scenarios. We sequence inventory imports before order imports and re-validate the item list against the order file before each batch runs. For manufacturers with thousands of BOM components, this sequencing step alone can take a full planning day.

  • Acumatica Import by Scenario is field-level strict on formats

    iCast allows free-form entry of dates, zip codes, and numeric fields that Acumatica validates. A US zip code like '02141-1234' fails the import if the Location screen's PostalCode field expects exactly 5 digits. We run a pre-validation pass against Acumatica's format rules — extracted from the import scenario metadata — and surface every format violation in a correction spreadsheet before any import runs. For date fields, we convert US mm/dd/yyyy and ISO yyyy-mm-dd to the system's configured format. For numeric fields, we strip currency symbols and thousand separators, ensuring consistent decimal representation.

  • Customer locations require a LocationID — iCast single-address records need a synthetic key

    iCast customers with one address do not always expose a separate location ID. Acumatica's AR303000 requires a Location record with a LocationID that is not null. We generate LocationID='PRIMARY' for every iCast customer that has no explicit location identifier. If multiple addresses exist in iCast, each is split into a separate Location record under the same CustomerID, preserving the address type label as a Location description. During import, we also map the address's country to Acumatica's CountryID field and set the address validation flag to 'None' if the country format does not match Acumatica's built-in validation list.

  • BOM and routing dependencies add iterative import passes

    iCast BOMs reference component items that themselves may have sub-assemblies. Acumatica's BOM screen (AM201020) requires that the output item and all component items already exist as inventory items. For deep BOM trees, we build a topological sort of the item dependency graph and run multiple import passes — items first, then single-level BOMs, then multi-level BOMs — until the full structure is loaded without reference errors. Each pass is logged, and any component still missing after the final pass is flagged in a separate exception report for manual resolution before the next phase begins.

Migration approach

Six steps for a successful iCast to Acumatica data migration

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

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

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

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

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

Context on both ends of the pair

iCast logo

iCast

Source

Strengths

  • Specializes in manufacturing and distribution workflows with job costing and shop floor tracking
  • Provides integrated inventory management and warehouse operations within a single platform
  • Serves multi-entity and multi-location operations under a unified database
  • Offers specialized tools for production planning and supply chain visibility not found in entry-level accounting software
  • Typically positioned at a lower price point than enterprise ERP platforms

Weaknesses

  • Limited customization and reporting flexibility compared to larger ERP systems
  • Constrained scalability with user counts and data storage limits relative to growing organizations
  • Smaller third-party ecosystem and fewer integration options than mainstream ERP vendors
  • Potential concerns about long-term vendor viability and product roadmap direction
  • Support quality and responsiveness reported as inconsistent by some long-term users
Acumatica logo

Acumatica

Destination

Strengths

  • Unlimited named-user licensing eliminates per-seat cost scaling as teams grow.
  • Modular architecture lets companies deploy Financials first and add Distribution, Manufacturing, or CRM incrementally.
  • Cloud-native with automatic updates removes infrastructure patching and version management from IT responsibilities.
  • Flexible customization framework (UDFs, extensions) supports vertical-specific workflows without forking core code.
  • Multi-tenant architecture with CompanyID isolation enables safe data segregation across subsidiaries.

Weaknesses

  • Steep learning curve and complex initial setup create significant onboarding friction.
  • Report Designer is widely cited as unintuitive and difficult to use for non-developers.
  • Feature gaps require customizations or third-party add-ons, adding implementation cost and complexity.
  • Implementation timelines frequently exceed initial estimates, especially for multi-module deployments.
  • API rate limits and concurrent session caps are tied to license tier, creating throughput constraints for bulk data operations.

Complexity grading

How hard is this migration?

Moderate ERP migration. 4 of 8 objects need a mapping; the rest are 1:1.

C

Overall complexity

Moderate migration

Derived from compatibility, mapping clarity, API constraints, and data volume across iCast and Acumatica.

  • Object compatibility

    C

    4 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

    iCast: Not publicly documented..

  • Data volume sensitivity

    B

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

Estimator

Estimate your iCast to Acumatica 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 iCast to Acumatica data migrations

Answers to the questions buyers ask most during iCast to Acumatica migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your iCast to Acumatica migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Small to mid-size manufacturers with under 50,000 records and clean master data typically complete in 5–10 business days. Larger setups with deep BOM hierarchies, 200k+ records, or multi-entity configurations extend to 3–4 weeks. The longest single step is typically chart-of-accounts sequencing and BOM dependency resolution before any data loads. Typical activities include data profiling, account mapping, sample import, and a 24‑48 hour delta capture before go‑live.

Adjacent paths

Related migrations to explore

Ready when you are

Move from iCast.
Land in Acumatica, 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