How can a manufacturer verify that a firm is an authorized Epicor partner?

Check the firm in Epicor's partner directory first, because the directory confirms that the partner relationship with Epicor exists. Then ask the partner directly for its Epicor partner level and for evidence that its team holds current Epicor product certifications. The two checks answer different questions. The directory confirms the relationship. The certifications confirm that the people who will do the work on your project are current on the platform. Both checks are worth doing before you sign a statement of work with any partner.

What should an Epicor Kinetic implementation statement of work include?

The statement of work should define scope in enough detail that additions require a formal change order. It should name the partner's project team, define the change order process, state how data migration is handled including trial loads and reconciliation, describe training by role and timing relative to go-live, define post-go-live support including what is included and what is not, and address CRM integration if it is in scope. Anything left undefined in the statement of work is resolved later, under pressure, when it is hardest to change.

What changes for the buyer between a fixed-price and a time-and-materials implementation?

Under a fixed-price model, the scope must be defined precisely before the engagement starts. Additions require a change order, which means the business controls what it commits to. Under a time-and-materials model, the business pays for the time the partner spends, which means scope growth is the business's financial exposure. Neither model eliminates risk. Fixed-price shifts risk to the partner when scope is well-defined. Time-and-materials shifts risk to the buyer when scope is open. The right model depends on how well the business can define its requirements before the project starts.

Who should own an Epicor Kinetic implementation inside the manufacturer?

One person, with decision-making authority and committed time. That person needs to be senior enough to resolve disagreements across departments, available enough to respond to decisions in a reasonable timeframe, and empowered to say yes or no without escalating every call. A committee cannot own an implementation. A person who is assigned the role but not given the time cannot own it either. This is a resourcing decision that needs to be made before the project starts, not after it is already running.

What happens if key users cannot be released from daily work during the implementation?

Decisions get deferred, testing gets compressed, and gaps arrive at go-live. The partner cannot configure processes it does not understand, and it cannot test scenarios that the business has not reviewed. If key users are not available, the project either slows to match their availability or proceeds without their input. Neither outcome is acceptable. The solution is a resourcing plan agreed before kickoff, with the business's leadership committed to protecting the time of the people the project depends on.

Should a manufacturer customize Kinetic or change its processes to fit the standard system?

Both options are valid. The question is which gaps are genuinely business-critical and which are habits. Standard Kinetic processes are tested, supported, and upgradeable. Customizations add maintenance overhead and can complicate future upgrades. The practical approach is to start from the standard system, identify the gaps that would materially affect operations, and customize only those. Gaps that reflect preference rather than operational necessity are candidates for process change. The business has to make that judgment. The partner can advise on the technical impact of each customization, but it cannot decide which processes are worth preserving.

What data should stay behind in the legacy system instead of moving to Kinetic?

Historical transaction detail that the business does not need for day-to-day operations or active reporting is a candidate to leave behind. This includes closed orders, completed work orders, and archived financial periods beyond what audit or regulatory requirements demand. The legacy system remains accessible after go-live, so history does not disappear. What comes forward is master data (items, BOMs, routings, customers, suppliers) and open transactions (open sales orders, purchase orders, work orders, open AP and AR balances). The decision on historical depth requires input from finance and whoever manages the business's audit or compliance obligations.

What does an implementation partner need from the business before discovery starts?

Access to the people who understand the current processes, not just the people who manage them. A list of the systems currently in use and which will remain after go-live. A clear statement of which manufacturing modes the business operates in. An initial view of data volumes and data quality in the legacy system. And a named internal project owner with the authority to make decisions. Discovery cannot produce a useful design if the partner is working from assumptions rather than facts. The more the business prepares before discovery, the more useful the output.

What should support after go-live cover, and for how long should it be defined?

Support after go-live should cover the stabilization period immediately after cutover, when users are operating on the new system for the first time and issues surface quickly. It should define response times, who is available, and what categories of issue are included. It should also define what falls outside the support scope and requires a separate engagement. The duration and scope of support should be stated in the contract before go-live, not negotiated after cutover when the business has no leverage. How long that period runs is a commercial decision between the business and the partner.

What is the difference between Epicor's own implementation services and an Epicor partner?

