Epicor Upgrade Ahead. What Should You Clean Up Before You Move?
An Epicor upgrade is easier when the business first removes obsolete forms, stale customizations, duplicate reports, weak master data and undocumented workarounds instead of carrying them forward.
The short answer
Before an Epicor upgrade, clean the environment you actually want to carry forward. Review obsolete customizations, duplicate reports, stale users and security, poor master data, unsupported integrations, unused forms and undocumented workarounds before migration work begins.
How this connects to the pillar
The specific issue of Epicor upgrade readiness cleanup sits inside the wider post-go-live governance question covered in Epicor Is Live. How Do You Build a Continuous Improvement System Around It?. This cluster focuses on the decisions and controls that make that part of the operating model reliable.
An upgrade can preserve yesterday’s problems perfectly
Technical success is not the same as operational improvement. If every old customization, duplicate query and workaround is lifted into the new release, the business may finish the project with newer software but the same complexity. Upgrade preparation is therefore a governance opportunity: decide what should survive before effort is spent testing and remediating it.
Start with an inventory of changes
Build a register of custom code, BPMs, forms, reports, dashboards, integrations, scheduled tasks, external extracts and critical manual procedures. Identify the owner and real usage of each item. Some changes will be business-critical. Others will have no current owner, no known users or a standard replacement in the target release. Unknown ownership is itself a useful risk signal.
Review standard capability before remediating custom code
An old customization may exist because the standard product could not meet the requirement years ago. Before rebuilding it, check the target Epicor capability and the current process. Replacing obsolete custom logic with governed standard functionality reduces future support and upgrade effort. The principle is not to remove differentiation; it is to stop paying to preserve history that no longer creates value.
Clean master data before migration amplifies it
Upgrades expose weak data because testing and reconciliation depend on it. Duplicate items, inactive suppliers, inconsistent units, stale warehouse locations, obsolete routings or unclear security make validation harder. Data cleanup should be scoped and prioritized rather than turned into an endless perfection project. Focus first on records that affect current transactions and critical reporting.
Test integrations as business processes
An interface can technically transmit data while the end-to-end process still fails. Upgrade testing should follow real scenarios: order release to production, receipt to invoice, shipment to finance, warehouse scan to inventory, or service completion to billing. This exposes timing, status and ownership issues that endpoint-level tests miss.
Prepare the people and decision path
Upgrade projects often lose time because nobody knows who can retire a customization or accept a process change. Assign owners before testing. Decide how defects, process changes and enhancement requests will be separated. Otherwise every user request enters the upgrade scope and the project becomes a redesign program by accident.
Upgrade-readiness checklist
Before the technical move, confirm:
- customization and integration inventory
- usage and ownership of each change
- standard replacement options in the target release
- critical master-data cleanup
- security and inactive-user review
- business-process test scenarios
- clear decision owners for retire, remediate or replace
What management should measure
Track custom objects requiring remediation, items retired, test defects by process, manual workarounds discovered, data issues blocking tests and effort spent on changes with low business value. These measures reveal where historical complexity is consuming upgrade capacity and provide evidence for a cleaner future operating model.
ACC context
With more than 20 years of Epicor experience, ACC has seen environments evolve through multiple releases, extensions and regional rollouts. That history is useful when deciding what is still strategically valuable and what should be simplified before the next platform step. Visit ACC.
Classify objects by business criticality before testing
Not every report, form or integration deserves the same test depth. Group objects by whether they affect financial integrity, customer delivery, production execution, compliance or convenience. High-criticality objects should receive end-to-end scenario testing. Low-value objects with no active owner may be candidates for retirement before the project spends effort preserving them.
Use the upgrade to simplify security
Years of role changes and temporary access can leave Epicor security difficult to explain. Review inactive users, inherited permissions, privileged roles and segregation-sensitive functions before migration. A cleaner security model reduces testing effort and makes future access reviews more meaningful.
Validate batch and scheduled processes explicitly
Scheduled integrations, exports, automations and background jobs are easy to overlook because users do not run them manually. Include them in the upgrade inventory with owner, timing and failure response. A successful interactive test does not prove that overnight or event-driven processing will behave correctly in the target environment.
Rehearse cutover with business ownership
Technical teams can move databases and applications, but business teams must know when transactions stop, what is reconciled, who approves restart and how late activity is handled. A rehearsal exposes gaps in ownership and timing before the real cutover. It also gives management a realistic view of operational risk rather than only technical readiness.
Convert lessons into a cleaner operating baseline
After the upgrade, update the architecture map, customization register and process ownership records while the knowledge is fresh. This prevents the environment from immediately becoming opaque again and gives the next improvement cycle a better starting point.
Retire unused reports and extracts
Reporting clutter creates hidden upgrade work because every query, export and scheduled task may need testing even if nobody uses it. Review actual usage and ownership. Removing abandoned reporting objects reduces noise during validation and makes it easier to identify the reports that genuinely matter to the business.
Document the current-state workaround before changing it
A workaround may look irrational until its original constraint is understood. Before removing it, document the problem it solved and the people who depend on it. This avoids deleting a symptom while leaving the underlying business need unresolved. The replacement can then be designed intentionally in the target environment.
Separate upgrade defects from improvement requests
During testing, users often discover old process frustrations and new enhancement ideas. Log them, but do not automatically treat them as upgrade defects. A defect means the target release fails to preserve required behaviour; an improvement request changes the desired behaviour. Keeping those categories separate protects scope and lets management make conscious trade-offs instead of allowing the upgrade project to absorb every historical wish list item.
Confirm operational support before go-live
The technical cutover is only one part of readiness. Confirm who monitors interfaces, who owns failed transactions, who supports warehouse or field users, and how urgent issues are escalated during the first operating days. A clean support model shortens stabilization and prevents the project team from becoming the only group capable of resolving production issues.
One final management check
Before cutover approval, ask each process owner to sign off not only that the new environment works, but that obsolete workarounds have not quietly been carried forward. This keeps the upgrade from becoming a technical migration of avoidable complexity.
Operational review point
A final upgrade-readiness review should trace several end-to-end processes using the cleaned target design and confirm that every critical dependency has an owner. Include interfaces, background jobs, reports, warehouse or field extensions and the financial consequence of each transaction chain. This gives management a business view of readiness rather than a list of technical objects. It also highlights where the upgrade would still depend on undocumented manual steps that should be resolved before cutover. Recording those dependencies also improves the support handover because the post-upgrade team knows which jobs, interfaces and controls need close monitoring during stabilization. Management should also confirm the rollback, reconciliation and communication path for any process that cannot tolerate extended downtime. This makes cutover readiness measurable in operational terms: teams know what must stop, what can continue, what evidence proves a successful restart and who has authority to make the final go/no-go decision. Those details often determine whether an upgrade feels controlled to the business even when the technical migration itself is successful.
Frequently asked questions
When should cleanup begin?
Before detailed upgrade remediation. Early inventory and ownership work prevents effort being spent on obsolete complexity.
Should every customization be rebuilt for the new release?
No. Compare each requirement with current standard capability and current business value first.
How much master-data cleanup is enough?
Prioritize active records and data that affect critical transactions, reporting and test scenarios.
What is the biggest testing mistake?
Testing technical objects without validating complete business processes and their financial or operational outcomes.
Sources
---