ERP migration

Migrate from JTL-Wawi to Acumatica

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

JTL-Wawi logo

JTL-Wawi

Source

Acumatica

Destination

Acumatica logo

Compatibility

92%

11 of 12

objects map 1:1 between JTL-Wawi and Acumatica.

Complexity

BStandard

Timeline

7–14 days

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

JTL-Wawi is a merchandise-management system (Warenwirtschaftssystem) purpose-built for German-speaking e-commerce operators — it manages items with marketplace-specific connectors to eBay, Amazon, Otto, and Kaufland via JTL-eazyAuction, plus internal order and inventory workflows. Acumatica is a cloud ERP with a multi-entity, module-based architecture covering Financial Management, Inventory and Order Management, CRM, and Project Accounting. The migration carries all standard JTL objects — items, customers, companies, orders, purchase orders, delivery notes, invoices, and stock quantities — into Acumatica's DAC-based schema. The primary structural challenges are mapping JTL's flat product-attribute JSON blobs into Acumatica's attributes system, resolving JTL's single-warehouse-per-installation model against Acumatica's multi-warehouse structure, and handling JTL's internal order-number sequences in Acumatica's document reference fields. Workflows, label templates, shipping configurations, and JTL-Connectors have no direct Acumatica equivalents — FlitStack exports their definitions as a rebuild reference for your Acumatica administrator. We extract data via JTL's export APIs (JTL-DataTransfer CSV and direct database access), transform and validate against Acumatica's schema constraints, then load through Acumatica's import framework with a field-level diff before committing the full run.

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

JTL-Wawi logo

JTL-Wawi

What's pushing teams away

  • Support costs escalate significantly when issues require Bronze or Silver tier assistance, and the tariff model means simple questions can become billable support tickets.
  • English documentation remains incomplete with many pages still showing German screenshots and links, creating friction for non-German-speaking administrators.
  • Cloud hosting was discontinued by JTL, forcing customers to either self-host on-premises or find third-party RDP providers, disrupting existing deployment patterns.
  • Customer satisfaction scores are modest (G2 3.8, Trustpilot 2.4) with reviewers citing feature gaps and support responsiveness as recurring frustrations.

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 JTL-Wawi objects map to Acumatica

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

JTL-Wawi

Artikel (Item)

maps to

Acumatica

InventoryItem (Stock Item) + Non-Stock Item

1:1
Fully supported

JTL items map directly to Acumatica StockItem (for physical goods held in inventory) or NonStockItem (for dropship or service items). We preserve the JTL item internal ID as RefNbr for traceability. Items flagged as 'Stücklist' (bill of materials) in JTL require Acumatica's BOM module to be enabled and configured by your Acumatica admin before migration runs.

JTL-Wawi

Artikel.Eigenschaften (Item Attributes JSON)

maps to

Acumatica

CSAttribute + InventoryItem row

1:1
Fully supported

JTL stores item attributes as a JSON column (Eigenschaften) per article containing key-value pairs like {color: red, size: XL, material: cotton}. We parse this JSON and create one Acumatica CSAttributeGroup entry per JTL attribute group, then link each parsed attribute to the corresponding InventoryItem row. Attributes with pick-list values in JTL become CSAttributeDefinition entries with predefined options in Acumatica.

JTL-Wawi

Kunde (Customer)

maps to

Acumatica

BQLocation + Contact

many:1
Fully supported

JTL customer records contain both person-level and company-level data in a single record. We split this into Acumatica's BusinessAccount (company information, TaxRegistration IDs) as the parent and Contact (first name, last name, email, phone) as the child. JTL's delivery addresses become additional BQLocation records on the BusinessAccount with the IsDefaultBilling and IsDefaultShipping flags set per JTL address type.

JTL-Wawi

Firma (Company/JTL)

maps to

Acumatica

BusinessAccount

1:1
Fully supported

JTL's Firmen table (company-level records used when JTL customer is a business entity) maps directly to Acumatica BusinessAccount with the AccountType = 'Customer' or 'Vendor' set based on JTL's firm type flag. Tax registration numbers from JTL's Steuernummer field migrate to the TaxRegistration collection on BusinessAccount.

JTL-Wawi

Auftrag (Sales Order)

maps to

Acumatica

SOOrder + SOLine

1:1
Fully supported