There is no published bright line between what Epicor delivers directly and what an Epicor partner delivers. Epicor publishes a methodology and offers services, but the split between Epicor-delivered and partner-delivered work varies by engagement. Before signing with any partner, ask specifically: what does Epicor deliver directly on this project, and what does your team deliver? Get a specific answer, not a description of the methodology. The answer tells you who is accountable for what, and where to go when something needs to be resolved.

Epicor Kinetic Implementation: Choosing a Partner

Replacing a legacy system with Epicor Kinetic is one of the larger operational decisions a manufacturer makes. The software is capable. The methodology exists. What determines whether the project delivers is what the business decides and owns before kickoff, and whether the partner it chooses can execute in its specific environment.

This guide is written for the person who will sign the statement of work. It covers what a Kinetic implementation actually involves, where projects stall, the data work only the business can do, and how to evaluate any implementation partner before committing.

What an Epicor Kinetic Implementation Is, and What It Is Not

An Epicor Kinetic implementation is the process of replacing a legacy or non-Epicor ERP system with Kinetic as the operational backbone of the business. It covers the full scope: system configuration, process design, data migration, integration with connected systems, training, and go-live.

It is not an upgrade. If you already run Epicor 10 and are moving to Kinetic, that is a separate track with its own considerations. See Epicor 10 to Kinetic: What the Upgrade Involves for that path.

It is also not a product decision. If you are still evaluating whether Kinetic is the right platform for your operation, start with Epicor Kinetic vs. Epicor ERP: What Changed and Whether to Move. This guide assumes the decision is made and the project is being scoped.

What Epicor provides and what it does not

Epicor gives you the license, a methodology, and a large partner network. The day-to-day execution of the project sits with the implementation team, and the line between what Epicor delivers and what a partner delivers is set engagement by engagement. That means the quality of the project depends on which partner you choose, how that partner is staffed, and how clearly the statement of work defines scope, price, and accountability.

Understanding this distinction early changes how a buyer approaches the evaluation. You are not just buying software. You are selecting the team that will run a project that touches every part of your operation.

What the Business Has to Decide Before Kickoff

The decisions that determine whether a Kinetic implementation succeeds are made before the partner starts configuring anything. A manufacturer that defers these decisions hands control of the project to the partner by default. That is how scope grows and timelines slip.

Assign an internal project owner with real authority

The implementation needs one person inside the business who owns it. Not a committee. Not a rotating responsibility. One person with decision-making authority, enough time committed to the project, and the organizational standing to resolve disagreements across departments.

Implementations stall when no one inside the business has the authority to make a call and make it stick. The partner can advise. The partner cannot decide for you.

Assign a process owner for each functional area

Beyond the project owner, each major functional area needs someone who understands the current process and can sign off on how it will work in Kinetic. The areas that need coverage:

Quote-to-cash: how orders are created, priced, and invoiced
Order-to-ship: how production orders are released and fulfilled
Purchasing: how purchase orders are created, received, and matched
Inventory: how items are tracked, counted, and valued
Scheduling: how production is planned and sequenced
Finance: how the general ledger, AP, and AR are structured

These are not IT decisions. They are operational decisions that happen to have system consequences.

Decide which manufacturing mode drives the design

Kinetic supports multiple manufacturing modes: make-to-stock, make-to-order, engineer-to-order, configure-to-order, and mixed environments. The mode that describes your operation drives the configuration design. A partner who does not ask this question early is not designing for your environment.

Decide whether to adopt standard processes or keep your current ones

This decision shapes the whole project, and it is easy to leave unspoken until design is under way. Standard Kinetic processes exist for a reason. They are tested, supported, and upgradeable. Customizing away from them creates a system that is harder to maintain and harder to upgrade.

The question is not whether to customize at all. It is which gaps are genuinely business-critical and which are habits that can be changed. That decision belongs to the business, not the partner.

Decide which systems stay and connect

Kinetic will not replace every system in the business. Identify which systems remain in place after go-live and which integrations need to be built or maintained. This includes shop-floor systems, quality systems, warehouse management, and any customer-facing tools.

Decide whether CRM is in the plan

