Epicor 10 to Kinetic Upgrade: What the Project Actually Involves
What carries over, and what does not.
Gonzalo Nuñez
Chief Technology Officer
An Epicor Kinetic upgrade moves the ERP foundation and business data forward. The transaction history, chart of accounts, item masters, open orders, customer records, and financial configuration travel with the database. What the upgrade does not move forward automatically is everything built on top of that foundation: the customizations, BAQs, dashboards, integrations, reports, print layouts, and workflow behaviors that the business has layered onto Epicor over the years. Those require a separate workstream, and the scope of that workstream is what defines the project.
Understanding what sits in each category is the first task, and it is worth doing before anything else.
What moves forward
The ERP core moves forward. Data moves forward. Standard Epicor functionality available in Kinetic is accessible after the upgrade without a conversion workstream. If the business runs standard processes on standard screens, the transition centers on the database and infrastructure, with less application-layer work required.
What requires project work
The application layer is where the project lives. Each of the following areas requires review and, depending on what the inventory finds, conversion or rebuild work:
- Customizations: Classic form customizations built for the Smart Client do not run in the Kinetic browser interface. They require conversion or redesign in Application Studio.
- BAQs: Business Activity Queries need to be reviewed for compatibility with Kinetic's data model and interface layer.
- Dashboards: Dashboards built in the classic environment need to be redeployed for the browser interface. They do not convert automatically.
- Integrations: External integrations carry field mappings, trigger logic, and authentication patterns that need to be retested against the upgraded environment.
- Reports and print layouts: SSRS reports and custom print layouts behave differently depending on how they were built and which deployment path the business is taking. The inventory is where each gets classified.
- Workflow-dependent behaviors: BPM directives, notification logic, and process automations need to be verified against Kinetic's processing model.
Epicor's browser direction
Epicor has been moving its interface architecture toward the browser for several releases. With Kinetic 2021.1, Epicor moved classic forms into sustaining support, with new features going exclusively to the browser forms. Kinetic 2025.2 is the final release where the Smart Client is available. With 2026.1, Epicor replaces the Smart Client with browser forms.
That direction is relevant to the upgrade project because it sets the expectation for every customization and workflow built on the classic interface. Whatever was designed for the Smart Client needs to be assessed for the browser environment.
For a comparison of what changed between Epicor 10 and Kinetic as a product, see Epicor Kinetic vs. Epicor ERP: What's Different. This article covers the upgrade project.
Start with an inventory, not a quote
A project quote produced before the environment is inventoried is a guess. The inventory is what turns the upgrade from a general plan into a scoped workstream, and it is the step that determines whether the project scope reflects the actual environment.
The inventory covers every object and dependency the business has built or configured on top of Epicor:
- Every customization, including form customizations, BPM directives, and code layers
- Every BAQ, including those feeding dashboards, reports, and external tools
- Every dashboard, including those used in daily operations and executive reporting
- Every integration, including third-party connectors, EDI flows, and API dependencies
- Every SSRS report and custom print layout, including those tied to specific printers or output paths
- Every file-storage dependency, including attachments, document paths, and server-resident files
- Every workflow-dependent behavior, including notification logic, approval chains, and process automations
Classify before scoping
Once the inventory is complete, each item gets a classification: retain as-is, convert for Kinetic, rebuild from scratch, replace with a standard Kinetic equivalent, or retire. That classification drives the scope estimate. Items that can be retired reduce the project. Items that require rebuild are the ones that need time, testing, and sign-off.
For an Epicor 9 or 10 to Kinetic upgrade, what usually needs rebuilding is customizations, BAQs, dashboards, and integrations. For a move from Kinetic on-premise to Kinetic cloud, the focus shifts to server-dependent customizations, integrations, and print routing.
The inventory and phasing
For businesses running multi-company or multi-site environments, the inventory is also where phasing feasibility gets established. Whether a phased upgrade is realistic depends on how the environment is structured: how companies share data, how integrations are scoped, and how customizations are distributed across entities. That cannot be determined from the outside. It comes from the inventory.
The inventory is not a project deliverable that comes after scoping. It is the input that makes scoping possible.
Support timelines are another reason to complete the inventory before anything else. Support for a given Epicor release depends on the version and on Epicor's lifecycle policy. The upgrade team can assess that against the inventory findings and factor it into the project timeline.
Choose the path: Kinetic on-premise or Kinetic cloud
The inventory tells the business what it has. The path decision tells the upgrade team what the work plan looks like. On-premise and cloud are not the same project with different hosting. The path changes what gets rebuilt, what gets reworked, and what governance the business takes on after go-live.
Four criteria drive the decision.
Customization depth
The more the business has built on top of Epicor, the more the path matters. Customizations that depend on server-side access, local file systems, or direct database interaction behave differently in a cloud environment than they do on-premise. The inventory will surface which customizations carry those dependencies. That finding feeds directly into the path decision.
Reporting and print setup
Reporting architecture is the next factor to work through. SSRS reports built on standard Epicor report styles have a different conversion path than reports built outside those styles. Print routing that depends on server-resident printer configurations needs to be reworked for cloud. The inventory identifies which reports fall into which category.
Integration design
How integrations are built determines how much retesting the path requires. Integrations that depend on the server environment need to be checked against the chosen path.
How IT wants to run the system
On-premise keeps infrastructure management internal. Cloud shifts it to Epicor. That is an operational decision as much as a technical one, and it affects staffing, patching cadence, and how the business handles future Epicor releases.
The upgrade team works through these criteria with the business before the project scope is finalized. The path is not a default; it is a decision with consequences for the work plan.
For more on Epicor Kinetic implementation options, including what a structured upgrade engagement covers, that page has the detail.
Rebuild and test in a copy
The conversion and retest work happens in a non-production copy of the environment. The upgrade team does not rebuild customizations or retest integrations in the live system. The copy is where the classified items from the inventory get worked through before any production decision is made.
What the upgrade team converts and retests
For an Epicor 9 or 10 to Kinetic upgrade, the upgrade team reviews and converts customizations and BAQs for Kinetic, and retests integrations. For an on-premise to cloud move, server-dependent customizations are reworked, and print routing and file storage are moved to the new environment.
Dashboards that were built for the classic interface need to be redeployed for the browser. BPM directives need to be verified against Kinetic's processing model, not assumed to carry over intact. SSRS reports are tested against the deployment path, because what survives on-premise and what survives in cloud are not the same.
Testing by role, not by object
The retest phase covers more than technical objects. The upgrade team runs workflows by role: what a purchasing manager does from order creation to receipt, what a production planner does from job release to labor capture, what a sales rep does from quote to invoice. Those role-based walkthroughs surface issues that object-level testing does not.
Pass criteria are defined before testing starts, not after. Expected output, expected data movement, expected exception handling, and expected report output are documented. An item passes when it meets those criteria, not when it runs without an error message.
Issue logging and sign-off
Every issue found in the copy environment is logged, prioritized, and resolved before the project moves to cutover. The sign-off process is not a single approval event. It is a running record of what was tested, what passed, what was fixed, and what was retested. That record becomes part of the project documentation and the basis for the cutover decision.
Testing in a copy is not optional. It is the mechanism that separates a planned cutover from an unplanned recovery.
Plan cutover around production
A 24/7 plant cannot stop for a weekend. Cutover planning for a manufacturing environment starts from that constraint, not from a generic maintenance window. The upgrade team builds the cutover plan around what production actually requires: when the plant runs, when it does not, what the minimum viable window looks like, and what happens if the window is not enough.
Two checkpoints the client controls
The cutover plan includes two checkpoints that the business owns, not the upgrade team.
The first is sign-off on the field map before anything moves. The business confirms that the data migration plan maps source fields to target fields correctly, that the logic is understood, and that the output is what the business expects. Nothing moves until that sign-off is in place.
The second is confirmation that counts match before the old system goes read-only. Record counts, transaction totals, and open-item balances are reconciled between the source and the target. The old system does not go read-only until the business confirms the numbers match.
These two checkpoints are client-controlled because they are the two moments in the project where a bad decision cannot be undone quickly. The upgrade team provides the data and the tooling. The business provides the sign-off.
First-week support
Go-live is not the end of the project. The first week after cutover is where edge cases surface: workflows that were not covered in testing, report outputs that differ from expectation, user questions that did not come up in training. The upgrade team runs a structured first-week support model, with defined issue triage, priority levels, and resolution paths.
Role-based training is part of go-live readiness. Users who have worked in the classic interface for years need guided time in the browser environment before cutover, not after.
Proof
Greenpaper, a TCP client, ran Epicor on-premise since 2015 and moved to Kinetic cloud in 2022 while running a 24/7 plant.
Talk to TCP about your Kinetic upgrade
Integrations and agents after the upgrade
Integrations do not carry forward on assumption. An integration that worked in Epicor 10 needs to be retested in Kinetic, because the upgrade changes the environment the integration runs against. Field mappings, trigger logic, authentication patterns, timing, file movement paths, and exception handling all need to be verified in the upgraded environment before go-live.
What retesting covers
The retest scope for integrations mirrors the inventory classification. Each integration is tested against the scenarios it handles in production: the data it moves, the conditions that trigger it, the outputs it produces, and the errors it is supposed to catch. The practical issue in an upgrade is not always that an integration is entirely broken. It is that a specific field, trigger, or operational scenario behaves differently in the new environment. Scenario-level testing surfaces those differences. Connector-level optimism does not.
Fluent agents
Fluent agents connect through the connector layer, not through customizations inside SugarAI or Kinetic. That architecture means an upgrade needs a test, not a rebuild. The connector layer is what gets verified in the upgraded environment. The agents themselves do not need to be reconstructed from scratch.
The Epicor and CRM integration
The integration between Epicor and a CRM system requires close attention during the upgrade retest. Data sync logic, object mapping between ERP and CRM records, process triggers that fire across both systems, and the handoff points where a sales workflow transitions into an operational one all need to be confirmed in the upgraded environment.
For businesses running an Epicor and CRM integration, the upgrade is the moment to verify that every sync scenario works as expected, not to assume the integration survived intact because the connector is still connected. The SugarAI integration in particular carries field-level and trigger-level dependencies that need scenario testing, not just a connection check.
What to ask whoever runs your upgrade
The vendors give you upgrade tools and documentation. They do not clean your data, rebuild the customizations that break, or redo the reports. That is the work the upgrade partner owns, and it is the work to evaluate before the project starts.
These questions separate a partner who has run this project before from one who is running it for the first time on your environment.
Who owns the inventory, and what does it produce? The inventory is the foundation of the scope. Ask what gets catalogued, how items are classified, and what the output looks like before any work starts.
What gets rebuilt versus retired? Not everything in the inventory needs to come forward. Ask how the partner distinguishes between items worth converting and items worth replacing with standard Kinetic functionality.
How does the path choice change the scope? On-premise and cloud are different projects. Ask how the partner's scope changes between the two paths, and what the path decision means for customizations, reporting, and integrations specifically.
How are reporting and print routing handled? Ask which reports carry forward, which need conversion, and which need to be rebuilt. Ask how print routing is handled for the chosen deployment path.
How are integrations retested? Ask whether integration testing is scenario-based or connection-based. Scenario-based testing finds the issues that matter. Connection-based testing finds out whether the pipe is open.
How is cutover planned around production? Ask what the cutover plan looks like for a manufacturing environment. Ask what the two client-controlled checkpoints are and how rollback is handled if something goes wrong.
Who owns user acceptance, and when does it happen? Ask whether business users are involved in testing before go-live, not just after.
See how TCP runs Epicor upgrades
If you are planning an Epicor Kinetic upgrade, TCP runs fixed-price Epicor 10 to Kinetic upgrades and on-premise to cloud moves, with cutover planned around production.
Frequently Asked Questions
Classic customizations that are not converted before go-live continue to run in the classic client, where that client is still available. They do not run in the Kinetic browser interface. With Kinetic 2026.1, Epicor replaces the Smart Client with browser forms, which means users working in the browser will not have access to unconverted classic customizations at all. Any customization that the business needs in the Kinetic interface must be rebuilt or redeployed in Application Studio before go-live. Leaving conversions until after cutover creates a gap between what users expect and what the system delivers.
Both routes are valid, and the decision depends on the environment. Epicor itself offers the option to upgrade to Kinetic in the cloud and adopt the browser experience in one move, which reduces the number of transition events the business goes through. Running them as separate projects gives the team more control over each workstream and limits the variables in any single cutover. The deciding factors are customization depth, integration complexity, how much the reporting architecture needs to change, and how much change the business can absorb at one time.
It depends on how they were built and which deployment path the business is taking. SSRS reports built on standard Epicor report styles and report data definitions have a different conversion path than reports built outside those standards. Reports built outside the standard Epicor report styles need to be checked against the chosen deployment path, and the inventory establishes which ones need conversion. Custom print layouts follow the same logic. The inventory step is where each report gets classified and the conversion scope gets established.
The cutover window is where the CRM integration needs a plan of its own. Before the old system goes read-only, the sync should be paused so that transactions created while the systems are switching do not create duplicate records in both environments. The order in which the endpoint is repointed matters: the CRM should be pointed to the upgraded Epicor environment only after the count reconciliation checkpoint is confirmed. Any transactions that were created during the window need to be reviewed against both systems before the sync is restarted.
The first decision is whether a documented workaround keeps the workflow running while a fix is prepared, or whether the issue stops production and requires an immediate fix. If a fix is needed, it is built and tested in the copy environment before it is moved to production. It uses the same copy as the upgrade project. The read-only version of the old system can serve as a reference for expected behavior while the fix is in progress. The fix does not go to production until it passes the same pass criteria used during the original test phase.
Before. Data that goes into the upgrade environment is the data the business operates on after go-live. Cleaning records, resolving duplicates, archiving inactive items, and correcting field-level errors after the upgrade means doing that work in the new environment under production pressure. Doing it before the upgrade means the migration moves clean data, the field-map sign-off is based on accurate records, and the count-reconciliation checkpoint reflects the state the business actually wants. Pre-migration data cleanup is part of the project, not a separate initiative.
It depends on how the environment is structured. Whether a phased approach is realistic for a specific environment depends on how companies share data, how integrations are scoped, and how customizations are distributed across entities. That cannot be determined from the outside. It comes from the inventory.
More people than IT. The inventory phase requires input from the people who use the customizations, BAQs, dashboards, and reports being reviewed. The testing phase requires business users to run role-based workflows and confirm that outputs match expectations. The cutover checkpoints require sign-off from the people who understand what the data should look like. Finance, operations, production, purchasing, and sales all have workflows that need to be verified. IT manages the environment. The business owns the acceptance criteria.
An upgrade partner should hand over the project record that upgrade tools do not produce: the inventory register with every object catalogued and classified; the test record showing what was tested, what passed, and what was fixed; the signed field map from the pre-migration checkpoint; the count reconciliation confirming that records matched before the old system went read-only; and the cutover runbook documenting every step taken during the cutover window. Those documents are the evidence that the project was run with discipline, and the reference point if anything surfaces after go-live.
It can be, if the scope is managed carefully. An upgrade project that also introduces a CRM integration or AI agents is running two change workstreams simultaneously, which increases testing complexity and the number of variables at cutover. The upgrade is a natural moment to evaluate those additions because the integration architecture is already being reviewed. Whether to execute them together or sequentially depends on the business's capacity for change and the complexity of each workstream. The inventory and path decision are good inputs to that conversation.
