Running 2 versions of OneWorld in parallel (73.2 and XE)

[at1108]

Hello,

I am faced with an interesting challenge. We are currently running JDE OneWorld version 73.2 and are beginning the testing portion of an upgrade to XE. In our past experience, the actual go-live of the JDE solution was rocky to say the least. That said, we are all feeling quite nervous about the actual "go-live", even if all of the testing goes well. We're running with Sql Server 7.0 databases.

So, the challenge is to have 2 versions of JDE OneWorld running in parallel for a short time after the go-live. By saying this, I mean that the data between the 2 environments should be synchronized every night in the case that we will have to roll back to the old version at some point. The largest hurdle as I see it is the fact that the database objects between the 2 versions seem to be significantly different.

I am still in the brainstorming process for making this happen, and would LOVE to hear any suggestions that you folks have from experience or stabs in the dark. Has anyone performed an upgrade from 73.2 to XE? How did you handle the go-live?

Thanks in advance for any suggestions, comments...

 

[gerd_renz3]

You want suggestions? Here they are:

I would not even try to do what you are attempting. It´s more an application issue then technical. The table formats are quite different between B732 and Xe. I would not immagine how to do that. If you spent the amount of work, necessary to accomplish what you want, for testing instead, you should be better off.
You have another problem, though. As you are running SQL I assume you have NT servers. You need C5.0 for B732 and C6.0 for Xe. Both compilers cannot live on the same machine. You temporarily would need a second ES server to run OW processes for both versions, even through the testing phase.

I did a few B732 to Xe upgrades. We spend all the time necessary in testing. If you survive the first couple of days after GoLive you would not want to go back. Xe is MUCH better. If you feel you need to go back, just redo all the work from one or two days. Or keep systems in parallel and do all the data processing in double for a couple of days. Uuh?

You might want to get the help s.o. who has done this upgrade before (I´m not available ) .

Good luck, Gerd

Em Tuesday, December 11, 2001 em 06:49:09 AM, [email protected] escreveu:



--
ISM - Solucoes na Internet

http://www.ismnet.com.br/

 

[SSAJAROFF92]

Hi there :

I?ve done two migrations from B7321 to Xe, and these two versions are
too different!
You can run them at the same time but using different databases, if I
were you wouldn't run these two releases on the same database.
Xe?s database structure is quite different that B7321?s.
For example, Xe uses Primary Keys, Clustered Indexes and B7321 doesn?t.
The most important part is to have a clean B7321 Production database
before starting.
Clean means : no NULL values, consistent data and no repeated rows.

Sebastian Sajaroff

 

[cpb]

I just went live the weekend before last with the same config (B732.2 to XE, MSSQL 7). I second (or third or whatever) what the previous posters have said: There is probably no way to do parallel production systems, short of having your users enter everything and run all jobs twice.

We did give some thought to how to do it, the most feasible proposal involved dumping the XE SQL transaction logs into a temporary database, and then using DTS to stick the data into the B732 databases. Once we started tracking the changes, >1400 tables in XE that don't exist in B732 for example, we realized it would be quicker (and cheaper) to go the everything-twice route. Eventually we abandoned the whole parallel prod idea as unworkable.

Your concern over a rocky go-live is not unfounded; the past couple of weeks have been a nightmare. I'm still bouncing from one crisis to the next "like a ping pong ball in a clothes dryer." Comparatively, however, it has gone better than the last two, and much better than the initial JDE go-live.

It would have been much worse if I hadn't done a series of dry runs over preceding weekends, and I recommend that approach instead trying to run parallel production databases. If you do a complete (successful) dry run, and have adequately tested your CRP setup, things should go pretty well. My crises are (with a couple of major exceptions) mostly things we could have fixed before go-live if the <expletives deleted> testers could have been bothered to actually TEST in the PY environment.

 

[adri_valentim]

I just want to make a point. When you are doing an upgrade, you are suppose to copy your Production Data (PRODDTA and PRODCTL) to your CRP environment. Then you upgrade your CRP and DEV environments. Once each function that your company is using is full test (I MEAN FULL TESTED IN CRP/PY ENVIRONMENT) can you even think about going with the upgrade of your Production. The CRP/PY environment is your parallel production environment. Yes, it takes time and resource to do it but, in the long run, it can save you a lot of headaches. You will always find bugs, but they should be minor ones.

Another point - a quick and dirty upgrade usually end in disaster. Once your are live - you can not afford to take risks.

Adrian Valentim
Valmatrix Consulting Inc.