If the business uses a CRM, or plans to, the time to plan that integration is before Kinetic goes live, not after. The customer master and pricing logic get designed once if the plan exists from the start. Designing them a second time after go-live means reopening decisions the business is already running on. For how the integration works, see the CRM-ERP integration service page.

Where Epicor Kinetic Implementations Stall

Practitioners who have been through Kinetic implementations describe the risks below in their own project threads. None of these are inevitable. All of them are addressable during planning, but only if they are identified before the project starts.

Scope that grows after discovery

Discovery surfaces requirements the initial proposal did not include. That is expected. The risk is when those requirements are added to the project without a corresponding adjustment to the statement of work, the price, or the timeline. Scope growth that is not formally controlled becomes the partner's problem on paper and the business's problem in practice.

Before signing, understand how the statement of work handles change. What triggers a change order? Who approves it? What happens to the go-live date when scope changes?

Data cleanup started too late

Data migration is not a technical task the partner handles in the background. It requires the business to make decisions: what records are current, what is obsolete, what needs to be corrected before it moves. That work depends on people inside the business, and it cannot start until the business engages.

Implementations that defer data cleanup until late in the project arrive at cutover with unresolved records. The partner cannot clean data it does not own.

Rebuilding the old system through customization

Customization is not inherently wrong. The risk is customization that recreates the legacy system's logic inside Kinetic rather than evaluating whether that logic still serves the business. Each customization adds maintenance overhead, complicates future upgrades, and can create dependencies the partner did not document.

The discipline required is business discipline, not technical discipline. Someone inside the business has to be willing to question whether a current process needs to be preserved or whether it is simply familiar.

Key users pulled back to daily work

Implementations require sustained time from people who also run the business. When production pressures pull key users back to their day jobs, the project loses the people who understand the processes being configured. Decisions get deferred, testing gets compressed, and go-live arrives with gaps that surface after cutover.

This is a resource planning problem, not a project management problem. It needs to be solved before the project starts, not managed around during it.

Training disconnected from go-live

Training delivered too early is forgotten by go-live. Training delivered too late leaves users unprepared. The timing, format, and depth of training need to be defined in the statement of work, not left to the partner's standard approach. Role-based training, delivered close to go-live and reinforced during stabilization, keeps what users learn connected to the system they will actually run.

No internal owner with authority

This risk is listed last because it amplifies every other risk on this list. Without an internal owner who has real authority and committed time, decisions get escalated, deferred, or made by the wrong person. The partner fills the vacuum with its own judgment, which may not reflect the business's actual priorities.

The Data Work Only the Business Can Do

Data migration is where buyers can assume the partner takes over. In practice, the business owns the decisions that determine whether the migration succeeds. The partner can execute the technical load. It cannot decide what the business's data should look like.

Decide what history to bring forward

Not all data from the legacy system belongs in Kinetic. The question is not what can be migrated. It is what the business needs to operate, report, and audit after go-live.

Master data comes forward: items, bills of material, routings, customers, suppliers. Open transactions come forward: open sales orders, open purchase orders, open work orders, open accounts payable and accounts receivable balances. Historical transaction detail, such as closed orders, completed work orders, and archived financials, is a separate decision. Bringing it forward adds migration scope and complexity. Leaving it behind means it stays accessible only in the legacy system.

That decision requires input from finance, operations, and whoever manages regulatory or audit requirements. The partner can advise on the technical implications. The business has to make the call.

Clean the records before migration starts

The legacy system's data reflects the whole life of that system, which means it also reflects its workarounds, inconsistencies, duplicate records, and obsolete entries. Item masters with missing fields, customer records with conflicting addresses, BOMs that no longer match the current product, suppliers that are no longer active: all of it comes forward unless the business reviews and corrects it first.

Data profiling, examining the legacy data before migration begins, is the step that makes the scope of cleanup visible. It is also the step that gets compressed when the project timeline is tight. The effect of skipping it shows up at cutover, when records that should have been corrected arrive in Kinetic in their uncorrected state.

Own the reconciliation sign-off

Before cutover, the migration needs to be verified. Trial loads are run, counts are compared, and discrepancies are resolved. That verification requires someone from the business who understands what the numbers should be, not just what they are.