JTL sales orders (Auftrag) migrate as Acumatica SOOrder records with the status mapped based on JTL's order status: 'Offen' (open) → SOOrderStatus.Open, 'Bezahlt' (paid) → SOOrderStatus.Completed, 'Storniert' → SOOrderStatus.Cancelled. Order lines map to SOLine with InventoryID resolved from the JTL article reference. JTL's internal order number is stored as an extended field (UsrJTLOrderNbr__) for reconciliation.

JTL-Wawi

Lieferschein (Delivery Note)

maps to

Acumatica

SOShipment

1:1
Fully supported

JTL delivery notes (Lieferschein) created from shipped orders map to Acumatica SOShipment records. The shipment links to the corresponding SOOrder via the OrderNbr field. Carrier and tracking information from JTL's Versanddienstleister field migrates to SOShipment.ShipVia and SOShipment.TrackingNumber respectively. Multiple Lieferschein for a single Auftrag in JTL create multiple SOShipment records in Acumatica.

JTL-Wawi

Rechnung (Invoice / AR Invoice)

maps to

Acumatica

ARInvoice

1:1
Fully supported

JTL invoices (Ausgangsrechnung) migrate to Acumatica ARInvoice. Tax amounts from JTL's MwSt (VAT) breakdown are preserved in ARTran tax fields. JTL's payment status (Zahlstatus) maps to ARInvoice.Status: unpaid → ARInvoiceStatus.Open, paid → ARInvoiceStatus.Closed. Where JTL tracks partial payments, we create multiple ARPayment records linked to the ARInvoice.

JTL-Wawi

Bestellung (Purchase Order)

maps to

Acumatica

POOrder + POLine

1:1
Fully supported

JTL purchase orders (Bestellung) migrate to Acumatica POOrder. Supplier resolution happens by matching JTL's Lieferant reference against the BusinessAccount.VendorClass and VendorLocation setup. POOrder status follows the same mapping logic as sales orders. Expected delivery dates from JTL's Lieferdatum migrate to POOrder.PromisedDate on POLine.

JTL-Wawi

Wareneingang (Goods Receipt)

maps to

Acumatica

APInvoice + POReceipt

1:1
Fully supported

JTL goods receipts (Wareneingang) linked to a purchase order migrate as Acumatica POReceipt to update inventory quantities. If a JTL Wareneingang also triggers an invoice, both POReceipt and APInvoice are created with the APInvoice linked to the POReceipt via the ReceiptNbr field. Standalone Wareneingang records without a PO order are imported as POReceipt only.

JTL-Wawi

Warenbestand (Inventory Quantity)

maps to

Acumatica

INSiteStatus + INLocationStatus

1:1
Fully supported

JTL inventory quantities per warehouse are mapped to Acumatica's INSiteStatus (total on-hand per site) and INLocationStatus (bin-level breakdown if JTL uses Lagerplätze). If JTL has a single warehouse and Acumatica has multiple sites defined, we prompt for a site-mapping rule — by default all stock lands in the Acumatica default site (WHOLESALE or the site designated as default).

JTL-Wawi

Anschrift (Address)

maps to

Acumatica

Address + BQLocation

1:1
Fully supported

JTL address records (Anschrift) with type flags (Rechnungsadresse, Lieferadresse) migrate to Acumatica Address records attached to BQLocation. Full street, city, postal code, and country are mapped field-by-field. JTL's Zustelladresse (special delivery instructions) is appended to the Address.AddressLine2 field in Acumatica for visibility.

JTL-Wawi

Bild(er) (Item Images)

maps to

Acumatica

UploadFile + NoteDoc (attachment on InventoryItem)

1:1
Fully supported

JTL item images are stored as URLs or local file paths referencing the JTL database's Bilder table. We re-download and re-upload these as Acumatica UploadFile records, then attach them to the corresponding InventoryItem via NoteDoc. Image ordering (primary image, gallery order) from JTL is preserved as NoteDoc NoteID order in Acumatica.

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.

JTL-Wawi logo

JTL-Wawi gotchas

Medium

SCX API per-endpoint rate limits return HTTP 429

High

UNC paths required for all file-based imports and exports

High

JTL Cloud hosting discontinued forces third-party RDP reliance

Low

