Epicor Kinetic On-Premise After 2028: Options and API

Epicor Kinetic on premise gets its last feature release, 2028.1, tentatively in January 2028. Epicor gives that release Active Support through December 31, 2029, then limited Sustaining Support from January 1, 2030. Your system keeps running either way. You can move to Epicor Cloud or stay on-prem, and both go better once your integrations use the REST API v2.

The ERP decision will get a project plan. The integrations around it often won't: SQL views, linked servers, BPMs that write files to a share, and an Excel workbook in purchasing that nobody admits to owning. Anything that depends on direct SQL or the app server's file system stops working in Epicor Cloud, and you can rebuild those pieces now, on-prem.

What did Epicor announce for Kinetic on-premise?

On January 6, 2026, Epicor announced that Kinetic 2028.1 will be the final on-premises release and that later Kinetic features will ship only in Epicor Cloud. Customers who bought Kinetic SaaS are not affected. The Business Wire release marks the dates as tentative; the Epicor newsroom copy carries the same schedule, which also covers BisTrack Desktop and older BisTrack UK releases not shown here.

Active Support is stated for release 2028.1, so a shop on 2024.2 should expect to upgrade to 2028.1 to get it. The customer notice reposted on EpiUsers says Active Support covers "fixes, security updates, and full technical assistance," while Sustaining Support "provides limited technical and application assistance." CIO.com lists limited phone support, the latest release without new modules, and the knowledge base. Neither lists security updates under Sustaining, although Epicor's press release says the phases exist "to ensure ongoing security and operational continuity." Get your account manager's answer in writing.

If your Kinetic database runs on SQL Server 2019, Microsoft's extended support for it ends January 8, 2030, eight days after Epicor's Active Support does. Staying on-prem into 2030 on that stack means running the ERP and its database with few or no vendor security fixes unless you upgrade SQL Server along the way.

What are your options if you run Kinetic on-prem today?

There are four realistic paths: Epicor's multi-tenant cloud, a single-tenant hosted cloud, staying on-prem on 2028.1, or replacing the ERP. Each one is easier if your integrations stop depending on direct database access before you choose.

2W Technologies describes Kinetic Custom Cloud as a single-tenant Azure environment sold by Epicor, with 2W managing infrastructure, SQL and patching and Epicor keeping functional support. Its FAQ says customers get application, API and integration host access but not OS-level access, and that major version upgrades are scoped and quoted separately. Ask which releases and support a Custom Cloud contract includes after 2028.1.

Epicor's own path is Ascend, which Epicor President and Chief Product and Technology Officer Vaibhav Vohra described as an "AI-powered Ascend with Epicor migration program" in Constellation Research's coverage of the announcement. It moves the ERP, not the linked server your controller built in 2017, so the integration inventory below is your side of that project. When you compare quotes, ask about the subscription against your current maintenance, the read-only replica if you need SQL reporting, any single-tenant premium, and the integration rework itself.

We have not found an independent firm that publicly offers Kinetic support the way several do for SAP and Oracle, so ask your Epicor partner in writing what they can cover after December 31, 2029. For comparison, see our post on the SAP ECC 2027 deadline for midsize manufacturers.

Which integration methods work on-prem and in Epicor Cloud?

REST API v2, BAQs exposed through REST and Epicor Functions work in both places. Direct SQL against the production database, file writes from BPM code, Service Connect running on the ERP server, and anything you install on the app server are on-prem only.

In a January 2026 EpiUsers discussion, Epicor Cloud customers said there is no direct SQL access to production, that a read-only copy can be bought for an additional cost, and that it connects over ODBC from IP addresses the cloud team allow-lists. The original poster measured his on-prem SQL polling at under 0.3 seconds and estimated that doing the same work through REST sessions would carry roughly 300% more overhead. Measure your heaviest integration the same way before you sign anything.

Kinetic Cloud customers on 2023.2 reported BPMs compiling with warning ECF1002, for example "The 'System.IO.File.AppendAllText(string, string?)' method cannot be called." In February 2024, Santiago Palacios, posting as Epic_Santiago, replied that the warnings "are intentional and are highlighting custom code patterns that we have identified as being problematic," and that they will become errors. System.Reflection was flagged too; check your target release. A BPM that writes a CSV to \\fileserver\edi\out needs a different design in the cloud, usually a call to an outside service that writes the file.

A July 2022 EpiUsers answer said Service Connect cannot run on the cloud instance, works with cloud accounts only from a separate server using REST calls, has been removed from the price list for new accounts, and is being replaced by Automation Studio. Epicor Automation Studio, launched in 2022, is a Workato-based iPaaS embedded in Kinetic and Prophet 21. It fits standard SaaS-to-SaaS flows; shop-floor systems and odd file formats still need code somewhere.

Epicor REST API v1 vs v2: which should you use?

Use REST API v2 for every new integration. It puts the company in the URL, requires an API key on top of the user login, supports access scopes, and is the only version that can call Epicor Functions. Keep v1 enabled only because the Kinetic browser client still depends on it.

An EpiUsers REST v2 thread shows a v1 call as https://{server}/{instance}/api/v1/Erp.BO.CustomerSvc/Customers and the v2 equivalent as https://{server}/{instance}/api/v2/odata/{CompanyID}/Erp.BO.CustomerSvc/Customers. The same thread shows BAQs at /api/v2/odata/{Company}/BaqSvc/{BaqID}/Data. Your instance's own help at /apps/resthelp/, per Epicor's REST services overview deck, is the authoritative list for your version.

Security is the reason to switch. In a v1 vs v2 discussion, Olga Klimova explained that the API key requirement is the only default security difference, that the browser UI uses v1, and that Functions require v2. Another contributor noted that REST ignores menu security, so without keys any valid user can reach almost any service through v1. On-prem, the EnforceApiKeyForRestApiV1 web.config setting forces keys on v1; test the Kinetic UI before enabling it in production.

Every v2 call needs an Authorization header (Basic or Bearer) and the API key. Two more headers are optional but common. A community-maintained client library, epicor-rest-node, sends the key as X-API-Key, sends CallSettings as JSON to pick company and plant, and sends License when it needs to claim a specific license type for the session. It gets bearer tokens by posting the username and password to /{instance}/TokenResource.svc/ and reading AccessToken from the response.

Responses are capped at 100 rows by default, set by DefaultMaxRowCount in web.config, according to an EpiUsers pagination thread, where another user reported that $skip paging slowed as the offset grew. A sync job that reads one page and stops will silently miss rows.

# 1. Read a BAQ through REST v2. Company in the path, key in the header.
#    Loop with $skip until a page returns fewer rows than $top.
curl -s "https://erp.example.com/KineticProd/api/v2/odata/EPIC06/BaqSvc/OAF-OpenJobs/Data?\$top=100&\$skip=0" \
  -H "Authorization: Basic $(printf '%s' "$EPICOR_USER:$EPICOR_PASS" | base64)" \
  -H "x-api-key: $EPICOR_API_KEY" \
  -H 'CallSettings: {"Company":"EPIC06","Plant":"MfgSys"}'

# 2. Get a bearer token and keep it for later calls.
EPICOR_TOKEN=$(curl -s -X POST "https://erp.example.com/KineticProd/TokenResource.svc/" \
  -H "username: $EPICOR_USER" -H "password: $EPICOR_PASS" \
  -H "Accept: application/json" | jq -r '.AccessToken')

# 3. Call an Epicor Function (v2 only). Library, function and fields are examples.
curl -s -X POST "https://erp.example.com/KineticProd/api/v2/efx/EPIC06/ShopFloorSync/PostOperationQty" \
  -H "Authorization: Bearer $EPICOR_TOKEN" \
  -H "x-api-key: $EPICOR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sourceId":"MES-88123","jobNum":"J104233","assemblySeq":0,"oprSeq":20,"qtyCompleted":48}'

How do you create and use an Epicor API key?

