@Ernie in terms of timing, would you work to correct the processes in vantage before going live, no matter how long that takes? In other words, delay the cutover until new processes are in place to support a new data approach?
Excellent way to put it.
That is exactly what I was trying to say.
2 Likes
Since he’s going to keep the old system running until all the old jobs are done, that won’t be an option. This is one of the nightmares he’s choosing… but at least it has an end date.
2 Likes
I see
Interesting thoughts - went through some of those scenarios at a couple of different places. The biggest kicker was historical information. Now with all the BI tools and such, it may be a lesser issue.
I’ve seen management change and want to do things differently - throw out the GL, change to smart part #s, etc. All they need to see is an empty install and what it will take to get you to a point you can even test.
I have also been through many data conversions from old systems where the data is “scrubbed” before loaded into the new. At some point people typically give up and you go with what you have. It will never be “clean”. Even customer and supplier data can be problematic.
You are going to have to bring over all parts that have inventory and I would think pending transactions. What we’ve done in the past for converting open jobs is setup dummy material, labor and burden part numbers and cost adjust them to the current amount in WIP on those jobs the day you convert. Accounting is going to want to see balances reconciled, things like WIP, stock, open AR, etc. At that point it is time to see if all the extra effort reconciling the systems is worth the amount of clean up that will be done.
Good luck!
Jenn
2 Likes
Great thoughts Jenn!
1 Like
Running in parallel is typically to labor intensive, IMO. Like others have said, I would run a conversion and get the data into your pilot environment, then figure out what you can and can’t live with. Whatever you can’t live with, start updating in your pilot environment. We moved from E9 to Kinetic and worked out everything in pilot, tried to clean up our processes and data along the way best we could (i’m sure some people would readily argue I’m not using Epicor as intended, but it’s what works for our company). Here’s what we did in a nut shell:
- Create new revisions of BOMs, clean up Parts, Vendors, Customers, etc,
- update/clean up BPMs/BAQs/customizations
- As mentioned by @utaylor separate process improvements vs implementation requirements to stay on schedule. Keep a list of process improvements so you don’t forget and can set strategy/long term goals (I’m a big fan of clickup for this)
- validate processes and data in Pilot and use this for training.
4.1 setup a freshdesk account for people to email problems too so you can prioritize and tackle/track them.
4.2 hire an industrial engineer, document the new processes and flow chart them for quick reference. - when you go live move convert the data from Vantage 8 to Kinetic. Have all your data prepped from pilot and DMT it into live to capture all the data clean up you did during testing. Also have a solution file prepped and ready to load into Live. it’s a lot of DMT work, but if you have them all prepped ahead of time, you can knock this out in a very long day.
- DO NOT RUN DATASE PURGE AND SUMMARIZE THE WEEK BEFORE YOU GO LIVE. This just creates unnecessary stress when you delete your entire TranGLC Table!
Keep in mind if they are 100 year old company, they’ll adapt to what needs to happen to keep things moving, even if it’s temporarily painful.
1 Like
Sorry I’m late to the party. We converted from 8.03 to Kinetic and it was very painful, in part because of some of the reasons you mentioned, plus we had modified the Vantage database back in 2006 when we installed it to get what we wanted, but concurrent with the upgrade we also added MRP and some other stuff that caused a lot of issues with simply converting the database. Lots of manual review of the data before it was uploaded via DMT. We brought along the active customers and suppliers, active part numbers (about 12k), and active projects/SOs/jobs, and left the rest of it behind (we still have it for reference).
But even with all that, my biggest complaint is that the basic functionality is awful in Kinetic … searching and selecting parts, for example, takes many more clicks, and sometimes it’s simply not possible to get what you want (not a big deal as long as I can get to the classic screens, but I’m told those will soon go away). Guess I need to learn how to write my own BAQs …
Good luck!
Lots of good advice already.
I agree with one cut-over migration.
I took part on 2 Kinetic on-perm and all customizations, ssrs, reports, data migration, even personalizations were all well planned, rehearsed, timed and tested prior to cutover weekend, so migration was successful. Only a small percentage clean-up, screen updates and such. Limited consultants time. The key for us was good planning.
Postpone all enhancement until migration is completed. Let them seat on ticket queue and pick them up as soon as all post migration activities are resolved.
If you were converting from some other software, you’d have no choice, right? You’d have to start over.
This gets into the Sunk Cost Fallacy and other ideas in that realm. (I’m a fan of Daniel Kahneman, who won the Nobel Prize for that.)
Like, bad management has people routinely come in on Saturdays and Sundays to catch up for lost production through the week. But if there was a law against working weekends or something, they would just have to adapt and get it done in 5 days. Long ago here they would be finishing trucks on the 33rd day of the month (not a typo), trying desperately to make a quota. Now we make the same number of trucks every day (and 5x as many) and break records.
You have to get people to imagine that stupid ideas just are not an option.
- Saturday does not exist.
- Uplifting from Vantage to Kinetic does not exist.
I know, that last one “is an option,” but if you think like it’s not an option, you force yourself to find solutions. But as long as the “option” is out there, there is no necessity to be the mother of invention.
When I said “you” there, I mean your coworkers. I know you actually want to move on.
Also, @jkane I’m glad they have you to guide them. They need your help.
1 Like
I agree with everything you said, but it sounds to me like management is pretty set on staying the same for now and @jkane trying to push it all by himself sounds like a difficult task maybe even a waste of time. I’m not saying he couldn’t do it, but if the larger org doesn’t want to do it, I don’t know how one person could possibly succeed alone.
1 Like
I’ve been there before, that’s like trying to paddle upstream with holes in your oars and your boat is taking on water…
2 Likes
But wait!!! I am actually at a company where I have the full support and backing of the President 
! Hard to believe, but actually true for once!!
1 Like
Then by all means bring in the experts when needed and get it done!
1 Like
These quotes below made me feel like they weren’t all in, all in, but as long as you feel good and feel like they are with you that’s all that matters, push onward! 
“Taking people through the mental exercise of trying to clean up the existing seems insurmountable for a company that is coming up on its hundredth anniversary.”
“the sheer volume of questions and pushback I am going to receive coupled with the board looking for a quick turn-around…”
We did something similar, years back we upgraded from a Unix proprietary ERP to Epicor9 and eventually to Epicor10. We converted the legacy system to a VM and kept as read-only for historical purposes only. Converting the data was not an option and based on issues with the old data we took the following approach. We loaded all customers, suppliers, open sales orders, open PO’s and open AP (team assigned to do via manual, DMT, etc inputs) and loaded GL balances into Epicor. Since not possible to convert part records we created the parts in Epicor as required, ie for on-hand inventory, open orders, reorders. This worked well for us. I suggested allowing open jobs from the old ERP to complete on the old ERP however they decided to recreate on new system but due to volume was very difficult to do on a timely basis and caused issues/delays in shipping, invoicing etc. The new travelers looked different so it would have been easy to identify which system it came from. We converted the legacy system to a VM and kept as read-only for historical purposes only. We created everything else new in Epicor going forward. I would always prefer this approach rather than bringing garbage data into a new ERP system. Eventually, the need for access to the legacy data phases out or is greatly reduced. Now in a recently new position on Epicor 10 preparing to upgrade to Kinetic have similar challenges again, including data integrity, not using Epicor as intended, great reliance on data outside of Epicor including redundant data-entry, etc. Working towards training, standardizing data inputs and streamlining the business process and hopefully getting buy-in and encouraging users by way of demonstrating success through examples. Preparing for the upgrade well in advance and cleaning up data before converting. One bite at a time…
4 Likes
A GREAT recounting of experience @sb_orion! Thanks for sharing, and welcome to the group!
1 Like
There is wisdom in this recounting. We are taking some of these same approaches. The adoptability from an evolutionary standpoint is not a bad approach.
Long and interesting thread…
I have done a number of version 8 to version 10/Kinetic “implementations” which were actually a re-implementation because of bad use. You could use Epicor’s migration to upgrade the bad use data to a historical company, and then implement a new operating company. What I typically find is because of a bad understanding, things like resource groups, operations, warehouse bins, reason codes, part classes, product groups, and gl accounts are out of alignment to what the company is doing and what the product is capable of. Every client claims they need access to history but typically it is going to be something like a part ordered or a purchase order for something. You can load old sales orders and old purchase orders just make sure they are closed. Pretty much everything else is a mapping exercise, but that should not be done until there is some training and agreed to changes in process.
I set up a conversion database in SQL. Create a bunch of BAQ Queries to export the data out of Version 8, load those into the conversion database and then write queries to map the data to what it needs to be for historical purposes. Then use DMT to load that data. It is very painful as you come across bad habits that don’t export well, like hidden characters in part numbers and descriptions that when exported, translate to carriage returns or extend the size of a part number so it no longer fits. It can be done, but it is very time consuming to get the data that needs to come over correct. I know that @LarsonSolutions has done this work several times as well.
I never recommend upgrading from Version 8. Especially if the users have not had good guidance in how to properly use the system.