Enterprise Migration

Most legacy migration projects involve bringing up to par or scaling existing systems which have been running in production for decades; such system are typically in the banking, insurance and financial sectors and usually these systems have evolved over time into behemoths! So much so there is usually tremendous inertia for change due to their complex and mission critical natures.

We have undertaken and executed migration of such large enterprise systems many times and they are proof of the engineering project management, design and implementation skills ofVulcantech

The problem with legacy systems is that there might be a lot of code (many times redundant), there usually isn't enough documentation and typically there are many customizations and add-ons over time to the base system.

The overarching aims for any migration of an enterprise legacy system is

a. To ensure a smooth transition of the live system under use day in and day out i.e minimize downtime

b. To provide for the new system all the features that were available in the legacy system i.e provide same feature t based on set

c. To add a host of new feature request based on customer input and requirements i.e add pressing feature requests and enhancements. Many times these become the driver for the migration in the first place

tc

d. To streamline and optimize the overall system while performing this migration i.e find out places where one can optimize; this may be due to by using more efficient processes and/or algorithms or simply due to a change in circumstances where certain features are no longer required

e. To use the appropriate technology solution proving maximum ROI for the client

We approach any migration with our in-house developed VulcantechMP(tm) (Vulcantech Migration Plan); it comprises of

Phase 1: Understanding the existing usage of the system i.e business context and the code i.e technical context

Phase 2: Planning out the various phases of migration; this might involve splitting the existing system into modules and planning different migration road-maps for different set of modules

Phase 3: Designing the actual migration process and its components

Phase 4: Zeroing on the technology aspects of the migration - for example, what will be the end system technology? what tools can we use to help the migration? what database back-end should we use? do we require a new data warehousing & reporting system?

Phase 5: Discuss with the client and get sign-off on the final migration plan

Phase 6: Implementing the migration solution to create a system running in parallel with the live one

Phase 7: closely working with the client to make sure things are on track in the "beta" migrated system. Make sure all data in the live system is also captured in the beta system

Phase 8: Plan and make a switch over to the new system from the legacy system i.e "switchover phase"

Phase 9: come up with a plan for maintenance and new feature requests

We achieve the above model by using cutting-edge project management techniques and programming methodologies in our execution. We are agnostic to platform when it comes to migration - we have done migrated both Windows(tm) and Linux based systems; we tend to implement solutions with open-source toolkits and libraries wherever possible due to their cost-effectiveness, quality and availability of their source to make changes and customize to suit our requirements.