Ready for migration !
Next week we will start the migration of our intranet portal from WPS v5.1.0.4 to version 6.x.
This give me the opportunity to share our migration methodology with you.
Finally, we decided not to wait for the v6.1 GA release for 2 main reasons:
- First we still don't have any fixed date for the 6.1 version (last info I had from IBM was that we could expect it for mid-june this year, but the date is approaching and no news about the release..)
- Secondly, there is always a risk to start a migration with a brand new software version.
As we have made a lot of custom developments on v5.x (approx. 1300 m.d.), we choosed to first try to compile and test our code on a more stable release. We will start doing our test using v6.0.1.3 (which is recommended by IBM as a primary step before 6.1 migration).
Even if we mainly have used public API for our custom development (i.e WCM or WPS) our approach will be to first try to "move" our code to simply make it work on the v6 plateform, to see if everything is compatible. Depending on the tests results we will then have a better idea of the effort needed to upgrade to v6.
Of course we will also study the cost of infrastructure migration. In our case, as we have about 13 WPS servers to upgrade (including a production cluster), this will represent an important workload.
After this first pre-study phase, we will see if v6.1 has been released and we will also evaluate its stability...Depending on the stability of 6.1 at this time we will decide wether to continue the study process with 6.0.1.3 or the new v6.1.
Then the next phase will be to study the v6.0.x and 6.1 new features and if we could replace some custom home-made features by the new built-in options. I hope this will be technically feasible (and functionally acceptable for our end-users) to migrate some custom parts of the code, because all these developments currently require a quite big maintenance effort.
Once the code migration will be finalized, we will likely start a stress-test migration (as if we were deploying a new software version). Once again, I hope that the caching strategy we have implemented on v5.x (mainly on WCM layer) will still be effective...because I don't want to spend my life time tuning the portal application once again !
After stress-test phase will be completed, we will do the pre-production server migration, and finally the production server will be switched to the new version. We will plan this last step very carefully because we will have to reduce as much as possible (or avoid) any interruption of service. Unfortunately, I think that our content author will have to create content twice (both in v5 and in v6) during a few days, because the server migration process takes a long time...
Then, after the production switch, we also have planned for a critical debug (and tuning) phase...even with intensive stress-test, the behavior of a web site is still "unpredictable" when opened to real end-users.
Well, if you are trying to figure out how much time this migration project will take...I would say between 7 and 12 month. The timeline will depends on 2 main factors: the first one is obvious : the number of ressources which will be assigned to the project. The second important criteria is what percentage of the custom code will we try to migrate to the standard ?
The story will continue in a next post...I'm sure I will have lots of things to say about this migration...
This give me the opportunity to share our migration methodology with you.
Finally, we decided not to wait for the v6.1 GA release for 2 main reasons:
- First we still don't have any fixed date for the 6.1 version (last info I had from IBM was that we could expect it for mid-june this year, but the date is approaching and no news about the release..)
- Secondly, there is always a risk to start a migration with a brand new software version.
As we have made a lot of custom developments on v5.x (approx. 1300 m.d.), we choosed to first try to compile and test our code on a more stable release. We will start doing our test using v6.0.1.3 (which is recommended by IBM as a primary step before 6.1 migration).
Even if we mainly have used public API for our custom development (i.e WCM or WPS) our approach will be to first try to "move" our code to simply make it work on the v6 plateform, to see if everything is compatible. Depending on the tests results we will then have a better idea of the effort needed to upgrade to v6.
Of course we will also study the cost of infrastructure migration. In our case, as we have about 13 WPS servers to upgrade (including a production cluster), this will represent an important workload.
After this first pre-study phase, we will see if v6.1 has been released and we will also evaluate its stability...Depending on the stability of 6.1 at this time we will decide wether to continue the study process with 6.0.1.3 or the new v6.1.
Then the next phase will be to study the v6.0.x and 6.1 new features and if we could replace some custom home-made features by the new built-in options. I hope this will be technically feasible (and functionally acceptable for our end-users) to migrate some custom parts of the code, because all these developments currently require a quite big maintenance effort.
Once the code migration will be finalized, we will likely start a stress-test migration (as if we were deploying a new software version). Once again, I hope that the caching strategy we have implemented on v5.x (mainly on WCM layer) will still be effective...because I don't want to spend my life time tuning the portal application once again !
After stress-test phase will be completed, we will do the pre-production server migration, and finally the production server will be switched to the new version. We will plan this last step very carefully because we will have to reduce as much as possible (or avoid) any interruption of service. Unfortunately, I think that our content author will have to create content twice (both in v5 and in v6) during a few days, because the server migration process takes a long time...
Then, after the production switch, we also have planned for a critical debug (and tuning) phase...even with intensive stress-test, the behavior of a web site is still "unpredictable" when opened to real end-users.
Well, if you are trying to figure out how much time this migration project will take...I would say between 7 and 12 month. The timeline will depends on 2 main factors: the first one is obvious : the number of ressources which will be assigned to the project. The second important criteria is what percentage of the custom code will we try to migrate to the standard ?
The story will continue in a next post...I'm sure I will have lots of things to say about this migration...
posted by Enguerrand SPINDLER at
1:41 PM
6 Comments:
Enguerrand,
My advice based on prior experience with IBM releases is that it is always a good idea to wait till at least fixpack 1 before even trying a new release. With previous Portal releases (v4.2, v5.0, v5.1, v6.0) things were pretty bad I would say in terms of fairly basic and fatal flaws in the base versions until fixpacks came out. Yes, each successive version has been better but not good enough to use without a fixpack. Yes, v6.1 has been in beta ~3 quarters if I recall right, but I am still skeptical!
My 2 cents! (obviously the value of cents is not too high right now) :)
-Vivek.
Vivek's Portal Blog
By
Unknown, at June 07, 2008
Hi vivek,
Thanks for this feedback.
I completely agree with you...even if IBM told us (in the last european WPS conference) that 6.1 has been tested much more than previous releases, I'm also skeptical...
In our case, as the migration planning will take several month (at least 6 month), I think we should have the opportunity to test a first fixpack.
But one thing is sure: if 6.1.0.x is not stable, we will upgrade only to 6.0.1.3, and we will wait until 6.1 is stabilized.
By
Enguerrand SPINDLER, at June 11, 2008
Enguerrand,
We are also starting our migration from 5.1.0.4 to 6.x. I was wondering if you could shed some light on how to measure the performance of 5.1.0.4 to compare it against 6.x performance. I was thinking of collecting some statistics regarding CPU, JVM, network traffic etc. Could you please share other specifics that might give useful information to baseline the older version.
-Valli
By
Valli, at July 06, 2008
Great post!!
What tool do you use to make the stress Test? I´m interesting in a protocol to make it.
Thanks!
By
Anonymous, at July 08, 2008
Regarding the performances of v6 compared to v5, IBM announced that v6 performances are been improved about 30%....well after doing some tests on v6 I would not say that there are so much differences. A good thing however is that if you use the WCM tool (for web content management), the server restart is quickr in v6 because WCM indexes are better manager in v6.
If you want a very simple way to compare the performances of both version (CPU, JVM, etc), you could have a look at the TPV (Tivoli Performance Viewer) tool (which is available from the WAS admin console).
Finally, for the stress test campain with v5 we have used the OpenSTA open source tool. This is a basic tools, but I think it is really sufficient for most of the projects. You can read this article which gives some info about stress test tools:
Performance considerations for custom portal code
If you want I can post more info about the stress test topic (I have some presentation provided by IBM which could help you).
By
Enguerrand SPINDLER, at July 08, 2008
Thanks Enguerrand,
If you could post about Stress-test and about your experience, it would be very useful for me!
Thans in advance
Guj
By
Anonymous, at July 09, 2008
Post a Comment
<< Home