Most manufacturers approaching an Epicor cloud migration start by asking what needs to move. That’s the wrong first question. The right one is why each customization exists in the first place, because the answer changes what you migrate, what you fix, and what you retire before the project even begins. This post works through that process in order.
You cannot scope a cloud migration without a clear picture of what’s running in your environment. Not what’s documented. What’s actually there.
Most on-premises Kinetic environments accumulate customizations across years of operation. Some were built deliberately, with a clear business requirement behind them. Others were added to work around a problem and never revisited. A significant portion exists somewhere in between: still running, still depended upon, but with no current owner who can explain the original intent.
The inventory is what makes the rest of the preparation work possible. Without it, migration scope estimates are guesswork.
A complete customization inventory for an Epicor cloud migration covers more ground than most teams expect. At minimum it should include:
The gap between what a team believes is in their environment and what the inventory actually surfaces is almost always wider than expected. In environments that have been running for five years or more, it is not unusual to find active BPMs nobody on the current team has touched, reports that finance runs monthly but cannot describe the logic behind, and integrations held together by a scheduled task nobody monitors.
That gap is where migration projects lose weeks.
Once the inventory is complete, the next step is to assess each item. Not to decide whether it migrates, but to understand why it exists. That distinction drives everything that follows.
In TeccWeb’s experience working through pre-migration assessments on on-premises Kinetic environments, most customizations fall into one of two categories.
Some customizations exist because the standard Epicor configuration genuinely cannot handle a specific business need. A BPM that enforces an approval workflow not supported out of the box. A report that combines data from multiple modules in a format the business requires for customer invoicing. A custom field that captures information specific to the manufacturer’s product or process.
These customizations have a clear owner, a documented purpose, and a business consequence if they disappear. They belong in the migration. The work is to convert them correctly for the cloud environment, not to question whether they should exist.
This is the category most migration guides don’t address honestly. A meaningful portion of the customizations in a typical on-premises Epicor environment aren’t solving business requirements. They are compensating for configuration decisions made at implementation, or shortly after, that were never corrected.
A BPM that forces a field to populate on every sales order might look like a business rule. It might actually be hiding the fact that the default field setup was never configured correctly. A custom report that recalculates a margin figure might look like a reporting need. It might be working around a costing method that was set up wrong years ago and has been producing slightly incorrect numbers ever since.
When TeccWeb walks into an on-premises environment ahead of a migration, this pattern comes up consistently. The team is aware the customization exists. Nobody questions it because it works. But migrating it into the cloud means carrying the original configuration problem into the new environment, wrapped in code that now needs to be maintained in a different architecture.
The cloud migration is the best opportunity most manufacturers will have to fix these problems rather than move them. Taking that opportunity requires asking why each customization exists before deciding what to do with it.
Two areas surface more consistently than others when this preparation work isn’t done properly.
Method Directives are hooked on a business object method, making them easier to scope and the preferred solution. Data Directives can be triggered by any transaction on a specified table and require careful conditions and thorough testing.
In on-premises environments, loosely scoped Data Directives that fire against full tables are a known performance risk. In cloud environments, where you do not control the underlying infrastructure and cannot tune the server to compensate, that risk has fewer places to go. The same directive that ran acceptably on-prem may behave unpredictably when it cannot be isolated or optimized at the infrastructure level.
Before migrating any BPM, review the directive type, the trigger conditions, and whether the logic it enforces is genuinely a business rule or a patch on a base configuration gap.
BPMs with embedded C# that call file system paths will break in a cloud environment. File system I/O access is not permitted in Epicor’s cloud hosting. BPMs that depend on advanced C# capabilities, including external method calls and certain library references, face additional restrictions: advanced BPM user rights are not available to Epicor cloud users. Any BPM that relies on these capabilities needs to be identified and rearchitected before migration, not after.
Legacy SSRS reports often rely on outdated data structures or queries that break in Kinetic. Report conversions frequently delay Epicor upgrades and create unexpected reporting failures.
The delay is rarely caused by the conversion itself. It is caused by discovering mid-project that a report was built to compensate for a data or costing setup problem, and that the underlying issue was never fixed. Converting the report moves the workaround into the new environment. Fixing the underlying setup problem first removes the need for the workaround entirely, or at minimum clarifies what the converted report actually needs to do.
Crystal Reports will not work cleanly in a cloud environment. All bug fixes and updates are SSRS only. Any Crystal Reports still in use need to be converted to SSRS before a cloud migration, not treated as a migration task to handle later.
BPM logic and directives generally import into the cloud environment. That is not the same as working correctly. A BPM that imports successfully can still fail at runtime if it relies on file system access, restricted C# capabilities, or external method calls that are not permitted in cloud. Importing is the beginning of the review, not the end of it.
A customization is a candidate for retirement if it has no named owner who understands its original purpose, has not been modified in several years, or exists to compensate for a configuration setup that can now be corrected in base Epicor. Retiring it rather than migrating it reduces migration scope and removes technical debt from the new environment. The decision requires judgment about the business context, which is why this assessment benefits from a consulting partner with hands-on Epicor experience rather than a checklist.
It depends on the size and complexity of the environment. A relatively standard deployment with a manageable number of customizations and integrations can be assessed in a few weeks. An environment with years of accumulated BPMs, custom reports, multiple integrations, and undocumented configuration changes takes longer. The assessment is not the migration. It is the work that makes the migration scope accurate and the timeline realistic.
The technical work of an Epicor cloud migration is manageable when you know what you’re dealing with. The harder part is knowing what you’re dealing with, and that requires experience working through real on-premises environments, not just familiarity with the Epicor platform.
TeccWeb has done this assessment work with manufacturers running on-premises Kinetic across a range of complexity levels. We know where configuration patches tend to hide inside what looks like intentional customization. We know how to separate what should migrate from what should be fixed first, and how to turn that assessment into a migration plan that reflects how the business actually runs.
If you’re preparing for a cloud migration and want a clear picture of what’s in your environment before committing to a scope and timeline, get in touch with TeccWeb.
