Designing a Successful Pilot Phase for Your Cloud Migration

Pilot phases, or pilots, as we will call them from now on, should be conducted to test and find the positive and negative aspects of a particular use case, design pattern, or application migration approach. They allow you to validate the foundation of your architecture (for example, with a landing zone governed by AWS Control Tower).

In this blog, we will show you a systematic approach to scope a successful pilot. This process will help you uncover organization-specific issues that can become expensive if not identified and taken care of early on. If your data landscape involves many dynamic reporting queries in SQL procedures that require refactoring to get rid of proprietary licenses, picking a relevant use case as a pilot will help you understand the associated complexity and effort.

Issues with using simplistic pilots

Teams tend to pick quick and easy pilots to minimize application and business team involvement. Or, they choose to test non-business-critical applications to avoid retrofitting or refactoring. Sometimes, teams limit their pilot to test only specific application components. This can look like migrating batch interface packages without considering the end-to-end design and impact on data ingestion and boundary systems.

When teams narrow their focus to these quick and/or easy migrations, it can delay their cloud migration efforts. To establish reusable standards and control mechanisms, we suggest using more complex use cases and being more intentional in determining suitable pilots. With these initial guiding principles in place, let’s discuss the key considerations in developing the set of pilots to migrate.

Figure 1. Pilot consideration process

Pilot suitability criteria

Successful teams determine the most suitable pilots out of a portfolio of hundreds or thousands of business applications based on the following criteria:

• Portfolio representation. The pilot should represent the architecture and technology stack of similar business applications and their complexity. If you operate in a regulated environment, picking a regulated application to build and test the controls framework will help you build a relevant experience for the next application migrations. Isolated or custom use cases are less suitable in building a repeatable experience.
• Migration strategy. Teams often start cloud migrations with a single pattern such as an automated rehost to Amazon Elastic Compute Cloud (Amazon EC2). However, business and technology drivers may require various migration approaches. These can include manual reinstall to Amazon Linux 2, automated deployments with infrastructure as code, moving to software as a service (SaaS), or refactoring to open source databases running on Amazon Aurora and Amazon Relational Database Service (Amazon RDS). Choosing a varied approach migration strategy will give your teams hands-on experience and help you avoid delays that can happen when you focus on a single pattern.
• Target design. Different architectural patterns exist in every application portfolio. Oftentimes, these patterns are represented by a small set of target architectural designs. For example, commercial off-the-shelf applications with cloud-compatible operating systems may be a suitable target for rehost to Amazon EC2. Event-driven analytics applications may better fit a serverless design pattern. Modern applications with regular releases may benefit from a containerized design pattern. You can account for these needs by promoting various target design patterns and different use cases in your pilot and build the foundations early on.
• Stakeholder availability. Even in a pilot, design and execution require involvement of all relevant stakeholders. This includes application developers, architects, IT infrastructure teams, as well as IT and business leaders. This joint collaboration across relevant teams reduces waiting times for knowledge transfer, technical permission setup, approvals, and decision making.

Considerations for your pilot’s success

Make sure you’re intentional in how you determine the success of the pilot and gather evidence. We have found that successful teams establish envisioned outcomes. Then, they use the pilot phase to validate the underlying assumptions on expected performance, cost savings, impact on operations, cutover experience as perceived by business users, and overall business value. Key considerations include:

• Return on investment. What is the actual migration effort? What are the key effort drivers? How do you optimize for subsequent application migrations? What are the actual cost savings? In other words, what can you save on licenses, right-sizing, or reduced operational effort?
• Technical feasibility by migration approach. How do you orchestrate the migration and cutover activities with automated rehosting? How do you deploy with infrastructure as code? Which tools and processes should you establish as your standard and follow for the remainder of the business application portfolio?
• Performance of target services on AWS. Determine the AWS service configuration required for your performance needs and validate that its performance is better than on premises. For example, the technical validation of high-performance computing or compute-heavy batch processes on AWS will typically include performance tests with the same data set against on premises and AWS.
• Operating model. How disruptive is the migration on the role and responsibility model as well as daily tasks? Validate the degree of change in how application teams deploy infrastructure. How do they interact with IT operations teams? What operational tasks are assumed when moving to serverless services, such as AWS Fargate or AWS Glue?
• Security and compliance. Determine the implications of compliance regulations and internal governance policies on the migration process. For example, validate risk controls framework for GxP, Health Insurance Portability and Accountability Act (HIPAA), or minimum requirements for risk management compliance and the associated validation effort for each application.
• Business user impact. Identify how the migration to the new technology stack and/or operating model impacts your business. Also, assess the requirement for application downtime and involvement of end users during cutover as part of the pattern selection process.

Pilot outcomes

When planning pilot migrations, quality is far more important than quantity. The pilot establishes key outcomes to accelerate follow-on migrations. These outcomes include:

• Developing reference architecture and deployment templates. Target design architecture that will become a blueprint for the rest of the applications that match the specific design pattern. Reusable build and deployment templates from the pilot migrations help expedite the migration at scale.
• Building operational readiness blueprint. Build the initial minimal viable product for operating on AWS. Identify the areas where IT teams should be trained to manage cloud operations.
• Acquiring a tailored migration plan/baseline. Pilots provide a good approximation on level of effort and cost to migrate other applications falling in the same pattern and validate the assumptions underlying the initial baseline.
• Identifying internal champions. Dedicating team members to the pilot phase will establish initial advocates for change within the organization. Champions lead by example, share their experience, and help coach other team members along the way.

Conclusion

Good pilots help establish a solid foundation to adopt cloud at scale and give real work experience to migration teams to avoid delaying cloud migration. By only picking “quick wins,” you will have short-lived success, but your progress will stall if your teams are not systematically building on pilot and migration experience.

Further reading

More guidance on scaling and accelerating your company’s cloud transformation can be found in the AWS whitepaper on Cloud-Driven Enterprise Transformation on AWS.