Parallel Upgrade---> Less Production Down Time as two environment will run in Parallel, Hard ware Cost for New Servers
In-Place-- Big Production Down Time
Its a Trade off between Down Time and Cost for Making a New Parallel environment.
Explore below link for Upgrade Details.
-> you have to "play" the upgrade on another environment to:
--> detect the problems and fix them,
--> evaluate how much time the upgrade is taking,
-> you will have to stop the production access when you will run the upgrade,
-> you can play the upgrade "safely" on a copy of your production database (or do a clean install),
-> you will have to do several "delta migration" from your current production to your new one to move the new records and this can take a little while to setup,
-> you can safely test your new platform (unitary / performance tests etc...),
-> you just have to switch both environments when they are ready,
No issue for downtime, but we want to give our client the pros and cons of both approaches.
We will be having a test server containing the replica of Prod environment and we want to give them an option best suited to them for any upgrade process..
Thanks Laurent and RP for replying ,
could you please add more considering that we have no issue of downtime.
Also we want to convince our client to go for Parallel upgrade, are there any better advantages over inplace upgarde.
Concept of Parallel Upgrade - Is basically to Minimize Production Down time because in 99% cases Client can go for 48 hours of Downtime.
Rest i think already explained.
now i see why LOL- I wrote - CAN it should be CAN-NOT.
Is basically to Minimize Production Down time because in 99% cases Client can go for 48 hours of Downtime.
Is basically to Minimize Production Down time because in 99% cases Client Can Not go for 48 hours of Downtime.
Ah, no it was for the indenting actually I didn't see the can not ^_^''
Hi Vivek, I have tried both the in-place and parallel upgrades in the past. From my experience, I think parallel upgrade is the best way of upgrading an environment. I know the guys have listed out some factors but the main thing that stands out for me is the number of issues you face while performing in-place upgrade. You can potentially face a lot of issues that might even render the upgraded application inaccessible. There is so much hassle involved in performing the in-place upgrade than the parallel one. For the parallel upgrade, there are several ways of upgrading it and the one I recommend is as follows:
- Do a clean install of 8.1 version
- Apply/migrate your customization
- Preform delta data migration to move the foundation and transactional (if required) data
Thanks a lot Laurent, RP and Mussie.
hope we could convince our clients for parallel upgrade. !
How did this go? How were you able to prevent new tickets being created in the old system while running parallel?
Hi Lorraine, users will still be able to log tickets in the old system as upgrade is usually a few weeks (if not months) project. Once the system is fully upgraded, you can run the Delta Data Migration (DDM) tool to migrate the old tickets. This tool is designed to do just that and you can read about it here: