MIGRATING HISTORY AND MERGING WITH CURRENT TRANSACTION
Comments
-
Hi Sharon. Yes, migrating in phases is a completely acceptable way to handle your situation (if it is related to HR or Payroll). I have done this for clients when the historical records are not needed immediately following Go Live. If you could reply and explain whether your history is payroll related or HR or neither, that would help me provide some considerations.Thanks and best of luck.Tammy0
-
Hi Sharon
we are faced with the same issue you described, large volumes of data to go through a JDE XE to 9.0 conversion in the minimum amount of time during the go live weekend. We are planning to approach the issue in reverse to the way you described. We are going to convert our historical data, that which is static, and basically pre-stage this into our new production database. We will also validate balances etc. as we do this weeks before the go live event.
The goal being to convert all historical tansactional and balance data, more than 2 years old, prior to the go live weekend - basically F0911, F0902, F4201, F4211, etc. Then over the go live weekend we will convert the most recent 2 years of transactions and balances, as well as master file and configuration type data and merge it with the pre-staged historical data.
To add to our complexity we are also merging three current XE environments into one JDE 9.0 environment and changing from SQL server to Oracle Unicode - thus even more time required.
rgds
Paul
0 -
Sharon,
I know of at least one customer who migrated all but the most recent 18 months of Distribution, A/P, A/R, and G/L one week before the "go-live" weekend. That way there was only 36 hours of downtime for going live. Then history was systematically merged with the "go-live" migration over the course of two weeks.
0