Server migration

We are in the process of migrating our entire JDE system (Enterprise, Deployment, Database, and JAS servers) to new servers. In the past we have always had consultants come in to do the work, but the powers that be would like us to try it on our own this time.

We run on the NT platform, using MS Server 2003 standard with all service packs and patches. We are running E8.10 Tools Release 8.94.

We have the database server migrated over, SQL 2000 to SQL 2000. Once we get everything up and running, we want ot upgrade to SQL 2005, and Tools Release 8.96.

The problem is migrating our Enterprise and Deployment servers. Has anyone come across some good documentation on this subject? Oracle advised trying to restore once we checked all MTRs. This would involve restring the OS as well, and I don't think this would be a smart thing to try since we are using new hardware.

Any assistance on this subject is appreciated. Thanks.

Here is a lenghty reply to a BIG question...

"The problem is migrating our Enterprise and Deployment servers. Has anyone come across some good documentation on this subject? Oracle advised trying to restore once we checked all MTRs. This would involve restring the OS as well, and I don't think this would be a smart thing to try since we are using new hardware."

I would agree to that, that would mess up drivers and patches and cause all kinds of havok.

"We have the database server migrated over, SQL 2000 to SQL 2000. Once we get everything up and running, we want ot upgrade to SQL 2005, and Tools Release 8.96."

If you are migrating to SQL 2005, use this as an opportunity to update your drivers. Look at the new Native SQL client. That is backwardly compatible with SQL 2000 and forwardly compatible with SQL 2005. I have that up and running on a bunch of my terminal and batch servers as a stepping stone toward SQL 2005.

As for the migration - I would install everything per scratch, like you were starting up fresh. Get the system up and running with the DV or pristing environment, out of the box. Make sure you can build packages and log in to pristine. Then you need to migrate over your central objects and versions and stuff. You might want to ask the powers that be to allow you to get a consultant for that. I would. (No, I'm not for hire)

Bringing over your business data would be the easy part. Bring over DV and PY business data first. On your old system, do a database refresh from PD to PY to give you a very clean snapshot. Then lob that data over the fence to your new system and test the living crap out of it. The last step will be to lob your prod data over from the old system to the new.

Another approach would be to add these new servers in to your exisiting environment and start the shuffle process. That is less of a big bang approach. Here is how that works.

1) Swap out your deployment server. Build the new box with a temporary name. Get JDE installed and swap over all of the JDE stuff. Do a name change so that your new deployment server has the same name as your old one. You might need a consultant for this. It can be done in house with a bit of planning.

2A) Add in a new enterprise server in the planner and slowly migrate your environments over to it.

2B) Our enterprise server is a cluster. We added two more nodes to the cluster to make it a four way cluster. We installed JDE on the new nodes. We installed SQL on the new nodes. The DBAs slowly transferred the databases from the old boxes to the new boxes. In cluster management, we transfered the JDE cluster service over to the new node. Once things were stable, we removed the old servers from the cluster.

3) Add in new batch servers - we added in a new batch server and are currently in the process of planning to swing the users over to the new server. We had to set up the OCMs for it. Then we need to move over data and convert some small batch processes for the new server. The last step on the cut over day is to do a little behind the scenes magic in SQL to swap out the name of the old batch server for the name of the new one so users old jobs look like they were processed on the new box. Alternatively you can set up the new box, switch users over to it and leave the old one around for a month for your users to reference old jobs. Give them a cut off date for the old server and stick to it.

I realize this was bit rambling, but hopefully it will spark some ideas.

Gregg Larkin
Praxair North American System Admin
JDE CNC and Security, Websphere, Tidal

Gregg,

Thanks for the information. I was not taking care of JDE when the new servers were budgeted last year, and am still learning, or I would have consulted with the person who was and found out the need for having consultants present.

The problem, after talking to him is that the powers that be didn't think about needing to factor in the cost of having our consulting group work with us, remotely or on-site, do the cost was not budgeted with the servers.

I will look into your suggestions, and see if we can limit what we will need the consultants to help with. This, in turn, might help us to reduce their quote down to a more manageable amount. Thanks, again, for the response.

Eric,

I'm sure your consulting group, or any of the many consultants on this list, would LOVE to manage the process from End to End. But with due diligience, that shouldn't be necessary and will be a good learning experience for you. Having a guy like Jon Steele (altquark is his JDElist alterego) or Sebastian Sajaroff engaged for a short term is a worthwhile investment. (didn't want to play favorites here ) Good luck and don't be shy about asking for some more moeny for the consultant. Migrating servers is a once in a blue moon event for guys like you and I. It's the bread and butter of the consultant guys.

Gregg

Thanks for the plug, Gregg !!!

I know this is a bit biased coming from a consultant - but that is why us consultants exist ! Your job is to run your IT department in your company. My job is to be experienced in Oracles' implementation procedures. For you, this might only be a one-off (or a very infrequent and rare process) - but for me, I do migrations, upgrades, installations and all sorts of similar activities day in and day out.

It is important to understand that there are two aspects of CNC people. There are CNC Administrators - who are the majority of people on this forum. These people understand the management of THEIR system to a great degree - and manage everything from security, printing, package builds, promotions etc in their company.

Then there are CNC Implementors - or, to put it another way - CNC Consultants. These people are trained by JDE to architect database systems, run the installation and upgrade procedures and architect/train a customers CNC Administrator with their daily duties. There are not many CNC Implementors out there - and the few of us that exist usually work for many different companies at different stages of their implementations. We're more "mercenary" than CNC Administrators.

Most people who are CNC Administrators that want to become CNC Implementors leave their customer and go on the road with either Oracle, a consulting organization or as an independent.

I hope that explains the difference. CNC Administrators have varying degrees of expertise depending on their role in their organization - CNC implementors have different types of expertise and usually have a much broader depth of experience. When you make architectural changes (or upgrades) - you really need a CNC Implementor or CNC Consultant to assist. When things go wrong, it usually goes wrong in a BIG way - and its nice to have us CNC Consultants around as insurance...

Eric,
We did this at my company last year and we brought in a consultant to help with the transition and everything went smooth. We did the DEV and Pristine migration while he was on site and then we did CRP and Production on our own. Using the consultant to help with building the plan for moving was well worth the money. He definitely covered some pieces that we would have missed.

Tom