If you're looking to transition your current applications from on-premises to the cloud, or from one cloud to another, there are certain steps you can take to ensure a seamless migration. In this blog post, we'll go over these concrete steps to help you plan and execute your migration with minimal disruptions.

When it comes to migrating your applications, it's important to have a clear and organized plan in place. One way to do this is by dividing the process into these three distinct phases:

• Concept - Planning and preparation

This phase is all about gathering the necessary information about your applications, identifying potential roadblocks, and creating a detailed project plan. By taking the time to thoroughly plan and prepare, you'll be setting yourself up for a smoother migration process.

• Implementation - Execution

This phase is where the actual migration takes place. This could include tasks such as configuring the new infrastructure, deploying the applications, and testing to make sure everything is working as expected.

• Completion - Post migration

After the migration is complete, it's important to monitor the applications in the new environment to ensure everything is running smoothly. This phase also includes addressing any issues that arise, training users and administrators, and documenting the entire migration process for future reference

Lets look at these three phases in detail.

1. Concept Phase

Concept phase is divided into these activities:

Discovery and Analysis

When planning a migration, the first step is to gather all the information about the applications that will be moving to the new environment. One way to do this is by creating an application details document for each application. This document should include information such as:

• Application name and version
• Number of users and usage patterns
• Business purpose and function
• Contact information for vendor, business owner and technical owner along with their contact details
• High level component diagrams exhibiting component type and which server it is hosted e.g web application components can be web site, caching layer, api, database and each could be hosted on different servers
• Integration diagrams outlining the communication or dependency link between the given application and all the other applications
• All the security accounts required for the application e.g. database logins, service accounts
• Key resource utilization (CPU/memory/network utilization)
• Performance benchmarks
• Known issues

Current Landscape

Current landscape is a one page architectural view of all the applications considered for migrations. It should also provide the current cost of running the application on the existing servers, including the cost of hardware and software.

Migration Strategy

Migration strategy will outline why, how and when the applications will be migrated and should include:

• Purpose or business case for migrations e.g. what benefits will materialize from migration
• Decision tree (or list of eligibility criteria) for determining application acceptability for migration. e.g. vendor/development team is available to perform the migration activities, application detail and support documents are available to facilitate and troubleshoot migration, no impact on application licensing, no performance impact, no feature impact
• Group the applications based on the architecture or deployed components. e.g. web application, database, services etc. Then define the generic approach for migrating each type of application. e.g. for databases, backup and restore
• Provide the approach for migrating each group of application. e.g. for databases, do backup and restore
• Provide testing approach for each group of application. e.g. load testing for databases, regression test for web application
• Proposed list of applications for migration
• Final list of applications for migration which met the eligibility criteria
• Define risk and effort for migrating each application. The risk can comprise of size or complexity of the application and business loss in event of unavailability. Drive effort from time required to prepare, migrate and test the application.
• Outline the migration plan with time frame of each application migration. Risk and effort will have input into devised plan. e.g. Low risk and small effort applications are migrated first or vice versa.
• Acceptance criteria for successful migration e.g. all features are working, integration with other application functional

Consolidation Strategy

During the migration, there might be opportunities to host multiple applications, databases on single instance of the server. To evaluate and execute these opportunities, consolidation strategy should include:

• Purpose or business case for consolidation e.g. what benefits will materialize from consolidation
• Materialized benefits of consolidation, saving in terms or dollars. Consider capturing number of CPUs and memory used before and after consolidations, and use it to calculate savings in dollars

Future Landscape

Future landscape is a one page architectural view of all the applications after the migration. It should provide the cost of running the application on the new servers, including the cost of hardware and software.

2. Implementation Phase

Implementation phase is divided into these activities:

Pre Migration Checklist

Checklist per application which include:

• Is migration date finalized? (Record the date of migration)
• Are business stakeholders engaged and communicated? (Record stakeholders name and type of communication sent)
• Are vendor/developer/support teams availability checked and their times are booked?
• Is application detail document available? (Completed during Concept phase)
• Is application support document available? (Acquired from support team/vendor)
• Is deployment/rollback plan available? (Can be completed during Concept or Implementation phase)
• Is test plan available? (Can be completed during Concept or Implementation phase)

Migrate/Test

This is the step when application is migrated to the new environment. In spite of all the planning, problems may arise during the migration and atmosphere can become chaotic. During those times, use the support team and helping documents to bring calm to the chaos. Execute testing according to test plan to ensure application is intact and all features are working.

Post Migration Checklist

Checklist per application which include:

• Is migration completed successfully? (Record the date of migration)
• Has stakeholders signed off on the successful migration? (Record the names and sign off date)
• List any follow up tasks? (Server names to decommission , post migration review to be scheduled)

3. Completion Phase

Completion phase is divided into various activities:

Decommission Old Infrastructure

Once all the applications are successfully migrated, switch off old servers. It is recommended to completely decommission infrastructure after 60 days of no issue reported.

Reporting and Metrics

Create reports to capture:

• What went well and any issues faced during migrations?
• Any learning which be applied to next migration
• Compare the evident benefit against the proposed benefit
• Capture performance metrics for migrated application and compare against the pre-migration performance metrics