Common Reasons for Migration

The first step when thinking about migration of your software to understand and define the reasons for the migration. The various options that need will need to be evaluated in the context of these reasons. In our experience, the common reasons for a migration are:

Vendor lock-in: Traditional commercial software is usually closed source. This leads to situations where your business ends up depending on the release cycles and response times of the vendor providing the Software. A big limitation of closed source is that you cannot customize or add features without buying expensive consulting services from the vendor. Another problem arises when vendors have their own proprietary standards and do not use an industry standard or protocol in their product. In these cases, you might want to migrate from this vendor to those who provide source code with their Software or to those vendors who follow industry standards and make it easy to switch vendors in the future.


Performance/Scalability: Your application might not have been designed for today’s load. The hardware on which it runs might not be able to meet the performance demands. The Software might need to be re-architected to support the changes in business and customer usage.

Reliability/Availability: The system downtime that used to be acceptable might be hurting your business now. The costs due to handling support issues and manual intervention due to the unreliability of the system might drive you to migrate to a more reliable solution.

Extensibility/Adding New Functionality: Your current system might have evolved over a period of time with new features being added that might be imposing a huge burden on its maintenance and adding a new feature might be getting prohibitively expensive. You might want to migrate it to a solution which is extensible so it becomes cheaper to add new functionality in the future.

Usability: Your current solution might be causing revenue drains because it is difficult to use. You might be spending a considerable amount of money on training your employees on the system. You might desire to migrate to newer user interfaces (e.g. web-based using AJAX) to speed up your business processes and increase your profitability.

Integration and Interoperability: An application rarely works independently of other Software. There are various integration points with other Software for reasons such as process efficiency (e.g. single sign-on), business reasons (mergers and acquisitions) etc. In such cases, usually a complete migration is not the optimal. Software bridges, re-architecting the application to service oriented architectures (SOA) is more suitable.

Obsolete technology: Software technologies move at a rapid pace and technology gets outdated fast. When the vendors stop supporting the technology, migration is forced on to you (e.g. some Visual Basic to .NET migrations fall under this category).

Cost: Reducing costs is a fairly common reason for migration due to various business causes such as cut throat competition, rising software licensing costs and total cost of ownership of the Software. Migrations from proprietary Software to free open-source Software fall under this category.

Changing market dynamics: Customers expect your solution to be current with the latest market dynamics. For example, instead of a shrink-wrap product, the market is moving towards Software-as-a-Service (SaaS).

Does Outsourcing Software Migration Projects make sense?

Software Migration projects are well suited for outsourcing. Why? Here are three simple reasons.

First, software migration is not your core business. You are migrating software due to some business reasons – maybe customers want your product on a modern platform, or maybe your older solution has outgrown its purpose and no longer meets your requirements and you desire to migrate to a more suitable platform. Whatever your reason to migrate, this is not something that you should be spending your engineers’ time or hiring staff. Your engineers should be spending their time on core aspects of your business and working on adding features that will keep you ahead of competition. You don’t want to hire new staff because you will need to worry about what to do with them once the migration project.

Second, it is cost effective. Software migration is an engineering disciple by itself. There are tailored software processes and best practices that have evolved a period of time. It is not practical and not sensible for you to invest in learning these methodologies as it is not your core business. This is the job of companies that specialize in Software migrations. They can provide value to you based on their expertise and experience. Outsourcing to qualified companies can lead to considerable cost reductions.

Third, the scope is defined in a much better way. Unlike new software development, the requirements are much better defined in a migration project. In regular software development projects, it is very common for requirements to evolve as the product is getting built. This is due to a variety of reasons – the end user starts realizing the requirements after seeing something. It is well known in the Software industry that a majority of software development projects are over-budget and over-schedule primarily because the requirements are not captured and managed properly. This is an inherent feature of new software development. Hence, people undertake working prototypes, create a version to throw it away so they can then develop the ‘real’ version etc. In the case of Software Migration projects, you are in a much better position to crisply define the requirements as you already have an industrial-strength version already up and running. You probably have a good handle on the performance numbers to expect and use cases for all different scenarios. Given this, it is very convenient to define the requirements and the acceptance criteria, a key aspect of outsourcing any project.

There are several more reasons why outsourcing migration projects makes sense – might be the subject for blogging some other day…