Share:
onpost_follow 1

 

migration projects

With the IT shift to cloud and business shift to cloud-based data platforms, there is a growing increase in migration projects, which aim at migrating applications and data from a corporate data centre to a cloud platform. The migration may be mandatory because of a merger or acquisition, in which data from another organization has to be migrated to a new or existing environment, or because a business segment has been sold, which requires migration to storage elsewhere. In some cases, migration may be a deliberate strategy towards better service delivery.

Why migrate?

Before we move to migration strategy and delivery model, we first need to understand why migration is required, and why is it important for businesses to migrate their data.

  • To overhaul an entire system – For instance, the organization may find its databases or systems outdated and may want to move to a newer platform, or an industry standard. This would involve migration from the legacy system to the new.
  • To upgrade databases – The databases may still be valid, but may need to be upgraded to newer versions. This would involve migration from older to newer versions of the system.
  • To deploy another system that sits alongside existing applications – Very often organizations would like to have an alternate or backup system in place. This could be for BCP purposes or merely to mitigate risks of having a single system. It could also because they envision the existing system getting outdated soon and would like to be prepared with a backup system in parallel. In this case, the migration would mean the data gets ported to the new system, but also co-exists in the existing system
  • After a merger or acquisition – This is perhaps one of the most common reasons for migration, when disparate systems that come together after a merger or acquisition need to be brought into a single version of truth. It also saves the organization’s licensing costs by limiting to a single data warehouse. For example, we worked with a large gaming enterprise that went through multiple mergers and acquisitions over the past decades. Because of all the mergers and acquisitions, they ended up with several versions of data and information across various sources. They wanted to have a single consolidated data warehouse with unified data structures and process.

Migration strategy and approach

Typically, a large migration project needs a dedicated team (and sometimes a strategic partner) for carrying out the migration. This is important since a qualified and experienced migration team will fill the gaps in resources that universally exists among all service providers attempting a migration. A migration project requires resources strictly dedicated to the various aspects of the migration, including program management, product and service development, engineering support, and technical and operational expertise.

One of the key things that you need to decide as part of a migration project strategy is the location – whether to execute the project at onsite or offshore, or through a hybrid model.  Several project factors would affect this decision, and it is therefore important to understand what these models mean so that the right decision can be taken.

Global Delivery Location Model

The global delivery model refers to the process of executing IT projects using resources located at multiple sites across the globe. There are various types of Global Delivery Models, as described here:

  • Onsite Delivery Model – In this model, consultants are deployed at the client site, working from the initial consultation until the project’s completion. Representatives will have face-to-face client interaction and a clear understanding of the client’s requirements and policies. There are no communication gaps, which enables better project control and management.
  • Offsite/Nearshore Delivery Model – In this model, a consultant works remotely, but resides in the same city or country as that of the client. There could be more than one onshore work site. It may also be possible that some consultants will work at the client site while others work from a remote location within the same territory.
  • Offshore Delivery Model – In this model, all the project tasks from the start until completion will be accomplished at one or more offshore sites using an outsourcing team. This model lends itself to achieve lower costs of operations.
  • Hybrid Delivery Model (Onsite/Offsite + Offshore) – This model features the combination of onsite, offsite, and onshore models. The Hybrid model provides the cost-effectiveness of the offshore model as well as the face-to-face contact that is crucial to preventing communication gaps and ensuring your projects’ success. The ultimate solution is usually the integrated Onsite-Nearshore model, as it is usually as effective as the Onsite model, yet offers the cost-efficiency of offshore development.

How to Choose the Right Delivery Location Model

For each migration project, several factors help decide the location for the delivery. Some factors lend themselves to one or the other model directly; whereas some factors are more ambiguous and need deliberation before an informed decision can be taken.

Some of the factors governing this decision are explained here, and in each case, it helps to see which model is favored.

  • Stage and scale of project – The larger the migration project, the greater the need for coordination between onsite and offshore. Typically, a large project would be executed in a hybrid model where the initial analysis and design stages are handled at client site/onsite and then the development and execution can be done offshore. Also, if the project is already at a stage where speed and turnaround time are paramount, having the team onsite to complete the project makes more sense than trying to offshore it. If the project is well planned, with ample stages for design/analysis and then transition and delivery, then the initial stage can be executed at onsite with the latter stages moving offshore.
  • Outsourcing maturity and strategy – The level of organization maturity towards offshoring would play a major role in this decision. If the client organization is mature, understands how offshoring works, has a process framework in place to ensure seamless working of offshore personnel, and has SLAs and metrics in place to measure effectiveness, then the offshore option is a good one. If these are not present, it would be better to go with onsite deployment of the project. The outsourcing strategy of the client also plays a role. A formal outsourcing strategy with well thought-out goals may help offshore the project better. For example, if the strategic goal is to save as much money as possible, then you can focus on projects where work can be sent offshore.
  • Outsourcing infrastructure – This is a huge decider, especially in migration projects. Since we are talking of migration from a legacy environment to a newer environment, you need to examine the infrastructure dependency at onsite and availability at offshore. If the infrastructure is highly specific to the client environment and cannot be replicated offshore then the decision is simple – the project needs to be executed at onsite. If, however, you can recreate the environment at the offshore site and can ensure seamless access to the resources to work from the offshore location, then the offshore model can be considered. Even then, the migration projects team needs to do a complete environment and infrastructure feasibility study and test, before deciding to move the project offshore.
  • Work breakdown within the project – Very often, the nature of the project and the way the project tasks are broken down decide the split between onsite and offshore. Tasks that are heavily dependent on the client team or environment need to be placed onsite only. Tasks that can be done with minimal dependency can be moved offshore. Even if considering a hybrid model, the split of work between onsite and offshore would depend on these factors.
  • Migration strategy – Migration projects can take one of three approaches to the migration – a big bang approach, a parallel/shadow approach or a phased approach. The approach adopted can also have a bearing on the decision of placing the project onsite or offshore. If the big bang approach is taken, it typically means that the migration is being done on a war footing basis, and would be executed in a short period of time with maximum intensity and focus. For such an approach, having the project completely onsite and close to the client makes more sense. In the parallel or shadow approach, certain tasks are run in parallel between the old and new systems while migration is planned. If this approach is adopted, it makes sense to have a core team located at onsite to decide on the parallel runs and to monitor them, while there can be a team at offshore looking into the migration tasks on the ground. If the phased approach is taken, then the team could be predominantly placed offshore after an initial due diligence and pilot phase at onsite to validate and establish the process.

Conclusion

You have the option of executing migration projects from either onsite/client site or offshore, or even a hybrid onsite-offshore model. The kind of project, its scale and stage, its task breakdown and dependencies, and its ease of operations and dependency on infrastructure could be some of the factors that influence where the project can be executed. In addition, the client’s outsourcing strategy and maturity to offshoring plays a huge role in the decision as well. The migration approach and workflow would also have a bearing on this decision. In summary, the idea is to make the migration projects as effective as possible, and choosing the right delivery location model is key to this success.

Share:
onpost_follow 1

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

clear formSubmit