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...