API keys arrived in Epicor ERP 10.2.400 along with access scopes, and you create them inside the application, not in the admin console. Give each integration its own key, its own Epicor user and its own access scope, and send the key as the x-api-key header.

EpiUsers members point to the API key maintenance program and the API Key section of Application Help in 10.2.400 and later. An access scope limits which services, BAQs and Function libraries a key can call. It does not limit what those resources return, so a scoped BAQ that happens to include pay rates will still return them. Because the key only works alongside a valid login, restrict the integration user too, and test each exposed endpoint with a call that should fail.

The key also works as an api-key query parameter, and an EpiUsers thread on Excel and BAQs confirms the two spellings, but a key in a URL ends up in proxy logs, IIS logs and browser history, so use the header. Rotate keys on a schedule, since a key can be replaced without resetting anyone's password.

How should BAQs, BPMs and Epicor Functions split the integration work?

Read through BAQs, write through Epicor Functions that call standard business object methods, and let BPMs and change data capture announce events. Your outside system then calls a handful of named endpoints instead of dozens of business object methods.

BAQs are the read side. A BAQ respects Kinetic's security, handles the joins you would otherwise write by hand against Erp.JobHead, Erp.JobOper and Erp.LaborDtl, and moves to the cloud as long as it does not depend on custom code. Updatable BAQs with custom actions fall under the same code restrictions as BPMs.

Functions are the write side. Epicor introduced them in ERP 10.2.500 as an expansion of BPM, "available for cloud users," grouped in libraries you publish. A Function that calls the same business object methods the UI uses gets the same validation, so a labor posting from your MES is checked the way an operator's entry would be. That only holds if the Function is written that way. Business object endpoints and updatable BAQs can also write, but a Function keeps the sequence inside Kinetic.

Do not count on Kinetic to deduplicate a retried call. Pass a unique source ID from the external system, as in the example above, store it in a user-defined field or your own mapping table, and have the Function check it before posting. Retries after a timeout then cannot double count a labor transaction.

BPMs and change data capture are the outbound side. A post-processing method directive can call out when an order is released, and Epicor's change data capture, laid out in a detailed EpiUsers architecture thread, uses triggers and became generally usable in 10.2.600. You enable tables and subscriber rules, and the Task Agent runs a log processor and a notification sender that can push a webhook to your service. Latency depends on how often those tasks run, and a delete has to be read from the captured row data, since there is nothing left to fetch through REST. Within those limits it can replace the SQL polling loops that have no equivalent in the cloud.

For the shop-floor end of this pattern, see our post on MES integration between ERP, PLCs and legacy plant systems.

Inventory the integrations that will break in Epicor Cloud

Start with three things on your current on-prem system: clients that connect straight to the Kinetic SQL database, server objects that reach into it, and BPM or Function code that uses the file system, reflection, the network or its own SQL connection. The queries below give you a first list in an afternoon. They are a starting point, not a compatibility test.

The first query samples SQL Server's sys.dm_exec_sessions, which sees only open sessions by their current database, so it misses a report that uses three-part names from another database. Run it on a schedule across a month end. The second catches linked servers and Agent jobs. The third follows a pattern shared on EpiUsers for searching directive and Function source. The search terms are ours, not Epicor's. A match means someone should read the code; a miss proves nothing, so compile and run everything in a cloud test environment before cutover.

-- 1. Sample who is connected to the Kinetic database. Replace KineticProd with your DB name.
--    Needs VIEW SERVER STATE (SQL 2019 and earlier) or VIEW SERVER PERFORMANCE STATE (2022+).
SELECT s.login_name, s.host_name, s.program_name,
       COUNT(*) AS sessions,
       MAX(s.last_request_end_time) AS last_seen
FROM sys.dm_exec_sessions AS s
WHERE s.is_user_process = 1
  AND s.database_id = DB_ID('KineticProd')
GROUP BY s.login_name, s.host_name, s.program_name
ORDER BY sessions DESC;

-- 2. Linked servers and Agent job steps that point at the Kinetic database.
SELECT name, data_source, provider FROM sys.servers WHERE is_linked = 1;
SELECT j.name AS job_name, js.step_name, js.database_name
FROM msdb.dbo.sysjobs AS j
JOIN msdb.dbo.sysjobsteps AS js ON js.job_id = j.job_id
WHERE js.database_name = 'KineticProd' OR js.command LIKE '%KineticProd%';

-- 3. BPMs and Functions whose code needs a human review before the move.
SELECT 'Directive' AS kind, d.Source, d.Name, d.BpMethodCode AS target, d.Company
FROM Ice.BpDirective AS d
WHERE CONVERT(nvarchar(max), d.Body, 0) LIKE '%System.IO%'
   OR CONVERT(nvarchar(max), d.Body, 0) LIKE '%System.Net%'
   OR CONVERT(nvarchar(max), d.Body, 0) LIKE '%System.Reflection%'
   OR CONVERT(nvarchar(max), d.Body, 0) LIKE '%SqlConnection%'
UNION ALL
SELECT 'Function', f.LibraryID, f.FunctionID, f.Description, NULL
FROM Ecf.EfxFunction AS f
WHERE CONVERT(nvarchar(max), f.Body, 0) LIKE '%System.IO%'
   OR CONVERT(nvarchar(max), f.Body, 0) LIKE '%System.Net%'
   OR CONVERT(nvarchar(max), f.Body, 0) LIKE '%System.Reflection%'
   OR CONVERT(nvarchar(max), f.Body, 0) LIKE '%SqlConnection%';

Add what no query will find: SSRS shared data sources, Excel and Access files with saved connections, Service Connect workflows, and scheduled tasks on other servers. Then put each item through the same checklist:

1. Name the owner and the business process. If nobody owns it, find out whether anything breaks when you disable the login for a week in test.
2. Classify it as read, write or event. Reads move to a BAQ, writes to a Function, events to a BPM call-out or a change data capture subscriber.
3. Write down the latency it actually needs. A nightly cost export and a shop-floor scan have very different requirements, and many "real-time" requests turn out to be fine at fifteen minutes.
4. Rebuild it on REST v2 on your current on-prem version and run old and new side by side until the outputs match.
5. Turn off the SQL login, so nothing can quietly fall back to the old path.

What does an integration layer you own look like?

It is a small service you control that sits between Kinetic and everything else, holds the field mappings and retry logic, and talks to Kinetic only through REST v2, BAQs and Functions. Your MES, WMS, EDI provider and reporting talk to that service, so a change in where Kinetic is hosted touches one adapter instead of every system.

Inside it you want a queue, so an upgrade window does not lose shop-floor transactions, plus the source ID check above. Epicor publishes no response schemas, so record what each endpoint returns today, version that as your own schema, and validate every response against it. Keep a queryable log for when a planner asks why an order did not sync. The hard part is the write paths, where a Function's business object sequence for jobs, receipts and labor needs testing against real data.

Schema validation pays for itself the first time a vendor changes a response. On our reverse-engineered SOAP integration for an ISP's CRM, it caught three vendor-side changes before they reached production, and the abstraction layer cut integration time for new features by an estimated 60 to 70%. Kinetic's REST API documents itself; the undocumented side is usually the other system, such as a 20-year-old MES database. Where that needs reverse engineering, read up on whether reverse engineering software is legal for your situation. This is not legal advice; review your license agreement and MSA with counsel.

With this layer in place, moving Kinetic means reconfiguring and retesting one adapter (host name, credentials, API keys, Function libraries, network rules) instead of rewriting each integration. Our guide to legacy system integration and reverse engineering with AI covers the broader method, and the manufacturing software development work we do is mostly this kind of layer.

What should you do first?

Run the inventory queries this quarter and rank the results by how much the business would notice if each one stopped. Through 2027, rebuild the top items on REST v2 and Functions while you are still on-prem, where you can compare old and new outputs side by side. Decide on hosting before 2028.1 ships in January 2028, and plan any move well before Active Support ends on December 31, 2029. More on how we work with plants is on our manufacturing industry page, and if you want a second opinion on the inventory, get in touch.