The implementation partner runs the trial loads. The business signs off on the reconciliation. If no one inside the business has the knowledge or the time to do that, the sign-off becomes a formality rather than a check. That is a risk that surfaces after go-live, not before.

How to Evaluate an Epicor Kinetic Implementation Partner

The criteria below apply to any partner. Use them in every conversation before you sign.

Verifiable Epicor partner status

Ask the partner for its Epicor partner level and for evidence that its team holds current Epicor product certifications. Then check the partner in Epicor's partner directory. These are not the same question. The directory confirms the relationship exists. The certifications confirm the people doing the work are current on the platform.

Experience in your manufacturing mode

A partner with strong make-to-stock experience is not automatically the right choice for an engineer-to-order environment. Ask for references from manufacturers whose operations resemble yours, not just manufacturers in your industry. The mode matters more than the sector.

For manufacturers with shop-floor data capture requirements, ask specifically how the partner has handled advanced manufacturing execution in prior projects.

Who actually staffs the project

The team that presents during the sales process is not always the team that runs the implementation. Ask who specifically will be assigned to your project: the project manager, the functional consultants, the technical resources. Ask what happens if a key team member leaves mid-project. Get the answer in the statement of work.

How scope and price are structured

Understand whether the engagement is fixed-price for defined scope or time-and-materials. Each model places different obligations on the business. Under a fixed-price model, scope definition at the outset is critical. Under time-and-materials, the business carries the risk of scope growth. Neither model is inherently better, but the buyer needs to understand what each one means for their exposure.

Data migration approach

Ask how the partner handles trial loads and reconciliation. Ask who is responsible for data profiling and when it starts. Ask what the partner expects the business to provide and in what format. A partner who cannot answer these questions in detail has not thought through the migration.

Training approach

Ask whether training is role-based. Ask when it is delivered relative to go-live. Ask what happens during the stabilization period after cutover. Training that is not tied to the actual go-live date and the actual roles of the users is not a training plan.

Support after go-live

Ask what support looks like after cutover. Ask how it is structured, what is included, and what requires a separate engagement. Get it defined in the contract before you sign.

CRM and integration capability

If CRM integration is part of the plan, ask whether the partner has built that integration before, in what systems, and whether it can be scoped at the same time as the ERP. A partner who treats CRM as a post-go-live add-on is not planning the project correctly.

Language and geography

For manufacturers with plants in multiple countries, ask whether the partner can support the implementation in the languages and time zones where the work will happen.

Technology Coast Partners (TCP) is an Epicor Platinum Partner that has run Kinetic implementations for over a decade in both English and Spanish. Clients include Greenpaper, Tecnas, IPSL, and IMPELMEX, all in Mexico.

See how TCP runs Kinetic implementations

Talk to TCP about your Kinetic implementation

Questions to Ask Before You Sign

Take these into any partner meeting. They are not a pitch. They are the questions a buyer needs answered before committing to a statement of work.

On scope and accountability:

What is included in the fixed scope, and what triggers a change order?
Who from your team will be assigned to this project by name?
What happens to the timeline and price if a key team member changes?

On your manufacturing environment:

Have you implemented Kinetic for manufacturers in our mode (engineer-to-order, configure-to-order, make-to-order, make-to-stock)?
Can you provide references from manufacturers whose operations resemble ours?

On data migration:

When does data profiling start, and who is responsible for it?
How many trial loads are included, and how is reconciliation verified?
What does the business need to prepare, and by when?

On training:

Is training role-based and shift-based?
When is it delivered relative to go-live?
What does the stabilization period cover, and for how long is it defined in the contract?

On the statement of work:

Does the statement of work name the project team?
Does it define the change order process?
Does it define support after go-live, including what is included and what is not?
If CRM integration is in scope, is it defined in this statement of work or a separate one?

On Epicor's role:

What does Epicor deliver directly on this engagement, and what does your team deliver?

A partner who cannot answer these questions specifically, before the statement of work is signed, is not ready to run the project.

If you are planning an Epicor Kinetic implementation, TCP scopes it at a fixed price, with the CRM planned from the start and cutover planned around production.