Incomplete English documentation with untranslated content

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

  • JTL item attribute JSON requires parsing before Acumatica attribute linking

    JTL-Wawi stores item attributes (color, size, material, etc.) as a serialized JSON column (Eigenschaften) on the article record. Acumatica has no native equivalent to a JSON blob — attributes must be defined individually within the CSAttribute framework and linked to InventoryItem rows via attribute groups. We parse the JTL JSON, extract each key-value pair, create the corresponding CSAttributeDefinition and CSAttributeGroup entries, then link the parsed attributes to the inventory item. If a JTL attribute uses free-text values (not a pick-list), it becomes a free-text CSAttribute in Acumatica. This step requires a pre-migration attribute-mapping plan and Acumatica admin access to create the attribute definitions before the migration runs.

  • JTL's single-warehouse inventory model creates site-split decisions in Acumatica

    JTL-Wawi in its base configuration manages one primary warehouse per installation — inventory quantities are stored without an explicit multi-warehouse schema. Acumatica's inventory model is site-centric: each INSite (warehouse) holds its own on-hand quantities, and transferring stock between sites creates INTransfer records. When migrating to an Acumatica instance with multiple sites already defined (e.g., a hub warehouse and a fulfillment center), we require a site-mapping rule before inventory lands: all JTL stock to the default site, or a distribution rule based on JTL's internal warehouse assignment fields if they were used. Without this rule, inventory may land in the wrong site and trigger incorrect reorder points.

  • JTL order-number sequence does not auto-continue in Acumatica document numbering

    JTL-Wawi maintains its own sequential order-number counter (Auftragsnummer) starting from your first order. Acumatica uses a separate numbering sequence per document type (SOOrder, POOrder, ARInvoice) with configurable prefix and start number. We preserve the JTL order number as SOOrder.CustomerOrderNbr and a custom UsrJTLOrderNbr__c field for cross-reference, but Acumatica's internal RefNbr will use its own numbering from the configured sequence. You must set the starting number for Acumatica's SOOrder numbering sequence before migration so it does not clash with existing JTL numbers if you plan to keep both systems running in parallel during cutover.

  • JTL workflows and JTL-Connectors have no Acumatica equivalent and must be rebuilt

    JTL-Wawi ships with a workflow engine (JTL-Workflows) that automates triggers such as order-creation events, payment-status changes, and shipping-label printing. JTL-Connectors (JTL-eazyAuction for eBay and Amazon, JTL-Connector for Shopware and WooCommerce) maintain live channel synchronization. Neither of these has a built-in Acumatica equivalent — workflows map to Acumatica's Generic Inquiries + Business Events or customizations, and marketplace connectors must be sourced from Acumatica's Marketplace or built as custom integrations. We export your JTL workflow definitions as text descriptions and a rebuild reference document. The channel connectors require a separate evaluation of Acumatica Marketplace apps (e.g., Channable, TradeCentric) or a custom integration build.

  • JTL item images are stored as URLs or local paths — re-hosting required in Acumatica

    JTL-Wawi stores item images either as URLs pointing to a JTL-hosted CDN or as file paths on the JTL server's local disk. Acumatica's file management uses the UploadFile table with a GUID-based reference. We re-download images from JTL URLs or extract them from the JTL database BLOB storage and re-upload them to Acumatica's file repository, attaching each to the corresponding InventoryItem via NoteDoc. Image filenames and ordering from JTL's Bilder table are preserved in the NoteDoc.NoteText or as a custom sort-order field. If JTL images are hosted behind Windows-only file shares (DFS paths), extraction requires a Windows server with network access to the JTL file share during migration.

Migration approach

