Product Packaging vs. Multi-foundation

[jdecnc]

What are your recommendations on either or both? What are the pro's and con's to each? Here is what needs to be accomplished:

Current platform - 8.11 8.96.2.1/SQL 2005/WebSphere 6.0/VS .NET 2003/Windows 2003
Future platform - 8.11 8.98.2.0/SQL 2008/WebSphere 6.1/VS 2008/Windows 2008

Our environment is slightly different then out of the box. We have roughly 15 environments. The biggest issue is we will have two of our production environments (different regions) on 8.96 for an extended period of time. (let's say 8 months after 8.98 go-live in a different production environment)

So my question is what are some of the best practices or industry standards that others have used when doing a tools release upgrade?

As always $$$$ do matter but hardware resources are readily available for parallel systems to do product packaging if that is the preferred method. (we are in the process of lease replacing all old hardware)

If you need additional information please let me know.

Thanks in advance for your responses.

 

[Sebastian Sajaroff]

Hi,

Multi-Foundation is used for Tools upgrade.

It let's you have 2 or more co-existing JDE instances
on the same server running at different Tools levels.

Product Packaging is used to port objects from one
JDE installation to another (i.e. : it builds ESUs)

Sebastian

 

[gregglarkin]

Robby,

I would set up a parallel environment on seperate hardware. Copy over all of your objects to the new environment. Then use Boomerang to move objects from one environment to the other. Boomerang is extremely easy to use and is much easier than product packaging.

- Gregg

 

[cdawes]

What are you actually trying to do?

Based on the info you've given you don't need anything -no product packaging, no Boomerang no multi-foundation.

Can you list how many path codes you have and how this relates to the environments?

If each environment has it's own path code then when you go-live on the new hardware you just copy all the databases over and update the object librarian, DD or other files - in other words just take everything instead of piece meal.


Colin

 

[jdecnc]

Sorry for the delayed response.

The ultimate goal is to get 8.98.2 deployed as well as upgrading the complete technology stack (OS, DB, compiler, WebSphere) One of the biggest issue with doing multi-foundation on this is version dependency issues between releases that and the technology stack.

As far as the environments consist there are four per pathcode. DV811 example is below. They consist of shared central and independent business data per environment.

PathCode: DV811
Environment: DVR1, DVR2, DVR3 and DVR4 (Region 1 - Americas, R2 - Europe, R3 - China, and R4 - APAC)

This project needs to be completed and not affect the normal deployment process. During the upgrade of 8.98 and the technology stack PROD R1 will go to 8.98, PROD R2 will be in the middle of a go-live and my be on 8.96 or 8.98 depending on go-live dates and roll-out of of 8.98, PROD R3 will remain on 8.96 for about 6-8 months and PROD R4 will remain on 8.96 for 2-3 more months.

Multi-foundation will address the tools upgrade but it does not address the technology upgrade/replacement.

Product packaging will address the situation but adds additional steps and duplicates the complete SDLC on both instances.

Currently we are entertaining two different options.

Option 1 - Phased approach. Do the tools release first on all servers, then phase two upgrade WebSphere, Phase 3 upgrade SQL back-end and final phase upgrade the OS on the remaining app servers.

Option 2 - Dual architecture (same as product packaging above) the difference is setup the transfer activity rules for promotions to promote to the 8.98 instance when the status is advanced in 8.96. Then we will only build an 8.98 package in non-prod for the regions on 8.98 and do the same for the 8.96 users.

Unfortunately we can not do everything at once. We are some what forced to piece meal it as we do not own some of the hardware in the various regions so we have to accommodate the roll-out on their lease replacement schedule.