Epicor has confirmed that all future Kinetic innovation is moving exclusively to the cloud. The final on-premises feature release is scheduled for early 2028, with active support running through the end of 2029. For on-premises customers, the migration question is no longer if but when.
Most teams treat a cloud migration as a technical project. Move the data, rebuild the customizations, go live. The steps are not the hard part. The hard part is knowing which of those steps will create problems for your specific environment before they slow the project down. That is what this checklist is actually about.
Most Epicor environments have more customization complexity than anyone on the project team fully remembers. This is where the real cost of a migration lives, and it is consistently underestimated.
BAQs and BPMs carry over to the cloud environment. Client-side C# scripts built in the Classic UI do not automatically port to the web. UI customizations built in the Classic interface must be rebuilt using Application Studio. Business logic embedded in Classic screens needs to be restructured, either moved to Epicor Functions, rebuilt in BAQs, or recreated in Application Studio.
For environments with a significant number of customizations, the rebuild work is substantial. A customization that worked reliably on-premises may break in the cloud version without warning due to changes in framework, database structure, or API behavior. Every customization needs to be catalogued before the project starts, assessed for cloud compatibility, and assigned one of three outcomes: rebuild, replace with standard cloud functionality, or retire. Treating this as a pre-project discovery step rather than a migration task is one of the clearest ways to avoid expensive surprises mid-project.
The cloud environment does not fix bad data. It just gives it a faster home.
Duplicate customer records, corrupted inventory counts, and incomplete supplier data do not disappear during migration. They arrive in the new environment on day one and immediately create trust issues that push people back to spreadsheets. That is a pattern that is very difficult to reverse once it takes hold.
Before migration begins, review customer records, inventory data, open transactions, and supplier lists for duplicates, inconsistent formats, and missing fields. Run a test migration on a defined subset of data first. Problems that surface in a test migration are manageable. The same problems discovered after go-live are not.
Decide what historical data actually needs to come across. Archived transactions, closed orders from several years prior, and data tied to processes that no longer exist add migration weight without adding operational value. Less data moved cleanly is a better outcome than all data moved with integrity problems.
Integrations built for an on-premises architecture do not automatically work in the cloud. This is one of the most common sources of post-go-live disruption, and it is almost always avoidable.
Warehouse management systems, EDI platforms, tax engines, labeling tools, and any other third-party application that connects to Kinetic needs to be reviewed individually before the project starts. The cloud version of Kinetic uses REST APIs and standardized connectors. Integrations built on older methods may need to be rebuilt from the ground up.
The discovery work here is not complicated, but it takes time. Leaving it until after go-live is a reliable way to create operational problems in the first 30 days on the new system, exactly when the team is least equipped to handle them.
Moving to cloud ERP means your business depends on internet connectivity to run. That sounds obvious. Most teams underestimate what it actually means in practice until something goes wrong.
A single internet provider is a single point of failure for the entire operation. Teams that have already made this move recommend a minimum of two providers from different carriers at each location. A mobile backup option covers emergencies: power events, cyber incidents, or physical damage to the facility that makes the local network unreliable.
Multi-site businesses need to assess connectivity at every location, not just the primary office. A branch with 10 users and a single residential-grade internet connection is a risk that needs to be addressed before go-live, not after the first outage.
Running a test migration confirms that data moved. It does not confirm that the migrated environment actually works for your business. Those are two different things.
Test data accuracy across key modules: inventory counts, open orders, customer balances, and financial periods. Test customization behavior in the cloud environment. Test integration outputs. Compare report and BAQ outputs against the on-premises version and confirm the numbers match.
The people doing the testing should be the ones who will use the system daily. Not just the project team. If a production supervisor cannot complete a job transaction, or an AR clerk cannot apply a payment the way they expect to, those are problems that need to be found and fixed before go-live. Finding them after is significantly more disruptive and significantly more expensive.
A migration that moves data and configuration cleanly but does not prepare the team to work in the new environment will produce the same outcome as a poorly executed technical project. Prosci’s 2025 research confirmed that human factors matter six times more than technical factors in ERP project outcomes.
Training should be role-specific, not system-generic. The goal is not to teach Kinetic. It is to help each person do their job in the new environment. A warehouse team member needs to understand receiving and shipment transactions. A finance manager needs to understand the period close in the cloud version. Generic platform training covers neither.
Post-go-live support coverage for the first 30 to 60 days is not optional. It is the period when questions are highest, confidence is lowest, and the temptation to build workarounds is strongest. Having someone available to answer questions and resolve issues during that window is the difference between a team that adopts the system and a team that routes around it.
It depends heavily on the complexity of the environment. A simpler deployment with clean data and limited customizations can move in a matter of weeks. Environments with significant customization depth, integration complexity, or data quality issues take longer. The discovery work done before the project starts is the single biggest factor in how predictable the timeline will be.
BAQs and BPMs carry over. Client-side C# scripts and Classic UI customizations do not automatically transfer. They need to be reviewed, assessed, and rebuilt in Application Studio or restructured into Epicor Functions or BAQs. The volume and complexity of customizations in your environment is the most important factor in estimating migration cost and effort.
Generally yes. Epicor requires customers to be on a supported version before migrating to the cloud. If you are running an older on-premises release, an upgrade step may be required before the cloud migration can begin. Confirm the version requirements with your partner or Epicor directly before the project scope is defined.
Epicor has announced the final on-premises feature release for Kinetic is tentatively scheduled for January 2028, with active support through December 31, 2029. After that, customers move into a sustaining support phase. Planning a migration with enough lead time to do it properly is strongly preferable to being forced into it under deadline pressure.
A clean Epicor Kinetic cloud migration requires more than following a checklist. It requires knowing which items on that list are straightforward for your environment and which ones need more careful handling before the project starts. The customization audit, the data cleanup, the integration review, and the post-go-live support plan all have the potential to become serious problems if they are not addressed early.
TeccWeb works with Epicor users and partners on Kinetic cloud migrations, from pre-project discovery through post-go-live support. If your migration is coming up and any part of this checklist looks complicated, get in touch before the project starts.
