We “migrated” from V8 to E10.1.400 via DMT. So going from E10.1 to E10.2 should be very straightforward. As @jtownsend said, there is a Menu structure in DMT that is geared towards migration. The menu items are in the order that you’d need to import data in.
One big warning about DMT, is that some fields provided aren’t respected. When I DMT’d in Order info (using individual DMT’s for Header, Line and Release), Things that auto increment - like line number - aren’t maintained. If your old system had 10 lines (1-6, and 9 -12; lines 7 and 8 had been deleted), DMT would create them as 1-10. Now if you DMT in the OrderRel info and one of your Releases referenced Line 9, that would be applied to the new line 9, which was line 11 in the original system. Not only would your release info not be applied to the correct line, Jobs numbers that used the Ord-Line-Rel format, would no longer match the line and release the were created for.
Uploading PO’s also suffered this re-numbering issue.
A similar thing happened with MtlSeq on BOM’s We had BOM’s with Mtl Seq’s like: 10,20,22,24,25,30,35. But DMT’ing them in created the Sequences 10,20,30,40,50, etc…
What I ended up doing on the orders and PO’s was to pad the DMT file with lines I could later delete
A DMT file for an order with lines:
OrderNum OrderLine PartNum Other_fields...
12345 1 ABC-123 .....
12345 3 XYZ-123 .....
should be
OrderNum OrderLine PartNum Other_fields...
12345 1 ABC-123 .....
12345 2 DMT-PAD .....
12345 3 XYZ-123 .....
That will keep line 3 from the old system as line 3 on the new one.
Some other off the top of my head
- Quadruple check the UOM setup.
- Don’t upload anything that you expect to delete later (save for those items used to pad gaps). I uploaded all the parts, with the intent of deleteing the ones we didn’t want transferred later. But then uploaded costs for all the parts. That created ADJ-CST parttran records, thus preventing me from ever deleting those parts I was going to delete later.
- Make backups of the DB after each major DMT upload. If you find that something went wrong, it’s easier to restore the DB from a couple of steps ago, than it is to start from scratch.
- Did I mention the importance of the UOM system being correct?
- You’ll have to do the Extended UD Column updates first as your DMT’s that hit the affected tables most likely need the UD fields.
- If you want transactional data for reference, put it into UD tables, and then make BAQs to query them. An overzealous person would structure the UD table identical to the transaction tables, then in a BAQ you could union the UD table to transaction table in a sub-query, thus combining the historical and current transaction data into one dataset.