The Customization Works. Will the Next Upgrade Still Be Easy?
Customization becomes technical debt when nobody can explain why it exists, what it touches, whether standard capability replaced it and how it will be tested at the next upgrade.
The short answer
A customization is not a problem because it is custom. It becomes a problem when the organization cannot explain why it exists, what process depends on it, which standard capabilities overlap it, what data it changes and how it will be tested during an upgrade.
Epicor Kinetic provides structured tools for tailoring workflows and user experience, including Application Studio and cloud-oriented configuration patterns. Existing users can make upgrades easier by treating every customization as a managed product with an owner and a purpose.
Build a customization register before the upgrade starts
Do not wait for a test failure to discover what has been changed.
Create a register containing:
- customization or extension name;
- business purpose;
- process owner;
- technical owner;
- screens/data/services touched;
- integrations or reports depending on it;
- frequency of use;
- criticality;
- date last reviewed;
- replacement or retirement candidate;
- upgrade test scenario.
This turns customization from tribal knowledge into a manageable portfolio.
Ask whether the original problem still exists
A customization may have been created years ago because standard capability was missing or inconvenient at the time.
Review whether newer Epicor functionality, workflow tools or user-experience capabilities now solve the requirement more cleanly.
Retiring old logic can be more valuable than converting it.
Do not preserve a customization merely because users are familiar with it.
Separate interface changes from business logic
A field moved on a screen is different from code that changes costing, order creation or inventory behavior.
Classify changes by risk:
- user-interface personalization;
- workflow/validation;
- data field/extension;
- report/query;
- external integration;
- business logic;
- scheduled automation;
- security/role behavior.
Testing depth should follow the operational impact, not the size of the code file.
Prefer supported configuration patterns
Epicor positions Kinetic Tools & Technology and Application Studio around configurable workflows, data and user experience, and its cloud business platform emphasizes low-code/no-code personalization designed to be upgrade-resilient.
For existing users, this does not mean every legacy customization can be automatically converted. It means modernization should prefer supported extension mechanisms where they meet the business requirement.
Document any remaining custom code and the reason it cannot yet be simplified.
Integration is part of upgrade scope
An Epicor screen can look perfect while an external warehouse, EDI, e-commerce, PLM, MES or reporting integration quietly breaks because a service, field or authentication method changed.
Include integrations in the same upgrade inventory.
For each interface, test:
- endpoint/authentication;
- data contract;
- error handling;
- retry behavior;
- master-data assumptions;
- transaction timing;
- monitoring and ownership.
Do not treat “interface still connects” as proof that the business process still works.
Test business scenarios, not custom objects
A technical team can confirm that a customized form opens, but users care whether they can complete the order, shipment, production, service or close process.
Build regression scenarios around end-to-end business outcomes.
A single scenario may exercise standard Epicor, configuration, custom code and integration together — exactly how the production system will behave.
Remove duplicate logic before moving to cloud
Cloud modernization is a useful forcing function. Organizations often discover multiple versions of the same calculation across BPMs, reports, spreadsheets and external scripts.
Choose the authoritative logic and retire duplicates.
ACC's CloudMove offering is positioned around structured Epicor SaaS migration planning. Regardless of provider, migration planning should include customization rationalization rather than lift every historical decision unchanged into the new environment.
Give every customization an exit condition
When new custom work is approved, record what would allow it to retire later:
- standard Epicor feature becomes available;
- process changes;
- integration is replaced;
- regulatory need ends;
- temporary acquisition workflow is harmonized.
This prevents the environment from accumulating permanent complexity from temporary business conditions.
Track upgrade test evidence
For each critical customization, preserve the test case, expected result, actual result, tester and issue resolution.
That evidence makes the next upgrade faster because the organization does not have to rediscover what “working” means.
Automate repeatable tests where practical, but keep business-user validation for high-impact workflows.
ACC's role in modernization
With more than two decades of Epicor project experience, ACC supports enhancement, integration and migration planning across different Epicor generations. That experience is useful when an organization needs to understand which historical changes are still essential and how to move them into a cleaner architecture.
The objective should be fewer surprises, not simply a successful technical conversion.
Link upgrade resilience to the Epicor roadmap
The pillar Epicor Is Live. Where Does the Next Operational Gain Come From? treats maintainability as part of operational value.
An enhancement that saves ten minutes today but adds recurring upgrade risk should be evaluated differently from one implemented through a supported, transparent pattern.
Upgrade resilience belongs in the business case for every change.
Create a heat map of change risk
Score each customization by business criticality, technical complexity, number of dependencies and frequency of change. A small personalization used by one team is different from logic that affects order pricing, costing or inventory across every site.
Use the heat map to decide where to spend regression effort and where modernization will create the greatest reduction in future risk.
Keep a clean-room comparison environment
Where practical, maintain a representative environment with the target Epicor release and minimal customer changes. Comparing standard behavior with the customized environment helps teams distinguish product changes from local logic.
This is especially useful when users report that “the upgrade changed the process” but the difference is actually created by an old personalization or integration dependency.
Make upgrade rehearsal a business activity
Run at least one rehearsal using realistic data and end-to-end scenarios before the production window. Capture elapsed time for technical steps, data conversion, interface validation and business sign-off.
The rehearsal should end with a go/no-go checklist and rollback criteria. Upgrade confidence comes from knowing how the organization will decide, not only from knowing how the software will install.
Put a maintenance cost beside the business benefit
When approving new custom work, estimate not only build effort but also testing, documentation, support and future upgrade effort. A small enhancement repeated across many companies or screens can create a much larger long-term footprint than its initial project estimate suggests.
This does not mean rejecting useful customization. It gives the business a fuller cost of ownership and encourages designs that solve the same problem with fewer dependencies.
Document the user impact of retirement
Removing an old customization is a change-management task as well as a technical one. Identify which roles use it, what replacement workflow exists and what training or communication is required.
A retired customization that is quietly recreated in Excel or an external script has not reduced complexity. Confirm that the replacement process is accepted before closing the item from the register.
Review security when logic moves
Modernizing a customization can change which roles can see, edit or trigger a process. Include security and segregation-of-duties checks in the conversion test, especially when logic moves from a bespoke screen into a shared workflow or service.
The new design is not complete until the same business control remains understandable after the technical implementation changes.
Frequently asked questions
Should we remove all customizations before moving to SaaS?
No. Keep the changes that still deliver business value, but rationalize duplicates and move suitable logic into supported extension patterns.
Is Application Studio only for UI changes?
It supports broader application personalization and workflow configuration, but the right design depends on the requirement and Epicor release. Review current Epicor documentation for the specific capability.
Who should own the customization register?
IT can maintain it, but each item should have a business owner who can explain why the change matters and validate it after upgrade.
How often should customizations be reviewed?
At least as part of upgrade planning and major process change. High-impact or heavily used customizations deserve more frequent review.
Can ACC review an existing Epicor customization estate?
Yes. ACC supports Epicor enhancement and migration planning and can help inventory, rationalize and test changes as part of modernization work.
Make change easier to change again
The best customization is not merely one that works today. It is one whose purpose, dependencies and test path remain understandable when the business and platform move again.
That discipline turns upgrade resilience from an IT emergency into a normal part of Epicor governance.