This blog comprises of 4 parts:
- Part 1 – Choosing the cloud provider
- Part 2 – Challenges
- Part 3 – Roadmap to migration
- Part 4 – (This entry) Learnings
We hope you find this blog useful as you plan migrations to cloud from in-premise and vice-versa. Do reach out to us at [email protected] to help with your migration needs.
Part 4 – Learnings
In this final part of the series, we talk about the learnings we had from this migration project.
Plan and estimate the project
Create a high level plan for the complete migration project with milestones and define clear goals for each milestone. Creating a plan will allow you to visualize the complete project and give the planners a birds-eye view of the roadmap.
It is imperative to do this along with leads of all the modules since applications in production have a tendency to have hidden implementations that may break during the move if not properly planned. Examples of these type of issues include: Hard-coded IPs/Hostnames, Local storage usage and other “host-bound” implementations.
An exercise that is useful for the planning phase is to describe this to the individual leads and ask everyone to contribute to the overall plan by bringing in the internal and external dependencies for each of the modules.
This exercise not only helps in the migration effort, but also throws up areas of improvement in the project that can eventually break tight coupling between modules.
Stick to the agenda
The planning exercise is bound to throw up interesting areas of improvement. Actively avoid taking on the improvements as part of the migration project unless absolutely necessary. The migration exercise is complex enough without the improvement goals, so sticking just the migration project will help towards the success.
Create an acceptance test plan
Invest in building a test suite and acceptance criteria (if it doesn’t already exist) for each module before the migration project is started. It is well worth the effort spent since this investment will pay dividends even after the migration is complete. At the very minimum, invest in an automated sanity test and documented feature manual test cases the define the quality gate for any release.
Take time to document this for each of the modules so these can be run in an automated way as possible. Minimizing the time to “accept or reject” a release will allow you to be agile while the migration project is underway.
Invest in building a CI/CD pipeline
Try to build in a CI/CD pipeline as a required process improvement for the migrated project. This will prove very beneficial once the movement is ongoing due to the reduction in time and errors faced during deployments. It will also allow developers to deploy directly to dev/staging environments without the need for Infrastructure approvals and such. Net effect of this is reduction in the amount of time needed to build/finalize a feature.
Identify external stakeholders
External stakeholders are third party companies and/or vendors that perform an important function for the company, and use the product in question to perform that task. They could be companies that use an API or an FTP location exposed by the product to retrieve or deposit files. They could also be APIs the product depends on, such as Google or Morningstar APIs typically used for common functions in a project. It is important to identify all such stakeholders, those who consume our APIs and those whose API is being consumed by the product.
Review the terms of use for external APIs and the access details for internal APIs to get a gauge of external tests that need to be added to the acceptance test plan.
Define Phases
Define phases in the project coupled with external releases/GA.
For e.g. Phase 1 could be defined as “Deliver UI from AWS S3/Cloudfront”.
If this type of planning is possible, it allows modules to be stabilized and the whole project can be de-risked instead of a big-bang approach to movement. Phase wise movement may provide some level of comfort to the team since all modules are not moving simultaneously. It also allows the team to focus on one module at a time which has a bearing on quality.
The downside of these type of module-wise external releases are the associated costs. This approach keeps the dependency on both environments until all phases are complete, which may be a significant cost over a period of time depending on the project. However, this also enables a small dedicated team to perform the move in a de-risked manner.
Lift and Shift First
Identify all modules that can simply be lifted and shifted. If there are no major dependencies on cloud-native features, this can be done in a relatively easier manner. Prioritize lift-and-shift over any of the other modules that need code-development or changes. In the Phased release approach, the lift and shift modules can end up being moved to the new cloud much faster.
Define 4 environments
We recommend creating 4 environments with CI/CD support for the migrated application.
Dev – Development environment where bleeding edge changes can be pushed.
QA– QA environment where development-tested changes can be pushed for QA to review and verify.
UAT – User acceptance testing where the Sanity and regression tests must pass before a feature is promoted into production.
Prod – Production environment accessed by end-users.
At the very minimum, plan for Dev, UAT, Production environments.
Deploy early
The closer the QA and UAT environments are to the production environment the better it is for the movement. Deploying using CI/CD to a mirrored production environment will allow QA teams to verify features against actual data and will safeguard against bugs that may be data-related, especially if there are code changes involved.
In our project, we migrated data from the existing production environment database to a mirrored production setup every week and ran incremental verification tests weekly to verify functional parity between these environments.
Deploying to a production environment early is a good way to ensure that the movement is tested well and the overal project runs smoothly.
Communicate clearly
Projects that are in production with scores of users are generally complex to migrate due to the number of different modules and components that may be actively being used. Moving a complex product like this involves bringing together stakeholders from various teams, understanding daily/weekly activities that are being done using the product. e.g finance reports and other such reporting and configuration activities.
In this environment, communication with all stakeholders for every step is critical.
We recommend setting up a migration group and a bi-weekly meeting to bring together all stakeholders to identify interdependencies and get help to fix them.
Program Management
A program manager is invaluable as you undertake this type of migration activity, especially if the product in question has active users and is in production. A program manager can help sort the communication that is required to keep all stakeholders informed and plan activities in a logical manner.
A single person to communicate with also greatly simplifies the communication across all stakeholders and keeps information flowing freely across teams of different modules. This is imperative to keep everyone motivated and communicate results across all teams.
