--- title: "SYSPRO to Epicor Kinetic Migration: A Technical Guide" slug: syspro-to-epicor-kinetic-migration-technical-guide date: 2026-10-26 author: Abdul Aleem categories: [Migration Guide, SYSPRO, Epicor Kinetic] excerpt: "Technical guide for migrating data from SYSPRO to Epicor Kinetic — covering extraction methods, entity mapping, load sequencing, and the 2026 licence deadline." tldr: "Migrating SYSPRO to Epicor Kinetic requires direct SQL extraction including the plus tables, field-level mapping of every entity, and loading through Epicor's supported tools in strict dependency order." canonical: https://clonepartner.com/blog/syspro-to-epicor-kinetic-migration-technical-guide --- # SYSPRO to Epicor Kinetic Migration: A Technical Guide # SYSPRO to Epicor Kinetic Migration: A Technical Guide Migrating from SYSPRO to Epicor Kinetic is a structural data translation between two manufacturing ERPs with different schema conventions. SYSPRO uses module-prefixed SQL Server tables (`ArCustomer`, `InvMaster`, `SorMaster`) organized into per-company databases. Epicor Kinetic validates every incoming record through its own business logic, and you load data through Epicor's supported import tools. Both systems serve manufacturers, but they differ on BOM revisions, shop floor execution, and how custom fields are stored — and those differences are where migrations break. If you attempt a direct table-to-table copy without respecting Epicor's business logic, the migration will fail on import or leave bad data in production. This guide covers SYSPRO extraction methods, loading into Epicor Kinetic, entity-level mapping, the 2026 licensing deadline driving many of these projects, and the edge cases that decide whether your go-live succeeds or stalls. Extraction patterns apply to SYSPRO 8. For the pair-specific scope, see our [SYSPRO to Epicor Kinetic migration](https://clonepartner.com/blog/migrate/syspro-to-epicor-kinetic) page. If you are still choosing a target, read [SYSPRO vs Epicor Kinetic: 2026 Comparison](https://clonepartner.com/blog/blog/syspro-vs-epicor-kinetic-2026-comparison) first. For a deeper look at data-layer risks common to all ERP transitions, see [Why ERP Migrations Fail at the Data Layer: 9 Core Patterns](https://clonepartner.com/blog/blog/why-erp-migrations-fail-at-the-data-layer-9-core-patterns). ## Why Are Companies Migrating from SYSPRO to Epicor Kinetic? Three forces are pushing SYSPRO customers toward Epicor Kinetic: **SYSPRO's 2026 licensing change.** SYSPRO is ending its Initial and Annual Licence Fee model. Going forward, SYSPRO is available only under a named-user subscription ([syspro.com](https://www.syspro.com/formal-notice-change-to-syspro-licensing/)). Existing licences expire on **31 October 2026** for customers outside the US, and **31 December 2026** for US customers, so the change applies from 1 November 2026 or 1 January 2027, depending on your expiry date. After expiry, SYSPRO's formal notice states that "you will no longer be able to access Syspro" without a new subscription agreement. Customers who decide to leave rather than subscribe have a data export right — the notice says "on cessation of your current licence, you have the right to export your data" ([syspro.com](https://www.syspro.com/formal-notice-change-to-syspro-licensing/)). For what each date means in practice, see [SYSPRO Licence Change 2026: The Deadlines Explained](https://clonepartner.com/blog/blog/syspro-licence-change-2026-deadlines-explained). **Manufacturing fit.** Some SYSPRO manufacturers find that Epicor Kinetic's scheduling, shop floor and quality features fit how they want to run production. Test that against your own processes with Epicor or its partners before you commit. **A forced decision point.** The licence change makes every SYSPRO customer choose between subscribing and moving. Those who move often re-run a full ERP selection, and Epicor Kinetic is one of the usual shortlist options. > [!WARNING] > **Two clocks.** The data migration — extracting from SYSPRO, transforming, loading into Kinetic — takes days, not months. Most data migrations complete within 1–5 business days, depending on data volume, complexity and API rate limits, and datasets under 10,000 records can finish in under 24 hours. The broader ERP implementation project — configuring Epicor Kinetic, rebuilding workflows, training users — is a separate effort measured in months, handled by Epicor or an Epicor implementation partner. Don't confuse the two timelines. ## How Do You Get Data Out of SYSPRO? SYSPRO 8 stores data in Microsoft SQL Server, with each company's data in a dedicated database plus a single system-wide database ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). You have several extraction paths: - **Direct SQL Server access** — the route we recommend first. You can read every table, including the plus tables that hold custom form data (e.g., `[ArCustomer+]`). A read-only SQL login on the company database is enough. - **Business Activity Queries (BAQs)** — "SQL views that are created in the relevant company databases", readable by "any SQL user with db_datareader permissions" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/2022-release/topics/syspro-8-business-activity-queries-reference-guide.pdf)). Useful as pre-built views, but they add nothing direct SQL cannot read. - **SYSPRO OData Service** — read-only access without direct SQL. SYSPRO notes it is "the only mechanism available when applications need access to SYSPRO data in the Syspro Cloud ERP environment" ([help.syspro.com](https://help.syspro.com/syspro-8-2025/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)). Use it where direct SQL is not possible. SYSPRO limits it "to 5000 rows" per call, with paging through `$top` and `$skip` ([help.syspro.com](https://help.syspro.com/syspro-8-2021-r2/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)). - **e.net business objects** — query objects like `ARSQRY` (Customer Query), `INVQRY` (Inventory Query), and `SORQRY` (SO Sales Order Query) return XML for individual records or filtered sets ([help.syspro.com](https://help.syspro.com/business-object-library/G_Objects/ars/arsqry/arsqry.htm)). SYSPRO documents that archived sales orders cannot be queried via `SORQRY`. These are designed for integration, not bulk extraction. - **Report Writer** — can send output to ASCII files, and data "can also be exported to third party software such as spreadsheets" ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/_repovr.htm)). A last-resort fallback for specific datasets. For bulk migrations, direct SQL extraction is almost always the right call because it reads both standard tables and the plus tables where custom form data lives. > [!NOTE] > **On SYSPRO 7 or earlier?** Verify table structures against your own database before applying the mappings in this guide. Before SYSPRO 7, custom form data was held in a single table, `AdmFormData`, rather than in per-table plus tables ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm)). > [!NOTE] > **Custom form data lives in plus tables.** SYSPRO's database guide says custom form data for `ArCustomer` "is stored in a table named 'ArCustomer+'" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). These are easy to miss during extraction scoping. Query `INFORMATION_SCHEMA.TABLES` in the SYSPRO company database and filter for table names ending in `+` to list every plus table before you finalize scope. ## How Do You Load Data into Epicor Kinetic? Epicor offers its own import tools. Load through them, so that Epicor's business logic validates every record. We could not read Epicor's own documentation for this guide, so we do not state product limits here. Confirm templates, row limits, authentication and licensing with Epicor or your Epicor partner. ### Epicor DMT **DMT** is Epicor's import tool for loading data from files during implementations. **When to use it:** Bulk loads of master data — parts, customers, suppliers, chart of accounts — where Epicor's validation catches mapping errors before production. **What to plan for:** DMT reads staged files, so you extract and transform first, then load. Ask your Epicor partner which entities have templates in your release, how DMT reports errors, and how long a full load runs on your environment. Time it during sample migrations. ### Epicor Kinetic REST API The **Kinetic REST API** is the route for programmatic loading. **When to use it:** API-based loading gives you control over sequencing, error handling, and retry logic. It's the better path for delta syncs and for multi-entity loads with referential integrity checks between steps. **What to plan for:** - **Paging and limits.** Confirm the row and request limits for your release and hosting with your Epicor partner, then page every query. - **Integration account.** Confirm how the account your load scripts use is licensed before you run bulk loads. - **Error handling.** Check both the HTTP status and the response body of every call. Log every rejected record with its reason. - **Backoff and retries.** Retry throttled or failed calls with exponential backoff, and send records that keep failing to a dead-letter queue for review. ### Direct SQL Insert — Don't Do It Writing directly to Epicor's database bypasses Epicor's business logic and validation. Load through Epicor's supported tools, and ask Epicor before any direct database change. ### Which Approach Should You Choose? ``` Is this a one-time bulk load of master/transactional data for go-live? ├── YES → Does it involve complex multi-step business logic (e.g., WIP job state)? │ ├── YES → REST API with custom ETL (control sequencing and error handling) │ └── NO → Epicor DMT, if your partner confirms a template for the entity └── NO → Is this an ongoing delta sync or real-time integration? ├── YES → REST API (or middleware for simple mappings) └── NO → Clarify the use case before choosing a tool ``` | Approach | Best For | Engineering Effort | Delta Sync | |---|---|---|---| | **Epicor DMT** | One-time bulk master data loads | Medium | No | | **REST API / Custom ETL** | Complex loads, delta syncs, WIP state | High | Yes | | **Middleware (Boomi, Make)** | Simple ongoing integrations | Low | Limited | For most transitions, a **hybrid approach** works best: bulk loads via DMT for master data, followed by API-based delta syncs to capture changes between the bulk load and go-live. Middleware can supplement simple integrations but is not built for multi-level manufacturing dependencies like routing operations tied to work centres. ## SYSPRO to Epicor Kinetic Data Mapping This is where migrations succeed or fail. SYSPRO's module-prefixed schema maps onto Epicor Kinetic's entities, but the field-level translation needs careful attention to data types, key structures, and relationships. ### Core Entity Mapping SYSPRO table names below come from SYSPRO's documentation. Confirm the matching Epicor entity and import template for each row with your Epicor partner. | SYSPRO Table | Description | Epicor Kinetic target | Notes | |---|---|---|---| | `ArCustomer` | Customers (AR) | Customers | Payment terms, credit limits and currency codes need remapping. Map customer contacts separately. | | `ApSupplier` | Suppliers (AP) | Suppliers | Map SYSPRO supplier grouping to Epicor's grouping | | `InvMaster` | Inventory master (stock codes) | Parts | UOM conversion, part class and product group mapping required | | `InvWarehouse` | Inventory per warehouse | Part warehouse and bin data | Load after warehouses and parts exist | | `SorMaster` / `SorDetail` | Sales order headers and lines | Sales orders | Open orders only — closed orders belong in an archive | | `PorMasterHdr` / `PorMasterDetail` | PO headers and lines | Purchase orders | Map SYSPRO PO statuses to Epicor states | | `BomOperations` | BOM operations (routing steps) | Part revision operations | Routing-to-revision mapping is non-trivial; see BOM edge case below | | `BomWorkCentre` | Work centres | Resource groups and resources | One SYSPRO work centre may become a resource group with several resources | | `WipMaster` | WIP jobs | Jobs | Only migrate active jobs. Partially complete jobs need state reconstruction; see WIP edge case below | | `GenMaster` | GL accounts | GL accounts | Map to the chart of accounts structure finance designs in Epicor | | `GenTransaction` | GL transactions | GL journals | Reconcile sub-ledger to GL balances before loading; migrating closed transaction history is rarely advisable | | `TblCurrency` / `TblCurrDatedRates` | Currencies and dated exchange rates | Currencies and exchange rates | Currency setup must be complete before any foreign-currency transactions are loaded | | `LotDetail` | Lot detail | Part lots | Check for purged lot history in archive files before extraction | | `InvSerialHead` | Serial numbers | Serial numbers | Serial status mapping required | Build the field-level mapping from your own SYSPRO schema. Read the column list for each table in your company database, then map each column to the target field your Epicor partner confirms. Keep each SYSPRO key in a field on the Epicor record, so you can cross-reference during validation and after go-live. ### Custom Field Mapping SYSPRO stores custom form data in **plus tables** — `[ArCustomer+]`, `[InvMaster+]`, and so on. In Epicor Kinetic, custom data needs user-defined fields set up on the target entity, or a separate custom table for data with no standard home. The mapping decision: - **Plus-table fields that extend a standard entity** (e.g., a custom field in `ArCustomer+`) map to user-defined fields on the matching Epicor entity. - **Plus-table data that represents a standalone entity with no Epicor equivalent** maps to a custom table, with key fields linking it to parent records. Set up the user-defined fields in Epicor before you import any custom data, and add that setup to your cutover runbook. Ask your Epicor partner what steps make new fields available to DMT and the API in your environment. ## What Does the Migration Architecture Look Like? A SYSPRO-to-Kinetic migration follows an extract → transform → load (ETL) pattern with one sequencing rule: Epicor checks references when records load, so entities must load in dependency order. Loading a sales order before its customer exists will fail. Loading a BOM before its component parts exist will fail. **Load sequence:** 1. **Foundation data** — Companies, Sites, Currencies, UOMs, Tax Categories 2. **Chart of Accounts** — account structure and posting setup 3. **Manufacturing setup** — Work Centres, Resource Groups, Resources 4. **Master data** — Customers, Suppliers, Parts (including warehouse/bin assignments) 5. **Manufacturing data** — Part Revisions, BOMs, Routings 6. **Transactional data** — Open Sales Orders, Open Purchase Orders, Active WIP Jobs 7. **Financial data** — Open AR/AP balances (not individual closed transactions) 8. **Traceability data** — Lot records, Serial numbers For extraction, bypass SYSPRO's e.net business objects for bulk data. Query objects like `ARSQRY` or `INVQRY` work for integration but return XML per record or filtered set, which makes them slow for bulk reads. Use direct SQL Server access to read the SYSPRO company database. ## Step-by-Step Migration Process ### 1. Audit SYSPRO and Define Scope Before extracting a single record, audit your SYSPRO environment: - **Identify the source of truth.** Determine if SYSPRO holds your master data, or if an external CRM, PLM, or WMS system does. Migrating stale master data from SYSPRO when the live version lives elsewhere is a common scope error. - **Enumerate the plus tables.** Run `SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '%+%'` in the SYSPRO company database to identify all plus tables. Document every custom field that needs a matching user-defined field in Epicor. - **Define scope.** Decide whether you are migrating full historical ledger transactions or just open balances. Moving years of closed `GenTransaction` records into Epicor is rarely advisable. Keep them in an archive instead. - **Assess data quality.** Run duplicate checks on customer codes, stock codes and supplier codes before extraction. Duplicate keys in the source will cause conflicts in Epicor regardless of which loading method you use. - **Check what SYSPRO has already purged.** SYSPRO's Lot Purge and Archive program and its Serial File Purge program may have moved or deleted history ([help.syspro.com](https://help.syspro.com/syspro-8-2024/g_programs/lot/lotp01/lotp01.htm)). Find out whether they have been run before you finalize scope. ### 2. Extract Data from SYSPRO Connect to the SYSPRO SQL database with `db_datareader` permissions. Extract the core tables (`ArCustomer`, `ApSupplier`, `InvMaster`, `SorMaster`, `WipMaster`, `PorMasterHdr`, `BomOperations`, `GenMaster`) and their plus tables in one coordinated snapshot, to avoid inconsistencies between related tables. Check for purged lot history in archive files. Export into a staging environment — never transform directly against the live SYSPRO database. ### 3. Transform and Cleanse Transform the data to meet Epicor's validation rules: - Standardize date formats - Map SYSPRO status codes to Epicor's equivalent states - Convert boolean and flag fields to the types Epicor expects - Handle UOM conversions and currency precision - Map SYSPRO GL account codes to the chart of accounts structure finance designs in Epicor - Remove duplicates and fix character encoding issues - Set up user-defined fields in Epicor for custom SYSPRO fields before attempting any load of custom field data ### 4. Load into Epicor Kinetic Execute the load via Epicor DMT or the REST API, following the dependency order above. A part must exist before its warehouse data can be loaded. Work centres must exist before operations. Customers must exist before sales orders. **Rollback planning:** If the load fails partway through — for example, at step 5 (Manufacturing data) after steps 1–4 are complete — you cannot simply rerun from step 5 without risk of duplicate foundation records. Establish a rollback procedure before go-live: either keep a pre-load Epicor database snapshot, or script compensating deletes for each entity that can be re-run cleanly. Test the rollback procedure during your mock cutover, not during the real one. ### 5. Rebuild and Verify Relationships Ensure multi-level relationships are intact. A sales order line must reference the right part, customer and tax category. Every BOM component must reference a valid part. Run referential integrity checks programmatically, in a test environment, rather than by hand. ### 6. Validate Run automated validation across five dimensions: - **Record count parity** — compare source counts from SYSPRO SQL against Epicor counts per entity. A 1% discrepancy on 50,000 parts is 500 records. Investigate every gap. - **Financial reconciliation** — compare trial balance totals from SYSPRO against the loaded Epicor GL. Sub-ledger balances (AR, AP, Inventory) must tie to GL control accounts to the penny. - **Field-level sampling** — sample 5–10% of records per entity and verify field values. Pay particular attention to currency amounts (rounding and decimal precision), date formats, UOM conversions, and character encoding. - **Referential integrity verification** — confirm every sales order line references a valid part and customer, every BOM component references a valid part, and every routing operation references a valid resource group. Run these as automated queries, not manual spot checks. - **User acceptance testing** — have functional users run real workflows in Epicor: create a sales order, receive against a PO, issue material to a job, post an invoice. Data that loads correctly but breaks in workflow was not validated properly. Never treat a successful HTTP status as proof of data integrity. Check the response body and confirm the record exists. ## Edge Cases That Break SYSPRO-to-Kinetic Migrations **1. Out-of-sequence entity loading.** Loading any entity before its parent exists will fail validation. Establish the full dependency chain before the load begins. **2. WIP and open jobs.** Migrating work in progress from SYSPRO `WipMaster` to Epicor jobs is the most technically complex entity migration. If a job is partially complete, you must calculate material issued (`WipJobAllMat` holds materials allocated to a job) and labour applied (`WipJobAllLab` holds labour allocated to a job), then recreate that state in Epicor. Wrong quantities produce wrong job costs. The safest approach is to close near-complete jobs in SYSPRO before migration and only migrate jobs with zero or minimal transactions. See [SYSPRO WIP and Job History: Migrate or Archive?](https://clonepartner.com/blog/blog/syspro-wip-and-job-history-migrate-or-archive). **3. GL structure mismatch.** SYSPRO GL accounts in `GenMaster` must be mapped to the chart of accounts finance designs in Epicor. This is a design decision requiring input from finance, not a simple field copy. A mismatched structure propagates errors into every subsequent financial transaction. **4. Orphaned records.** Older SYSPRO environments can contain orphaned records — `SorDetail` lines pointing to stock codes no longer in `InvMaster`, or `WipMaster` jobs referencing inactive work centres. Epicor will reject these records. Your ETL pipeline must find and quarantine orphans before the load phase. Run orphan detection queries during the audit, not during cutover. **5. Missed plus-table data.** Failing to extract custom form data from SYSPRO's plus tables (`[ArCustomer+]`, `[InvMaster+]`, etc.) causes silent data loss. Scripts that only read the base tables miss this data, and the load still looks successful because the base record was created — just without the custom fields. **6. Archived sales orders.** SYSPRO documents that archived sales orders cannot be queried via the `SORQRY` business object ([help.syspro.com](https://help.syspro.com/business-object-library/G_Objects/sor/sorqry/sorqry.htm)). If you need historical order data for reference, extract it directly from SQL and from SYSPRO's archive files. Loading years of closed order history into Epicor is rarely necessary. **7. Purged lot history.** SYSPRO's lot Purge and Archive program copies lot transactions to an archive file, and "the header record is never deleted from the lot master table" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/g_programs/lot/lotp01/lotp01.htm)). Lot headers may therefore reference transactions that no longer exist in the live database. Check archive files before extraction and decide whether historical lot transactions need to follow the inventory into Epicor. Regulated manufacturers usually need them. **8. BOM and routing structure.** SYSPRO's `BomOperations` holds routing steps for each stock code. Epicor ties BOMs and operations to a part revision. Decide on a revision naming convention before the load begins — which revision label corresponds to the current SYSPRO production BOM? Without this decision, BOM loads will fail or create unusable revision structures. See [Migrating SYSPRO BOMs and Routings](https://clonepartner.com/blog/blog/migrating-syspro-boms-and-routings). **9. Multi-company databases.** SYSPRO holds each company in its own database. If you are consolidating several SYSPRO companies into one Epicor company, or splitting one into several, you need extra transformation logic, decided before data mapping begins. **10. Exchange rates.** SYSPRO stores exchange rates in `TblCurrency` and dated rates in `TblCurrDatedRates` ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/dated-exchange-rates/dated-exchange-rates-ovr.htm)). Set up currencies and rates in Epicor before migrating any transaction that references a foreign currency. **11. API throttling and integration licensing.** Throttled calls and an unlicensed integration account can both stop a bulk load mid-run. Implement exponential backoff with a retry cap, and confirm integration account licensing before starting any load. **12. Silent rejections.** A load script that only checks HTTP status codes can log a rejected record as a success. Parse every response body and confirm the record exists. ## Cutover Strategy Run a full mock cutover before the real one. Time every phase — extraction, transformation, load by entity, delta sync — under conditions close to production. This removes go-live surprises and gives you a measured cutover duration to share with the business. **Go live on a Monday, never a Friday.** Freezing SYSPRO and completing the final delta sync before Monday's working day gives you a full week to stabilize in Epicor with IT and functional staff available. A Friday cutover that hits problems leaves you troubleshooting over a weekend with fewer people around. **Cutover sequence:** 1. Run the bulk load into Epicor in the days before go-live while SYSPRO stays live. 2. Optionally, run incremental delta syncs to capture changes in open orders, parts, customers, and suppliers. 3. Freeze SYSPRO (no new transactions) before Monday's working day starts. 4. Run the final delta sync, covering only records changed since the last sync. It takes about 30 minutes. 5. Validate record counts and financial balances. 6. Open Epicor for production use. After go-live, rebuild reports and dashboards in Epicor, train users, and watch for third-party systems still trying to send data to the frozen SYSPRO environment. ## Best Practices **Extract via SQL, load via Epicor's tools.** Use direct SQL for SYSPRO extraction to capture everything including plus tables. Use Epicor's supported import tools for the load so business logic is enforced. **Migrate open transactions only.** Leave closed sales orders, closed purchase orders and closed jobs in an archive or data warehouse. Migrate open balances and open orders to Epicor. **Test the rollback.** During your mock cutover, run the rollback procedure, not just the forward load. If you cannot roll back cleanly in testing, you cannot roll back cleanly in production. **Check every response.** Build response-body checks into every load script from the start, not as an afterthought. **Set up user-defined fields before loading custom data.** Add their setup to your cutover runbook with completion checkboxes. **Start scoping early.** The load itself takes days. The work before it — auditing SYSPRO, designing the chart of accounts mapping, setting up user-defined fields, building and testing ETL scripts, running mock cutovers — takes much longer. With SYSPRO licences expiring on 31 October 2026 (outside the US) and 31 December 2026 (US), start now. ## When to Use a Managed Migration Service Building this pipeline in-house is feasible if you have engineers who know both SYSPRO's SQL schema and Epicor Kinetic's import tools. Most teams don't. The common failure modes of DIY migrations: - **Broken referential integrity** from loading entities out of sequence - **Missed plus-table data** because the extraction script didn't account for SYSPRO's custom form tables - **Silent data loss** from unchecked response bodies, field truncation, character encoding mismatches, or UOM conversion errors - **Extended downtime** because the cutover wasn't rehearsed with a delta sync and the rollback procedure was never tested ClonePartner is an engineer-led data migration service. We don't resell SYSPRO or Epicor, and we don't implement Epicor — we move the data and validate the result. Every project includes unlimited sample migrations until the data is right. - **Fixed pricing** — one fixed price per project, starting at $500 ([clonepartner.com](https://clonepartner.com/pricing)). No hourly billing, no per-record metering. - **1–5 business day execution** — depending on data volume, complexity and API rate limits. Datasets under 10,000 records can finish in under 24 hours. - **SOC 2 Type II and ISO 27001.** Staging data is purged within 30 days of project close. Our validation uses record-count parity, field-level checks, response checking, and referential integrity verification across every entity. For related SYSPRO migration patterns, see the [SYSPRO to Dynamics 365 Business Central Migration Guide](https://clonepartner.com/blog/blog/syspro-to-dynamics-365-business-central-migration-guide). For an architectural comparison of the target platform, see [IFS vs Epicor Kinetic: Architecture, TCO & Migration Guide](https://clonepartner.com/blog/blog/ifs-vs-epicor-kinetic-architecture-tco-migration-guide). For a structured validation approach, see [The Ultimate ERP Data Migration Checklist (10-Point Plan)](https://clonepartner.com/blog/blog/the-ultimate-erp-data-migration-checklist-10-point-plan). > Migrating from SYSPRO to Epicor Kinetic? Book a free 30-minute scoping call. We'll map your data landscape, identify the edge cases, and give you a fixed-price proposal — no hourly billing, no surprises. > > [Talk to us](https://clonepartner.com/talk-to-us?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click) ## Frequently asked questions ### How long does a SYSPRO to Epicor Kinetic data migration take? The data migration itself — extraction, transformation, and loading — typically completes within 1–5 business days, depending on data volume, complexity, and API rate limits. Small datasets under 10,000 records can finish in under 24 hours. This does not include the broader Epicor Kinetic implementation project (configuration, training, workflow setup), which is a separate effort measured in months. ### Can I export my data from SYSPRO after the 2026 licence expires? SYSPRO's formal notice states that on cessation of your current licence, you have the right to export your data, and that SYSPRO will provide a straightforward process for this on request. The notice does not say how long that process stays available after expiry. Plan your extraction before the deadline — 31 October 2026 outside the US, 31 December 2026 for US customers — and raise the export with your account manager ahead of it. ### What is the best way to load data into Epicor Kinetic? Load through Epicor's supported tools — its DMT import tool or the Kinetic REST API — so that Epicor's business logic validates every record. Ask your Epicor partner which tool suits each entity in your release and what limits apply in your environment. A common pattern is DMT for bulk master data and the API for delta syncs. ### What happens to SYSPRO custom fields during migration to Epicor Kinetic? SYSPRO stores custom form data in plus tables (e.g., [ArCustomer+]). In Epicor Kinetic, custom data needs user-defined fields set up on the target entity before you import. Plan the target field mapping during scoping — not during load. ### Does the Epicor Kinetic REST API have rate limits? Limits depend on your Epicor release and on whether you run Epicor's cloud or your own server. Confirm them with your Epicor partner, test throughput during sample migrations, and build paging, backoff and retries into every load script.