Portals have evolved over years and many companies are now faced with the need to upgrade or migrate to a newer Portal environment to take advantage of the Web 2.0 or other social media capabilities that were unavailable in the earlier versions. Some of these include simple things like the need for parallel portlet rendering with AJAX or ability to use third party JavaScript libraries for optimized User Interfaces, the need to create social groups and microsites etc. Such upgrades sometimes becomes challenging with the huge proliferation of multiple Portal sites and portlets. However with some advance planning, such upgrades or migrations can be done with relative ease, more so if the process incorporates best practices and upgrade steps documented in advance. The following steps are common for any such upgrade and can be applied for most portal products.

1.      Identify the Current State:

• Infrastructure Components: Identify and document the existing deployment with respectto the Operating System, Application Server, JDK/JVM used, Web Server, Database, Authentication Systems, Authorization Systems (any SSO Solutions), LDAP etc.
• Identify the deployment topology; especially in a globally distributed environment understand the number of clusters, standby and failover mechanisms, performance SLAs, harware load balancers etc. Also document how the physical deployment is done especially the components within the DMZ and behind the firewall.
• Earlier, many vendors had their own names for Portlets. They were known as modules, gadgets, pagelets etc. These Portlets were built on proprietary standards. These days portals can support a wide array of standards based Portlets such as JSR 168 and its sequel JSR 286, WSRP 1.0 and WSRP 2.0 etc. Identify and document the Portlets of each type namely, JSR 168 Portlets, WSRP Portlets, proprietary Portlets such as pagelets or gadgets etc. Also, retain the older Test scripts if available or create new ones for the Portlets and Portal to ensure successful functional testing post upgrade.
• If any of the Portlets provides transactional capabilities identify how are these transactions handled?  Does it involve a middle-ware? Is it done asynchronously or synchronously? What are the frequencies of such updates? Are there any security requirements that need to be taken care of?

2.      Determine the future state:  

• This would include the newer operating system, if a virtualized environment is going to be used then the type of virtualization software. How the development, staging & UAT and Production En vironments are set up.  
• Identify and document the down time (if any) permitted for the upgrade.
• Identify of any of the Portal components or Portlets need to be re-configured before deployment. Sometimes JSR 168 and 286 Portlets may need to be repackaged before they are redeployed, especially if a different Application Server is going to be used.

3.      Governance and Management.

The portal is essentially an aggregation framework that allows delivery of different applications through a common front end. In a distributed and decentralized environment, the Portlets are usually managed by different business groups or departments. Identify the key owners of the Portlets in such environments, and such upgrades could impact their business. The owners could be department heads or LOB managers.

4.      Resource Planning:

Identify the resources and timeline required for the upgrade/migration. This is usually the most challenging part, since it involves people within and outside the organization. Also this is a fine blend of art and science, and success greatly depends on the skills of the project manager in holding a dynamic team together.  Especially identify, how many of these would be in-house resources, how many would be provided by a systems integrator or software vendor, the physical location of these resources - onsite, offsite, near-shore or, offshore. Identify their roles, responsibilities and issue escalation procedures - such the database administrator, deployment engineer, person responsible for installation and configuration, team responsible for migration and deployment of legacy code, teams for code reviews, module testing, integration testing and stress & performance testing.

5.      Continuously Communicate:

Document and enforce proper communication protocols - such as periodic review meetings, stand-up meetings before go live etc., define the frequency of such meetings, identify the meeting lead and organizer. Identify persons responsible for documenting the meeting notes and follow-ups for timely completion of tasks. Also, once the go live date is decided, communicate the same to the user community and get their buy-in.

6.      Risk Mitigation Plans:  

Despite best intentions and however well planned and documented, things can go wrong with any implementation. This could be events within and outside the control of the implementation team such as delay in procurement of hardware to getting the infrastructure in place. Ensure all possible risks are documented with suitable mitigation plans.