Manufacturing
Epicor on-prem sunset: what to do with your historical data
By SourceX Editorial · Updated
Short answer
Before an Epicor on-prem server is retired, convert open items to the next platform, keep closed history in a read-only archive, and review that archive for licensing while the system still runs. Epicor has said on the EpiUsers community forum that Kinetic on-premises development ends in 2028, so confirm your version's dates in writing.
Key takeaways
- Epicor has said on-premises Kinetic development ends in 2028; an end to development is not an end to support, so confirm your version's dates in writing.
- A cloud move usually carries open items and balances, not the full closed history held in an on-prem database.
- Customizations such as BPMs, UD fields and BAQs hold meaning that must be documented before the server is retired.
- Older Vantage, Vista or Epicor 9 databases kept for reference belong in the same decision.
- The archive extraction is the right moment for a metadata-only licensing fit check.
What has Epicor said about on-premises Kinetic?#
Epicor has said that on-premises development of Kinetic ends in 2028 and that innovation is moving to the cloud. The statement comes from a post by Epicor on the EpiUsers community forum, titled 'Epicor Kinetic Innovation Moves to the Cloud: On-Premises Development Ends in 2028'. The same post says Epicor is outlining export options covering data plus attachments, and which exports can be automated through APIs and reporting versus which need assistance.
An end to development is not the same as an end to support, or to your right to keep running the software. Those dates depend on your product, version and contract, and a forum post is not a contract. Ask Epicor or your partner, in writing, for the points below, and keep the answers with your ERP contract file so the next budget discussion starts from facts.
- The final on-premises release available for your product line
- The end of standard support for the version you run today
- Whether your license allows continued use without a maintenance plan
- The supported migration path and how much history it carries
- Which exports of data and attachments are automated through APIs and reporting, and which need Epicor's assistance
- How customizations are treated: BPMs, UD fields, BAQs, dashboards and reports
- Which third-party products and integrations depend on your on-prem database
What the change means for your historical data#
The change matters most for historical data because an on-prem Epicor database often holds many years of closed quotes, orders, jobs, labor, part transactions and quality records that no migration plan intends to carry forward. When the server is retired, that history goes with it unless someone decides otherwise.
Many Epicor sites also keep older databases from Vantage, Vista or Epicor 9 that were never fully converted during past upgrades. These sit on a server few people remember how to open. A sunset decision is the moment to decide their fate too, rather than discovering them during a hardware refresh.
The meaning of the data is spread across customizations. UD fields and tables, BPM directives and BAQs encode how the company actually used the system; without notes on what each one did, an archive of raw tables is hard to interpret later.
Your options for Epicor history, compared#
Epicor history has five realistic paths, and most companies combine at least two of them. The comparison below assumes the company is moving off on-premises Epicor, whether to Epicor's cloud or to another ERP.
Two combinations are common. Companies staying with Epicor often pair the cloud migration with a read-only archive of closed history; companies leaving Epicor pair a new ERP with the same kind of archive. Either way, the archive is where a licensing review happens, so its completeness decides what is possible later.
| Option | What happens to history | Good fit when | Watch for |
|---|---|---|---|
| Stay on the last on-prem release | History stays in place for now | The business needs time and the license allows continued use | Shrinking support, security patching and integrations |
| Migrate to Epicor cloud | Open items and balances move; closed history depends on the plan | You want to stay with Epicor and its processes | Assuming the full history moves without asking |
| Move to another ERP | Open items convert; history needs its own plan | The business has outgrown Epicor or is consolidating systems | Mapping custom fields and old part numbering |
| Read-only archive | Closed history kept searchable outside the ERP | Traceability, audits, warranty and requoting still need old records | Losing schema knowledge and attachment links |
| Licensing review before retirement | Archive assessed on metadata for a possible license | Long, linked quote, job and quality history exists | Customer drawings and export-controlled jobs in the data |
Why the sunset is a natural moment for a licensing review#
A sunset is a natural moment for a licensing review because the archive extraction, the system knowledge and the decision-makers are all in place at once. After the server is gone, the person who wrote the BPMs may have left and the restore process may no longer work.
Long Epicor histories can matter to AI developers building systems that quote, schedule, plan materials or handle quality decisions. Quotes that record whether the work was won, jobs that compare estimated with actual hours, and nonconformances and DMRs with their dispositions are records of manufacturing judgment that are hard to find elsewhere.
The first step shares nothing. A fit check covers which modules were used, how many years are accessible, which record families link together and which restrictions apply, such as customer-owned drawings attached to parts or jobs under export control. Data that proceeds is licensed, not sold, and the company keeps ownership.
Illustrative: a machine builder on an older on-prem release#
Illustrative: a fictional builder of packaging machinery runs Epicor on premises, with an older Vantage database kept on a separate server for reference. Leadership decides to move to Epicor's cloud but learns the migration plan covers open orders, open jobs, inventory, active parts and balances only.
The CFO asks IT to export both databases into a read-only archive with a written data dictionary covering UD fields and the main BPMs. Before the old servers are retired, the company runs a metadata fit check.
Customer-specific engineering for one large account is flagged for exclusion. The quote, job, field service and nonconformance history for the company's own machines moves into a licensing review, and the archive doubles as the lookup system for service and warranty questions.
A planning sequence for the next budget cycle#
A planning sequence keeps the history decision from being made by default during cutover. The steps below fit inside an ordinary budget cycle and do not depend on the final migration date.
Assign each step an owner. Finance usually owns retention and the archive budget, IT owns extraction and documentation, and quality owns the traceability requirements that decide which links must survive.
- Confirm dates and license terms for your version in writing
- List every Epicor database, including test copies and older Vantage, Vista or Epicor 9 databases
- Decide which open items and how much recent history the migration will carry
- Document UD fields, BPMs, BAQs and reason codes before the people who built them move on
- Build and test a read-only archive, including attachments and their links
- Run a metadata-only licensing fit check on the archive
- Set retention and destruction rules, and check for legal holds before deleting anything
How SourceX handles a retiring Epicor database#
SourceX treats a retiring Epicor database as possible supply in the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check works from a description of modules used, years accessible and record families, the company keeps its data in its own storage, and nothing moves during the initial assessment.
If a package proceeds, Rights and Preparation remove customer drawings, jobs under export control and the personal details of employees and customers, and the company approves the final scope. The data dictionary written for the archive, covering UD fields, BPMs and reason codes, becomes part of the SourceX Evidence Packet that documents the package.
Frequently asked questions
Will Epicor's cloud migration bring over all of our history?
Not necessarily. Migration scope is set by the plan you agree with Epicor or your partner, and many plans focus on open transactions, balances and active master data. Ask specifically which closed history is included, how far back it goes, and what happens to attachments and custom fields.
Can we keep running our current on-prem version after support ends?
That depends on your license and maintenance agreement, so check the contract and confirm with Epicor. Even where continued use is allowed, running an unsupported ERP raises security, compatibility and staffing questions that grow over time, which is why many companies treat it as a bridge rather than a plan.
What should we do with an old Vantage or Vista database?
Decide deliberately. Old databases often hold the longest history the company has. Restore and test them while someone still can, export them into the same read-only archive as the current database, and include them in the licensing fit check rather than deleting them unseen.
Is Epicor data different from other ERP data for licensing?
The licensing questions are the same for any ERP: rights, privacy and depth of linked history. Epicor sites often have rich job, labor and quality records because the system is used on the shop floor, which can make the history more useful than a finance-only ERP.
Does a licensing review delay the migration?
It should not. The review runs on metadata and on the archive, which is built for retention reasons anyway, so it sits alongside the migration rather than in its path. The migration team keeps its own timeline; the review only needs the archive to exist before the old server is wiped.
What if a partner hosts our Epicor environment?
Check the hosting agreement for data return and deletion terms, and ask for a full database export, including attachments, before the arrangement ends. Formats, fees and deadlines for that export vary by agreement, so get them in writing and test the export before the hosted environment is shut down.
If we move to Epicor's cloud, how do we get our data out later?
Read the cloud subscription agreement for data return, export formats, fees and deletion timelines at termination before you sign. Those terms decide how you retrieve history at exit, and they are easier to clarify at the start than at the end. Keeping your own read-only archive of pre-migration history also means the oldest records never depend on the subscription.
Sources
- An Epicor post on the EpiUsers forum, titled 'Epicor Kinetic Innovation Moves to the Cloud: On-Premises Development Ends in 2028', says Epicor is outlining export options (data plus attachments) and which exports can be automated through APIs and reporting versus which need assistance. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.