In January 2026, Epicor confirmed that version 2028.1 will be the final on-premises feature release for Kinetic, with Active Support running through December 31, 2029 and Sustaining Support beginning January 1, 2030. The dates are set.
What most manufacturers haven’t figured out yet is what those dates actually demand of them, and how much lead time the real work requires. Today, we break it all down.
The system isn’t shutting down. Get that off the table first.
Your on-premises Epicor environment will continue to function after 2028.1. What changes is that no new features, improvements, or updates will be delivered to on-premises customers after that release. Move into Sustaining Support in January 2030 and the situation gets more consequential: no new releases, no security updates, no critical patches, no compliance or regulatory updates.
For manufacturers with regulatory exposure, quality certifications, financial compliance requirements, or industry-specific reporting obligations, that’s not a minor detail. A system that runs but stops receiving compliance updates is a risk that compounds quietly every year. The framing that you have until 2030 to worry about this understates what’s actually involved. A well-managed migration for a complex environment can take over 12 months. That math changes when the deadline becomes real.
Most conversations about this announcement start in the wrong place. Cloud versus on-premises is a strategic question worth answering, but it’s the second question, not the first.
The first question is: do you actually know what’s running in your environment?
Most manufacturers running on-premises Kinetic have been on it for years. That time accumulates. BPMs written for a process that changed two years ago. BAQs feeding a dashboard nobody remembers commissioning. Custom forms built by a consultant who’s long gone, with embedded C# scripts the current team has never touched. Integrations to third-party systems that work fine until something upstream changes.
When TeccWeb walks into an on-premises Kinetic environment ahead of a migration conversation, the first thing we do is an inventory. What we consistently find is a gap between what the team believes is in the environment and what’s actually there. Customizations that reporting or workflows actively depend on, with no documentation. Integrations running on logic written against an older API version, held together by a scheduled task nobody monitors. Reports that finance runs every month-end that would break if anyone touched the underlying BAQ.
Every customization, bolt-on, and workaround that accumulates between now and migration must be re-engineered, retired, or replaced. The customization inventory will be the single largest cost driver in any migration scenario. That’s what drives timeline and budget overruns in ERP migrations more reliably than almost anything else. Not the technology. The accumulated history of a live system nobody has fully mapped.
You can’t make a sound decision about where to go next until you know what you’ve built. That inventory is where the planning work actually starts.
Is your team still working in the Epicor classic Smart Client?
Starting with the 2026.1 release, Epicor no longer distributes the traditional Smart Client desktop application. All general users must transition to a web browser interface. That deadline isn’t 2028. It’s now.
C# scripting and classic personalization layers must be reviewed and often re-engineered for the Kinetic framework. Application Studio now handles most screen logic using visual tools and event-driven actions, and embedded logic in classic screens may need to be restructured. If your environment has custom screens built in the classic UI, and most environments that have been running for several years do, those screens don’t carry over automatically. Each one needs to be assessed, then rebuilt or replaced.
The reason this matters for 2028 planning: teams that haven’t completed the UI migration are still adding to their customization debt while falling behind on a nearer deadline. The two projects are separate but they interact directly. Classic-form technical debt carried into a cloud migration makes that migration more complex and more expensive. Cleaning it up before the conversation about cloud migration starts puts you in a better position on both.
TeccWeb works through this with manufacturers in a consistent sequence. The steps below aren’t the only way to approach it, but skipping any of them tends to surface as a more expensive problem later.
Customizations, integrations, BAQs, reports. Not what’s documented but what’s actually running. This is the step most teams skip, and it’s the one that creates the most trouble downstream. The gap between what a team believes exists in their environment and what’s actually there is almost always wider than expected.
Not everything in the environment needs to survive a migration. Some customizations can be retired. Some workarounds exist because the base configuration was never set up correctly, and fixing the configuration is a better answer than migrating the workaround. Knowing which is which has a direct and measurable impact on migration scope and cost.
Third-party integrations designed for on-premises Epicor may require modification or replacement for cloud environments, as API architectures differ and authentication methods change. Finding those gaps before a migration starts is significantly less expensive than finding them mid-project.
If you’re still running classic forms or screens built on C# scripts, treat that as its own project with its own timeline. It shouldn’t get folded into the cloud migration conversation as a secondary concern. The two projects interact, but managing them as one makes both harder to execute cleanly.
A migration that lands during peak production season or in the middle of a fiscal close creates operational risk that’s entirely avoidable. Good planning establishes what windows are actually available for your business, not just what the project timeline allows.
No. The January 2028 date marks the final on-premises feature release, not a shutdown. Your system will continue to function after that point. What changes is that no new features, improvements, or updates will be delivered to on-premises customers. The more significant threshold is the transition to Sustaining Support in January 2030, after which no new security updates, critical patches, or compliance and regulatory updates will be issued.
Active Support provides full access to Epicor phone support, security updates, and new issue investigation. Sustaining Support is a reduced tier. It covers existing documented issues but does not include new patches, security updates, or compliance changes. For manufacturers with ongoing regulatory or reporting obligations, the distinction is material.
It depends significantly on the complexity of the environment. A system with years of customizations, multiple third-party integrations, and undocumented configuration changes requires substantially more preparation than a relatively standard deployment. Implementation timelines of 12 to 24 months are common for organizations undertaking a full migration. The preparation work, including environment auditing, customization assessment, and integration mapping, adds time before the migration itself begins.
The technical side of an Epicor migration is manageable when you know what you’re dealing with. The harder part is knowing what you’re dealing with in the first place, and that takes hands-on experience with real on-premises environments, not just familiarity with the platform.
TeccWeb has done this work with manufacturers running on-premises Kinetic across a range of complexity levels. We know where the problems tend to hide, what an environment audit actually surfaces, and how to turn that inventory into a migration plan that accounts for how the business actually runs. We also know when cloud migration is the right move and when the numbers or the operational reality suggest a different approach.
If you’re at the point where the 2028 timeline feels real but the path forward isn’t clear yet, that’s exactly where a conversation with TeccWeb is useful. No commitment required. Just a straight answer on where your environment stands and what it would take to move it forward.
