Following on from our recent post regarding the Epicor Support changes, Epicor has completed an FAQ’s to help businesses with Epicor ERP understand what the new Product Maintenance Methodology means for their business. There are three sections New Product Maintenance Methodology, Frequency and Updates. If after reading the FAQ’s you still have questions don’t hesitate to get in touch with us
Question: What is new about our product maintenance methodology in Epicor ERP 10.1 onward?
Answer: With the release of Epicor ERP 10.1, we have updated our product nomenclature, regulated the frequency of releases and the way in which we provide fixes to our customers.
Question: What is the Epicor ERP 10.1 product naming nomenclature?
Answer: The product number has 4 segments. For example, the current product release is 10.1.400.5. Using this example, the segments are explained as follows:
is the Product segment, which is typically incremented as a result of significant architectural enhancements.
is the Version segment, which is typically incremented as a result of significant product application enhancements.
is the Release segment, which is typically incremented as a result of legislative and local application enhancements.
is the Update segment, which is incremented every few weeks and will ONLY contain bug fixes that will have no
impact to our customer’s product configurations.
Question: How frequently are Product segments incremented?
Answer: Seldom. Our last Product increment was in 2014 as a result of a technology stack change.
Question: How frequently are Version segments incremented?
Answer: We expect these to be about every 1 to 2 years. Our last Version increment was in December 2015.
Question: How frequently are Release segments incremented?
Answer: We expect these to be about every 6 months or so. Our last Release increment was in December 2015 (at the same time as our last version increment).
Question: In general, how frequently are Update segments incremented?
Question: Given the frequency of the Updates, do you expect customers to apply all Updates?
Answer: For On-Premise and Hosted customers, yes, we would recommend that customers apply every Update. Updates are now restricted to providing bug fixes only and are not disruptive to our customer’s product configuration. For Cloud ERP, Single Tenant and Express customers, the Cloud Operations team will apply Updates firstly to pilot and then to production following their Cloud Maintenance Schedule.
Question: How can you ensure that Updates are not disruptive to a Customer’s product configuration?
Answer: As part of our automated build and release process, all software included in an Update is automatically validated to ensure that it complies strictly with a series of rules to ensure that the software fixes will not affect any public interfaces within the product. For example, no impact to any UI Customizations, BPMs, Custom Reports or Integrations and no DB Schema changes.
Question: If I decided not to apply an Update, would I be able to apply the following or subsequent Updates?
Answer: For On-Premise and Hosted customers, yes. Updates are cumulative, which means that all bug fixes from Update 1 will also be included in Update 2 in addition to Update 2’s bug fixes; all bug fixes in Update 2 will also be included in Update 3 in addition to Update 3’s bug fixes and so on. Given the frequency of Updates, the net number of additional fixes added to any given Update will be limited, which will facilitate a swift, focused UAT for our customers. However, this would be negated, should a customer decide not to keep current with applying Updates as the delta would increase each time. For Cloud ERP, Single Tenant and Express customers, the Cloud Operations team will apply Updates firstly to pilot and then to production following their Cloud Maintenance Schedule.
Question: What if I think I have found a potential bug, how can I request a fix under this new maintenance methodology?
Answer: You would contact Epicor Support as normal. If they are able to replicate the bug in the latest released Update, they will report the bug to Epicor Development and depending on the severity of the bug and the impact to your business, Epicor Support may request a fix on your behalf to be included in a future Update. An SCR (Software Change Request) will be created by Epicor Development for tracking purposes and Epicor Support will then inform you of the SCR number, the targeted Update number and its release date.
Question: What information is required by Epicor Support in order for them to request a fix on my behalf via an Update rather than wait for the next Release level?
Answer: You would need to provide the following information:
Question: What if the targeted Update release date I am given is too far into the future for me?
Answer: You can contact Epicor Support and quote the Epicor Support Call number and the SCR number and request that the target Update be reviewed to see if it can be brought forward to an earlier Update. You will need to provide the reason for your request and the impact to your business.
Question: What if the targeted Update is revised earlier but is still too far into the future for me?
Answer: You can contact Epicor Support and ask that your fix request be escalated, providing the reason for your escalation request.
Question: Will there be exceptions to these Update rules?
Answer: Occasionally, we may need to issue out-of-cycle Compliance Updates which may include functionality for legislation or compliance reasons. However, these will be identified very clearly so that our customers understand the reasons and business impact. The numbering of these Updates will increment by 100, making them easily recognizable. For example, following 10.1.400.12 let us say that we need to issue a Compliance Update, so this would be 10.1.400.100. From that point, normal Updates would then resume and be numbered .101 then .102 and so on.
Should you have any queries don’t hesitate to call us on +353 (0)1 461 1700 or +44 (0)845 862 0864 or Contact us