Six steps for a successful JTL-Wawi to Acumatica data migration

  1. Extract and profile JTL-Wawi data via JTL-DataTransfer and direct database access

    We begin by running JTL-DataTransfer exports for items, customers, orders, purchase orders, and inventory — generating CSV extracts following JTL's documented export schema. For records with complex structures (attributes as JSON, multi-line order positions), we supplement with direct SQL queries against the JTL database (MS SQL Server or MySQL, depending on your JTL installation). We profile the data for duplicates, missing required fields, and encoding issues. The profiling report identifies items without SKUs, customers without email addresses, and orders with orphaned positions — each resolved against your JTL admin before mapping begins.

  2. Build JTL-to-Acumatica attribute and site mapping plan

    Based on the profiling results, we build an attribute-mapping plan: each JTL attribute key from the JSON column becomes a CSAttributeDefinition in Acumatica (with attribute group and type — free-text, combo, or multi-value). Simultaneously, we build the warehouse-to-site mapping: each JTL Lager (warehouse) ID is assigned to an Acumatica INSite. If your Acumatica instance has multiple sites already configured (central warehouse, fulfillment center), the mapping is applied during inventory load. This plan is reviewed with your Acumatica admin before any import runs. We also define the Acumatica document numbering sequence start numbers to avoid collision with JTL order numbers retained in CustomerOrderNbr.

  3. Run sample migration of items, customers, and orders with field-level diff

    A representative slice migrates first — typically 200–500 items spanning multiple attribute groups, 100–300 customer records including multi-address companies, and 50–100 orders across all statuses. We generate a field-level diff showing source JTL values against the Acumatica destination fields for each record. You verify: attribute parsing completeness from JSON, address-split correctness on company vs. individual customers, order-status mapping accuracy, and inventory quantity totals matching JTL's Lagerbestand report. Discrepancies are resolved in the mapping plan before the full migration proceeds.

  4. Execute full migration with ordered entity load and delta-pickup window

    The full migration runs in dependency order: inventory items first (to resolve InventoryID on all transaction lines), then customers and suppliers (to resolve VendorID and CustomerID on orders), then purchase orders, then sales orders with their shipment and invoice links. A 24–48 hour delta-pickup window captures any new or modified records in JTL during the cutover. All operations are logged to an audit table with timestamps, user references, and the Acumatica record ID created. After delta-pickup, we run a reconciliation report comparing JTL record counts and total order value against Acumatica totals. One-click rollback reverts all migration records if reconciliation fails your acceptance criteria.

  5. Deliver reconciliation report and JTL workflow export reference document

    The final deliverable is a reconciliation report: line-by-line count of migrated vs. source records per entity (items, customers, orders, inventory), plus a financial totals check comparing JTL's Gesamtwert (total order value) against Acumatica's SOOrder.OrderTotal sum. We also deliver the JTL-Workflow export as a structured PDF: every workflow trigger, condition, and action from JTL-Wawi's workflow list, formatted as a rebuild guide for your Acumatica admin. Label templates, shipping configurations, and JTL-Connector definitions are exported separately as configuration reference files for your Acumatica implementation partner.

Platform deep dives

Context on both ends of the pair

JTL-Wawi logo

JTL-Wawi

Source

Strengths

  • Integrated multi-channel selling across eBay, Amazon, and custom storefronts via JTL-Connector ecosystem.
  • Automated workflow engine (JTL-Workflows) reduces manual tasks using event-driven process chains.
  • JTL-Ameise provides CSV-based import/export for all core business objects without requiring API access.
  • Active German e-commerce partner network with certified service partners and 72,000-post community forum.
  • RDP-based hosting option eliminates on-premises Windows server maintenance for small teams.

Weaknesses

  • English documentation is incomplete with German-language screenshots persisting even on translated pages.
  • Support model transitioned to paid tiers, making basic issues potentially billable under Bronze or Silver plans.
  • No standalone cloud offering from JTL itself forces customers to third-party RDP providers.
  • Modest review scores (G2 3.8, Trustpilot 2.4) reflect ongoing customer satisfaction concerns.
  • JTL-Connector ecosystem is tightly coupled to JTL-Wawi, making cross-platform migrations more complex.
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?

Standard ERP migration. 1 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 JTL-Wawi and Acumatica.

  • Object compatibility

    B

    1 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

    JTL-Wawi: Per-endpoint rate limits enforced; HTTP 429 returned on exceed (specific limits not publicly documented).

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Most JTL-Wawi to Acumatica migrations complete in 7–14 days for setups under 100,000 records. Larger migrations with 500,000+ records, multi-warehouse inventory splits, or JTL attribute JSON parsing across 1,000+ attribute groups extend to 3–6 weeks. The longest phase is typically the attribute-mapping planning step, where JTL's JSON attribute blobs need to be mapped to Acumatica's formal CSAttribute definitions before any item data can land cleanly.

Adjacent paths

Related migrations to explore

Ready when you are

Move from JTL-Wawi.
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