Agile Case Study — Migration of Legacy Application to Cloud -

Photo by Christina @ wocintechchat.com on Unsplash

Migration of legacy Application to more advanced technologies and platforms is a current issue for many software organizations. As per Current market trend Cloud Base Solution is one of the best approaches for the same. When most of the legacy Application move it to Cloud Environment its Consider as SAAS (Software As A Service) Based Product

What are the benefits of Migration of legacy Application to Cloud is as follows

• Reduced Costs
• Automation of Migration Activities
• Reuse of System Functionality
• Scalability
• Business continuity
• Collaboration efficiency
• Flexibility of work practices
• Security
• Easy to Maintain
• Easy Database Backups
• Performance
• Quality Control

For this Case Study We have options of 2 Agile Frameworks such as

• Scrum
  This is a Framework for managing and organizing agile projects
• Extreme Programming (XP)
  XP includes practices that are more technologically oriented and supports different development activities such as programming, code integration and testing

As per AWS they have “The 6 R’s”: 6 Application Migration Strategies

1. Re-host (Referred to as a “lift and shift.”)
   Move applications without changes. In large-scale, legacy migrations, organizations are looking to move quickly to meet business objectives.
2. Re-platform (Referred to as “lift, tinker, and shift.”)
   Make a few cloud optimizations to achieve a tangible benefit. You will not change the core architecture of the application
3. Re-factor / Re-architect
   Re-imagine how the application is architected and developed using cloud-native features. This is driven by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment.
4. Re-purchase
   Move from perpetual licenses to a software-as-a-service model.
5. Retire
   Remove applications that are no longer needed. Once you have completed discovery for your environment, ask who owns each application.
6. Retain (Referred to as re-visit.)
   Keep applications that are critical for the business but that require major refactoring before they can be migrated. You can revisit all applications that fall in this category at a later point in time.

The objective of the migration plan is based on below things

• Managing the Scope
• Schedule
• Resource Plan
• Issues
• Risks
• Coordination
• Communication to all stakeholders

We need to Consider following areas At the time of Migration of Legacy Application

1. Requirements and Feasibility Activity Area
   In the requirements and feasibility activity area the migration requirements for the system are gathered and the main components of the solution and their implementation strategy are identified.
2. Recover Activity Area
   The purpose of the recover activity area is the recovery of the knowledge from those legacy components that during the feasibility analysis has been pointed as candidates to be re engineered.
3. Migrate Activity Area
   In the migrate activity area the target system is defined and implemented using the elements identified during the requirement and recover phases. This includes also the design and implementation of the components necessary for the SaaS application and the development of the service oriented architecture
4. Validation Activity Area
   The purpose of the validation activity area is to define testing strategy to verify that the migrated system implements the requirements and services work properly.
5. Supervise Activity Area
   The supervise activity area provides elements to monitor and control the performance of the system when deployed in the Cloud and to modify that performance.
6. Interoperability Activity Area
   The interoperability activity area provides tools that solve interoperability problems with 3rd part providers or any external components and services

Application Migration Process

Below mentioned Steps are common for All the above respective Areas.

In Queue
Work Queue
Work Start
Review 1
Post Test
Ready For Release
Released

Definition Of Above Terminology

• In Queue
  This is a list Of Task / Bug / Features / Documentation Which Scrum Master & Dev Team / Support Team Decided to Work on.
• Work Queue
  This is a list Of Task / Bug / Features / Documentation Which are Cleared to Developer / Support Team. This List Contain those Task / Bug / Features / Documentation which not required any Clarification from Product Owner / Scrum Master
• Work Start
  This is a list Of Task / Bug / Features / Documentation On Which Developer / Support Team is working on. This Queue always Contain individual task for every team member. No user will work on Multiple Task on same time.
• Review 1
  This is a list Of Task / Bug / Features / Documentation Which needs to verify by Co Developer Team Member / Co Support Team Member is working on.
• Post Test
  Once Co Team Member move task to Post Test QA Person or Respective Person Need to Verify Task / Bug / Features / Documentation. Wether its properly fixed or not.
• Ready For Release
  This contains list of all tasks which are Ready For Release
• Released
  Once Task Released on live Environment. Release Manager move that task to this queue