Your personal, professional EPICOR ERP services seneschal.
Allan could not believe we were in St Petersburg, FL and was pleasantly surprised when we visited him in person the next day. His customized programs were only BAQs and BPMs and absolutely no impediment to the upgrade. Today, Emcee is using EPICOR 10.2.300.
If you are in Florida, Wisconsin, California or Illinois then you’ve found a personal, professional services firm to make your EPICOR upgrade happen without disruption to your business. Pronto Progress specializes in Technical and Functional upgrades of EPICOR. Actually, we rescue upgrades.
Sometimes it is vital to be on site. Face to face communication is so very important. It is truly amazing how much non-verbal communication happens between people. Estimates of just body language communication approach 55%!
Probably you're disappointed with an upgrade that failed as was Alan Barbario from Emcee in Venice, FL? Perhaps you're convinced EPICOR will never run quickly, as was Chris Lieber from ASSA ABLOY in Atlanta, GA even on Vantage 8.03.
Maybe, like Tony Chircharillo of Chirch Global Manufacturing in Illinois, you were fatigued and sick of asking EPICOR how to get order and job profit reporting on EPICOR 9.05 SAAS.
Vicki definitely doesn’t like to be promised something without delivery as happened with Judith Nickse of New England Machinery in Bradenton, FL.
Vicki does not need to be the smartest person in the room, oh no! She’ll expect Pronto Progress to be the smartest person in the room about the EPICOR ERP and the processes and procedures that apply to her company. Nay! Nay! She relies on Pronto Progress knowing, finding or proposing the solution because she already has too many plates spinning on poles.
Vicki relies on Pronto Progress to test, validate and train her user community along every upgrade step. Maintaining customizations and improving functional utilization of EPICOR is another one of those skills that Vicki relies on in her seneschal, Pronto Progress.
Running legacy ERP systems, whether or not they are on a supported upgrade path, can present a number of business challenges. These can be summarized into the following two areas:
- Technical
- Functional
The technical challenges are many, and the risks to business continuity high. These risks all lead to one place – the legacy hardware and the server operating systems. The IT Director probably asked these questions, but you already knew the answer before they were asked:
- What happens if my server fails?
- How long will it take to get my legacy system up and running from a hardware failure – will I even be able to get my system running again?
- Will the company survive a significant hardware-based disruption?
- How much data could I lose in a hardware failure?
- What is my backups policy and where do I keep these backups?
- When was the last time you tested the backup?
- How do I protect my system from ransomware, viruses, or intrusions – how can I protect the company when the OS is no longer supported?
- How will I support or integrate new hardware and software with my legacy system?
- What is the DR plan or perhaps Is there are DR plan?
Perhaps you have already identified these risks and attempted to mitigate them by virtualizing the operating system, hardware, and 3rd party drivers; however, this will only get you so far and the risks can only continue to grow with time. As of Nov 2018:
- Windows Server NT and 2003 R2 are no longer supported
- Windows Server 2008R2 is at the end of extended support
- SQL Server 2000 -2005 SP4 are no longer supported
- SQL Server 2008 R2 SP3 is at the end of extended support
(https://support.microsoft.com/en-us/lifecycle/search/1163)
Goods new, installing service pack 2 on windows server 2008 R2 will buy you just over a year of support. Going to SP4 on SQL Server 2008 R2 will buy you 8 more months of support - after this, you need to be on Epicor 9.05.
Ultimately these OS’s are dead, and any sensible IT strategy must include a plan to migrate to an OS that will be supported for the foreseeable future. There is still one more elephant in the room – your legacy ERP systems are either not certified for or cannot run on the latest server operating systems! What approaches can be used to upgrade the ERP and simultaneously move the whole system to more a recent version of the OS?
Functional challenges to upgrading your ERP system usually boil down to fear of the unknown:
- What upgrade path to choose
- Resistance to change, the old way is better!
- Knowledge gaps for employees and turn-over due to change
- Risks to business data and continuity during the transition from the old system
- Perceived loss of mission-critical functionality
The goal for the company must be to get back to a supported ERP upgrade path, with preferably no loss of functionality, no downtime to the business, minimized knowledge gap for end-users, and all at the lowest possible cost. These challenges can all be addressed through planning, training, and a dash of customization.
So, after listing and describing the risks to your company (which is presumably why you are here), is there a way forward? Can a strategy be formulated that encompasses both a server OS migration and an ERP migration? The answer is yes, and relies on a stepwise, incremental upgrade plan that moves the ERP and the server OS to a middle ground. Once here, the process can be paused, and the migration goals assessed. With this process there is no danger to business continuity and no data loss during the migration; furthermore, the new pilot system can be utilized for training, which will minimize the learning curve for employees.
The Pronto Progress upgrade recipe can be boiled down to:
Step 1: Get to the latest major revision prior to the release you ultimately want to end up using
Step 2: Review the new business functionality against the most recent version and determine what existing modifications you can deprecate
Step 3: Upgrade to the most recent version
Applying this strategy
Any upgrade strategy will ultimately depend on what version of Epicor the customer is using and what version they intend to migrate to. The destination endpoint does not just mean getting to the latest version of Epicor; it should also include a technical review of what hardware resources will be needed to meet each stage of the migration. As with any migration and upgrade, the business functions and flows should ultimately be examined, and if, necessary streamlined.
The best practice of any upgrade is to achieve a working environment at the latest revision of the last major version to reduce the overall potential for employee turnover or business reorganizations, which lead to increased training costs and potential scope creep. The upgrade process has three possible starting points and one endpoint the latest version of Epicor. The three starting points are below:
If you’re running anything below Epicor 9.05.02a, then your first aim is to get your version migrated all the way to 9.05.702a. This is the last major Epicor version prior to implementing Epicor 10. Provisioning of hardware is important at this stage as Epicor 9.05.702 should not be considered as the endpoint in an upgrade plan, it is more properly defined as an intermediary waypoint on the way to Epicor 10; therefore, the server hardware should be chosen to meet the minimum requirements of Epicor 9.05.702a. This version of Epicor is certified for Server 2008 R2; however, it will work with Server 2012. Do not be tempted with an upgrade to server 2016, as this will not work with the progress layer in Epicor 9.05.702a! The steps to complete are:
- Complete an in-place upgrade of the current ERP system to get to Vantage 8.03.409c
- Run the data upgrade utility to get the database to 9.05.702a
- Installed the ERP system on the new server
- Validate BPMs, customizations, and reports
At this point you have made the initial leap, you are at the intermediary waypoint and probably should take some time to reflect on the new ERP system. When you are ready you can push on to implement the upgrade to Epicor 10. Again, customers should first assess their technical requirements - does your server meet the minimum requirements for Epicor 10 and what OS are you going to install and use. Epicor 10 works with Server 2012, but a better choice would be server 2016. Once provisioned, the client ERP system can be set up and the database migrated to the new ERP format. The result of this step is a pilot system that can be used for training employees on the new ERP interface functionality.
The final functional step in this process is to assess and then to migrate critical customizations, BAQ dashboards, BPMs, and reports. The main stumbling point in this process will be the loss of BPM functionality, caused by the elimination of the progress layer in favor of a Microsoft stack. So, prior to this step, a full impact assessment should be carried out to identify the customizations that are in place, and which ones are mission-critical to a successful migration. Once assessed, the BPM progress logic can be migrated/translated to the new C# Microsoft stack and each BPM tested and validated.
If you have made it to Epicor 10, then your upgrade path ought to be clear. Apply all upgrades as they become available and stay up to date, then you will never again fall foul of the Epicor supported upgrade path!
Time Lines:
The time required to complete a full ERP upgrade will be influenced by where the customers are currently located. A company that is currently on a version prior to 9.05.702A can get to this version in about 2 months. Since 9.05.702A is the last major revision before Epicor 10.2 and is a prerequisite for the jump to Epicor 10.2 it is a viable “Pause” step which should not adversely affect existing customizations, reports, or BPMs.
The time required to upgrade from Epicor 9 to Epicor 10 is about 4 months and is dependent on how many custom reports, form customizations, and BPMs will need to be re-written since Epicor 10 uses a complete Microsoft Technology Stack.
Gotchas:
Validation is crucial. Believe it. After every upgrade, before turning the users onto the version, we always run several validations, and always include order to ship and closing the books. Print those invoices! Make sure you do one-page invoices and customer order acknowledgments along with multi-page invoices. Those documents that go 1 of 2, 2 or 2 then 3 of 2 are pretty embarrassing! It’s boring, mundane and vital. We recommend writing the script as a test plan and using it like a pilot uses a checklist prior to every take-off and landing. The time spent will be hours. The validation must happen every time; even and especially when the step is a total repeat and there is no earthly reason it shouldn’t work. This is an unavoidable expense. When it’s assigned within Pronto Progress I insure the poor schmuck assigned to do it knows that the whole project is at risk if this isn’t done. It reminds me of going hiking on the Appalachian trail and forgetting toilet paper. Trail hikers know it’s called Appalachian gold. Validation is gold.
Another gotcha is undocumented processes in the upgrade. Well, they’re not so much undocumented as hidden and the only way to get them is to call EPICARE and then be very specific as to the issue.
Another gotcha is being told something blatantly wrong by EPICARE or in the steps. If it doesn’t make sense to us, we discuss and decide how to proceed based on experience. Write these into the upgrade document. Do not assume that you won’t ever have to repeat some particular step. You will! You will multiple times.
Time the steps. You’ll need that for those fancy go-live promises you’ll be making.
Iterative steps. Take a pause at 9.05.702A and let the system breathe and the folks use the system in production. I know, I know, it sounds like such a waste of time and money. Experience has shown that it’s not. In fact, when folks climb Mount Everest they often go up, and come down in steps. Nobody climbs that mountain in a day hike. If you’re coming from Vantage the stop at E9 is actually a relief and frankly pretty easy. Imagine if you went from V8 to E10 in one step and then had questions? Why is this gone? What is this G/L transaction? Well, where did it come from? Which upgrade step caused it. Take this advice.
Vicki needs to rely on processes and good, trainable people; so that she can move toward a sustainable, repeatable business model. It's time for a "big boy" ERP. Irreplaceable folks seem great until they are overworked. Then irreplaceable becomes risky. Great business practices start with the EPICOR ERP as the foundation and the tailored best practices so that your business' unique value proposition requires no drama, and very few clicks. NeuWave Medical in Madison, WI was running Fishbowl and spreadsheets. Having purchased EPICOR SaaS, the implementation languished until Patty Ford in our Chicago, IL office came on site, replacing EPICOR Professional Services. Within months of going live on EPICOR, NeuWave was acquired by Johnson & Johnson. J&J runs SAP, yet NewWave was not required to convert to SAP.
Large and small companies can easily avoid version lock. Version lock comes in two forms, counterfeit and technical. Counterfeit version lock comes about in two fashions; job security and fraud. Technical version lock is caused by poor development techniques or poorly designed interfaces.
Sometimes there are folks in your organization that need to stay on the current version. What?? Oh yes!
During an upgrade interpersonal confrontation is common. Folks can be very passionate, stubborn or even threatening in their avoidance of upgrades. There is a formula to overcoming this stubbornness. When you see anger, discover what it is that is feared. Fear is absolutely the basis of all anger. Once you understand their fears, gently educate over time. Knowledge overcomes fear.
If you don’t believe fear is the basis of anger then try this test. Go walking on a nice spring day in some suburb looking for a large Labrador sleeping in a puddle of sun. Sneak up on the dog and then startle it awake very loudly. The Lab will initially be fearful, then become angry. Don’t try this test on a terrier or your spouse.
The reason for counterfeit version lock is often based on the person’s perceived job security. Streamlining procedures upon an upgrade is very common and will result in some job functions becoming obsolete. Incompetence may have been masked by complicated processes and now could be revealed by streamlining. This version lock is counterfeit and not caused by technology. Chris Lieber from ASSA ABLOY had a very bad experience with a Vantage upgrade. No longer did the job number mimic the order number. The result was that Chris had to scramble to adjust the processes as he had no way back to the original, older version. Chris took a professional “black eye” as a result of this modification of which he was initially unaware of. As a result, Chris avoided upgrades for the next 10 years.
Outright fraud is another form of counterfeit version lock. When someone insists that inventory numbers must be on paper, or the payroll clerk insists that payroll must be done through ADP rather than in the ERP, fraud is the distasteful possibility. Even ownership can have their hand in fraud for tax purposes. When ownership actively subverts following a systematic approach to something like bank reconciliation or inventory control, the smart money is on tax fraud.
Here’s how companies find themselves technically version locked:
- Secret Stadium Sauce syndrome. Your company needed something special or unique. The chosen, expedient path was to write a special computer program or a fancy spreadsheet. Probably no business analyst with robust knowledge of EPICOR gave the business issue sufficient consideration. A software developer with marginal experience in the EPICOR ERP can be relied upon to make themselves indispensable because they’ll want more income. If your firm does this again and again over the course of years you are indeed technically version locked. To avoid this style of version lock make all of your EPICOR adjustments using BPMs and never stand-alone executables or DLLs.
- Inertia syndrome or tunnel vision. In every organization inertia means the same thing “A body in motion tends to remain in motion and a body at rest tends to stay at rest unless acted upon by another force.” Decision makers rightfully believe they need to delegate responsibility to grow their people. The operative word is growth. Phony excuses can’t be allowed to blunt a leader’s attempt to change course. Oilgear, a Milwaukee, WI company failed to implement EPICOR at its main manufacturing facility and as a result, the venture capital company that owned them liquidated that operation. All of the delay revolved around whether they should use 3 or 4 segment G/L codes. It was, and is a moot point.
Indicators of tunnel vision version lock include:
- “When Bob retires, we’ll make this change.”
- “The configurator is required by corporate.”
- “We’ve always done it this way.”
- “We had to write this special system when we implemented EPICOR.”
- “The boss’ kid is an expert with spreadsheets.”
- “We have great people who will embrace change.”
- “Could you write up the procedure with instructions that folks can follow?”
- Force majeure syndrome. The expert told you that EPICOR can’t do what you asked for, so you had no choice. Visa Lighting began implementing EPICOR in 2018 moving from a relatively recent version of QAD. EPICOR’s sales team emphasized using EPICOR out of the box (OOB). OOB means making no changes whatsoever and is meant to be a prescription to avoid version lock.Unfortunately, OOB methodology decapitates one of the main features of EPICOR, called BPMs. EPICOR is known for having many screens to do some standard processes. This feature gives you a robust solution and at the same time makes EPICOR harder to use for simple functions. If the user forgets a particular value in a combo box, the result can be costly and harmful. It may take weeks or months to discover. Posting an invoice into a far future period, say 2028 instead of 2018, is an example of where a BPM can be handy. Many bills, such as rent, are never invoiced they are simply paid. If the date is 2018, the invoice will never get paid. By using BPMs the astute business analyst can make oversights such as this nearly impossible. Best of all, done within EPICOR and following some simple development rules, the BPM is fully upgradeable without using a developer.
If you are technically version locked it can be overcome! Recognize counterfeit version locked arguments. Overcome the fear with knowledge. Once you’re not technically version locked, enjoy the new features of each upgrade. After all, you paid for it!
“You may delay, but time will not.”
― Benjamin Franklin
I had just come back from vacation in the north woods of Wisconsin chasing the elusive white tailed deer. With missing a few days in early November for this vacation, Hunter was on my case a bit about getting the financials finished up for the month of October, and soon.
I had just finished with writing the journal entries and getting the % of completion project (Milestone) project entries entered. I took a quick peek at the financials to see how they looked. Immediately, I noticed that my sales numbers looked way off for gross sales for the month. Understandably, this resulted in showing a huge net loss for the month when in reality, this wasn’t the case. Knowing that the sales number had to be incorrect, I sent out to investigate as to why.
Looking deeper at our Sales account, I noticed that it seemed none of the project billing invoices (our time and material invoices) were showing in sales. Investigating further, I found that all the project billing invoices were still sitting in the Deferred Revenue account. I knew that I had already run the Capture Revenue Recognition and Capture COS/WIP Activity for the month as part of my month closing steps, and that should have taken care of recognizing those sales, therefore moving them from Deferred Revenue into Sales, however this was not the case.
I proceeded to run both Capture Revenue Recognition and Capture COS/WIP Activity again. Nothing changed and I was at a loss.
I made the phone call and consulted with Patty Ford from of our Chicago office and our resident EPICOR guru. Together on the phone we went on to troubleshoot different things. We noticed that according to the ERPLive: System Monitor, that the Capture Revenue Recognition task failed when I attempted to run it on both previous occasions. Then, while looking at the posting engine log, Patty was able to see which posting rule was causing the failure. She also set the GL transaction type to “manual review” before posting so she could see what things would look like if it were to be posted. After verifying that things looked to be correct, she reversed the manual review rule, and then let Jason know that things should now post correctly once the GL Code gets added to the project. What an advantage it is to be able to call someone like Patty when you need help with finding where EPICOR errored out on you. With her help, we discovered that one of our project billing invoices wasn’t being processed with the Capture Revenue Recognition. Looking closer, we found that the project itself did not have a GL Control Code tied to it, so EPICOR didn’t know where to code the invoice when it tried to process it.
After going back to the project, adding in the GL Control Code that it needed I ran the Capture Revenue Recognition task again.
This time it ran completely and without error. As a result, EPICOR now recognized the project billings that were in Deferred Revenue as Sales and now the financials looked a whole lot better.
Pronto Progress instituted a validation plan at every upgrade. In fact, Pronto Progress has a position just for Black Box testing and validation. Tina Silverio with Pronto Progress longer than she wishes us to admit, works to make sure that the White Box testing done by Pronto Software Architects is vetted prior to Vicki seeing it. While you only do this upgrade once, we do it dozens of times and apply lessons we have learned from them.
One of our senior consultants, Jason Villalobos, arranged to update this customer in Fond du lac, WI to EPICOR 10.1 from EPICOR 9.05.702A. The customer asked for their data to be migrated so that they could play with it in the new version while they continued production in E9. It was done as they requested by Jason.
Months passed. Jason Villalobos left Pronto Progress under a cloud and a few months after that Natural Stone Veneers contacted us to finish what Jason started. Understandably, they expected this to be a one-day effort and that what they’d already played with or done in 10.1 would stay or, in other words, not be overwritten.
Somewhere along the line Natural Stone Veneers concluded that, when they were finished playing, Jason would use DMT (Data Migration Tool), from EPICOR to migrate the updated data from the E9 version to E10. Natural Stone Veneers insisted that they had setup some General Ledger data, along with other things, in 10.1 and that Jason had promised it would only a day and all the new data would be migrated.
Almost incomprehensible, Natural Stone Veneers also wanted to continue doing some work in E9 while they did some work in E10. Invoicing would remain in E9 while job reporting would move to E10. Correction, not almost incomprehensible, unquestionably incomprehensible. The resulting confusion would have been comical had it not been so predictably tragic.
After a man-month of effort attempting to use the DMT the way Natural Stone Veneers expected it to be used along with attempting to imagine what Jason was thinking when he’d made these promises; the result was an absolute train-wreck.
DMT is a fine tool if you’re moving from something besides one version of EPICOR to another. There is no playing at an upgrade! The process should be:
- launch the upgrade
- then train folks in the changes during a few days of hands-on training with the converted data
- then the following weekend re-do the conversion such that on Monday morning folks can use the new system
- worse-case-scenario – if the go-live conversion failed or an issue crops up on Monday, then everyone goes back to the old version where they left off on Friday.
Why did the decisions happen the way they did?
- Jason Villalobos had a habit of over-promising which often extended to simply not showing up at the customer on the day he’d promised. Easily the customer could have been led to the playing notion based on their experience with his availability.
- The customer’s accounting department probably was trying to save cost by instituting a DIY (do-it-yourself) strategy.
- Waiting months is a mistake.
- DMT, rather than a standard upgrade migration is a mistake, when upgrading from EPICOR to EPICOR. Yes, an upgrade may seem like it will cost more, however it’s provable and absolutely reliable. Also, the upgrade process often insures important historical data is both maintained and migrated.
- Agreeing to the customer’s plan instead of guiding the customer to the correct plan is a mistake. Instead, we should have simply admitted the advice was bad, or their plan unworkable, and offered to do it the right way.
Locally, the outcome of the project was an obvious failure. Natural Stone Veneers and Pronto Progress reached a settlement with their attorney wherein we were not paid for any of the months-long effort. Globally this lesson was applied to EMCEE in Venice, FL where we successfully upgraded them from an even older version of EPICOR than Natural Stone Veneers was using. Better still, EMCEE is a valuable on-going customer and a terrific reference source.
“Failure is simply the opportunity to begin again, this time more intelligently.”
– Henry Ford
Never, ever use the SDK however. Done right, customizations move when you upgrade. Done wrong, and you are version locked! We'll never ever do that.
Businessmen understand that obstacles are always present. We've not met a businessman yet that doesn't appreciate our ownership of their objective. We'll coax you past the traps. Your business, your customization(s), are NOT the problem.
Probably you've spent some cash and likely you feel as though it was wasted. Take a moment to grieve over it. Now, let's Go Forward℠. Call Hunter and let's discuss how to leverage your objectives and knowledge, and our expertise and savvy with EPICOR to get you there!
1-(954)-471-9202 or click Reach Us.
THERE ARE OBSTACLES; BUT NO FAILURE.
First, you are not alone.
We've been down this incremental path.
Success is won one objective at a time.
Subscribers to Go Forward℠started by reaching out to us by phone or email.
Alan from Emcee in Venice, FL couldn't believe we really had an office in St Petersburg. Was he surprised when we stopped by!