We are currently on V8.03 and are moving to E10.1. Originally the need was just to get off of the old servers that V8 is running on (a Win Server 2003 box). The plan was to export select data from V8, do some minor translations, and import into E10 via DMT. The translations were going to be to bring some things in line with our new parents companies accounting systems. Translations were just going to be to : CustID’s, SupplierID’s, Product Groups, Part Numbers, and GL Acct’s.
But someone in Finance threw a monkey wrench into the plan (it’s always Finance, isn’t it? ). And now we’re going to do this as two stages.
Stage 1 is just to get off the old box and onto E10. No translations will be done, just exporting data from V8 for import into E10. I did convince them only migrate relevant data Ex: only customers with an order in the last two 2 years, recently used suppliers, recently used parts, etc…)
The plan is to make BAQ’s to run in V8, to create the CSV files for import into E10. Looks like there is 109 “entries” in DMT (using the Migration menu). I’ll only need about 60 of them - we don’t use It much beyond Sales, Parts, Jobs (mtls only, no labor, operations or scheduling), AR and AP. And only the basics of those.
Anyone see any major flaws with this technique, or know of a better one?
One thing I’ve already found, is that the DMT into E10 uses CustID’s and not CustNum’s. So every BAQ will have to export CustID in place of CustNum. I assume SupplierID’s are the same. Any others like this?
BTW - There is WAY to much garbage in V8 to just have Epicor convert it to E10. We already made that mistake when we went from Vista 4 to V8.
We moved from Vantage 8.03 to E10 in 2015 using exactly the method you described (V8 BAQ to Excel then into E10 using DMT). We were very happy with the final outcome because we were able to do some data cleansing in the process and, as you mentioned, only bring over truly relevant data.
The only warning that I do have is to thoroughly test all of your DMT loads before go live, ensuring that fields are importing properly. There were several instances were there was prerequisite data and I had to do multiple loads on the same table to ensure that the data imported in the correct order. One example was with PartPlant. You have to load the minimum, maximum, and reorder to max fields in a specific order for them to load correctly. With proper testing though, it is definitely a viable method.
Did you try to import any customizations or BPM’s?
I figured we would just recreate all the BPM’s from scratch in E10. A query of the Bpm tables shows only 15 enabled BPM’s (and most of those are just to pop up a message based on field values).
We’ve got a ton of customizations, but most of those were work arounds for poorly implemented V8, or carry over garbage from V4. Hopefully most of them won’t be necessary if we setup (and make people use) E10 properly from the get go.
And what about UD fileds in tables? I understand that E10 is designed to require using UD tables instead of UD fields in standard tables. Are all UD fields in standard tables gone?
I did not import any BPMs or customizations. Similarly to you, most of our BPMs and customizations were workarounds for things our users didn’t like in V8. Much of this was because we weren’t using the system properly to begin with. I removed most customizations and only recreated the ones that were absolutely necessary. An upgrade to E10 is a great opportunity to review business processes and change the way you do some things, rather and changing the system to work with your old processes.
Regarding UD fields, yes all UD fields in standard tables are gone. I didn’t like the UD table change when we first went to E10, but now that we have been live for almost 2 years, it really is an improvement in my eyes. There will be some remapping that needs to be done to incorporate V8 UD fields into E10 UD tables. The hardest part of this for me was figuring out which UD fields were actually being used. I made a spreadsheet of all the tables I was bringing over then very tediously went through each table to see if there was data in the UD fields. Once I had all of that figured out, I determined which UD fields were actually necessary and which could be ignored and then recreated the necessary ones in E10. A tedious process, but I don’t know of a better way of doing it.
Luckily I’ve kept a pretty good spreadsheet of utilized UD fields in standard tables.
What’s the Cliff’s Notes version of migrating UD fields? Something like:
Select a UD table for each standard table that used UD fields. Ex: UD01 will hold UD fileds from OrderHed.
Export index fields and UD fields from Std tables (that use UD fields). For example of OrderHed table: Company, OrderNum, ShortChar01, ShortChar02, etc…
Import data from step 2 to a UD table. Example for OrderHed UD fields: Company-> Key1, OrderNum->Key2, ShortChar01-> ShortChar01, etc …
Rinse & Repeat
How difficult is updating reports that used UD fields. Adding a UD field in an RDD wasn’t too bad, as the table was already in the RDD. But what about linking UD tables in a RDD?
Not quite. In E10, you can create a UD table that is automatically linked to a standard table. The benefit of this is that in the UI, it behaves very similarly to if the fields were actually fields in the standard table. For instance, if you have UD fields on the part table in V8, you would use E10’s Extended UD Table Maintenance to create the Part_UD table. Then you would create whatever UD fields you need within the Part_UD table. From that point forward, all of the columns you added to Part_UD will react as if they were actually a column in the standard part table. They will be identified as UD fields by having a ‘c’ after whatever you name the field. For instance, in my Part_UD table, I have a field called CreateDate. When I am loading a part using DMT, I can load on the standard Part table with a column name of Part.CreateDate_c to load data
What I did was in the V8 BAQ, I gave my UD columns a heading of whatever the column name would be in Epicor (my V8 Part.Date01 field was given a header of Part.CreateDate_c), so that when I exported by BAQ to Excel, it would already be mapped.
Can I ask why you don’t upgrade all the data using the standard V8-> e10 process then use the truncate processes on E10 to cut the data down to the relevant batch of data?
It seems like there are three options in the upgrade process.
Simply upgrade - Move all old data to E10.
Dump and Load - Extract all old data, scrub it and reload it with DMT
Upgrade and Delete or Delete and Upgrade - Delete or Truncate data from old data then use the upgrade path to move scrubbed data to E10.
The biggest change we are trying to make is to remove old warehouses and to simplify our UOM structure. Both of these things are pretty big but don’t have any direct effect on financials. Any thoughts on a method?
@John_Mitchell We were in the same positions as you about 12 months ago. As part of the migration from V8->E9 there is a required step which is about merging UOMs and is probably one of those things from experience you will spend some time doing to get right. You will need to engage your accounts & purchasing dpts to figure out what a UOM of ‘asdasdsa’ or some other genius idea they have type in actually means (usually means EA). Post upgrade you can disable all the junk UOMs so they cannot be used going forward. Warehouses I’m guessing you would need to reimport from scratch to do that.
In the end we upgraded the entire 60~gb dab from V8 -> E10.0.700 and didn’t truncate any data. Our wanting to keep all our financial history in one active database and not juggle between E10 and V8 drove the decision primarily.
If you have any question about the upgrade process feel free to ask and I will reply as best as possible.
I know this thread is old, but i am in a similar situation. Were you able to import historical data via DMT tool?From what i researched, if i go the DMT method, i can only import base files (customer, parts etc) but no historical data.
Our choice to go this route was two fold. First we didn’t want to bring everything over. The second was to do some tweaking of the info we did bring over.
We’re not able to bring over historical data like part transactions. Probably the best thing to do would be to export Part Transactions data, and import it into a UD table. Then make dashboards to display the info similar to what native V8 has.
Thanks for the info. So what information you put in UD tables? Some of the questions i get is like a customer purchase history, financial data. did your company not bring the historical data on these items?
Another option, that can sometimes be easier is to perform the v8 - e10 upgrade into an archive or history company that resides in E10 along with your “new company”. This way you have a company in E10 that makes accessing history, for most things, a no-brainer and you also have easy access to pulling over data into your new company when desired.
Thank you Edward! Did not think about this option! Will look into this!
I could upgrade from vantage to 10. Then do a new implementation on a new company.
). And now we’re going to do this as two stages.