An Avanade Blogging Community

As one of my roles at Avanade, I have the joy (no really!) of managing our Lotus Notes Migration solutions space. As a result of this I have the opportunity to speak to many different types of customers all over the world whom have either decided to make the switch to the Microsoft platform or are considering it and are seeking assistance or input on a strategy for 'taking the plunge'

Overall the key to executing a migration of any type is the amount of up-front planning and strategic thinking which is undertaken prior to commencing the actual "migrating" - with a Lotus Notes migration this is of particular importance as choices undertaken early in the process have the ability to heavily influence the eventual cost of a migration overall.

Much of the focus of any migration away from Lotus Notes usually centre's around the application portfolio a customer has, with two key considerations needing to be taken into account when determining the true cost of ownership or migration cost and when (if) demonstrable cost savings will be achieved as a result of a platform transition.

These considerations, often referred to as “as-is” and “to-be” architecture provide the foundation of any evaluation into updating an application estate through a migration or upgrade to a later release. By determining the “as-is” state, a business is in essence, clearly defining their requirements, existing issues and strengths of their existing solution prior to determining their future state environment within the “to-be” architecture which can then be executed on.

This approach to application migration is time tested and sound, however when it comes to a platform migration often there are other constraints or considerations that need to be considered, by borrowing from an Enterprise Architecture model in addition to the traditional application architecture model organizations can in essence mitigate some of the risks associated with the change process. By understanding and reacting to internal forces such as political boundaries and fiscal requirements or constraints it is possible to ensure that the business vision and strategy is accurately represented in both the current and future state solutions.

The true value for an organization will lie in the “to-be” or future state solution which provides them with a foundation for executing on a business or process enablement vision, it may be provided through the ability to find or locate information or expertise more easily through search or it may be realized through infrastructure and application streamlining and the efficiencies associated with operating a less complex or optimized environment.

The value to each organization is different, as are the metrics they apply in judging what represents true value with respect to executing on their business strategy or vision.

For example, I've seen customers who have focused on the quick win aspect of migrating their simple template based applications - a great approach as they seek to gain momentum in the transition away from Domino - but at the same time they've overlooked the savings achievable by migrating or rebuilding more complex applications which were costing them countless hours in code maintenance and support time each year.

Some key tasks organizations undertaking an application migration might consider :

• Creation of a comprehensive application database inventory
  • Identify whether the application is being used
  • Is it template based or custom built

• Identify who the owner is and actual users are
  • Identify the owner of the application
  • Identify who uses the application

• Categorize the application according to it's "to-be" state (some suggested categories)
  • Migrate - move to another platform
  • Archive - move to cheaper storage or tape.
  • Rebuild - functionality replaced in a new application.
  • Web-enable - left on Domino and web-enabled.
  • No action - left on Domino and accessed via client

• Identify the true business value the application is providing
• Work with the application owner to identify what function it serves organizationally
• Identify the key functions that it provides
• Evaluate the value of remediating the functionality to another platform
• Create a "to-be" recommendation for the application.

Whilst the above list is a somewhat cut-down version of the things that should be considered when evaluating migrating an application to another platform it's a good start for organizations looking for a starting point.