How to engage application teams during a cloud migration

Engaging effectively with application teams is key in scaling out your cloud migration initiative. Some application teams want minimal involvement in the migration process. Others view it as opportunity to enable their engineers and learn by doing. In this post, I discuss the pros and cons and suitability criteria of three engagement models.

• Deliver (“do-for” mode) whereby a central migration team delivers most migration tasks on behalf of application teams.
• Assist (“do-with” mode) whereby the central team works alongside application teams, offering on-the-job training for them.
• Self-serve (“let-do” mode) whereby application teams deliver migration tasks using migration tools and solutions offered by the central team.

The models vary in the degree of autonomy delegated to application teams. With higher autonomy, the role of the central migration team shifts towards enabler and solution provider. Caution is advised, as prematurely launching any engagement model can result in poor experience for application teams, especially if it doesn’t align with their autonomy and preference.

Engagement models

When designing a large migration program, one key and often overlooked aspect is how the migration team should engage with application teams. Sometimes, centrally run migration factories using Cloud Migration Factory AWS Solution receive insufficient demand and backlog by application teams. Development organizations may opt for varying degrees of central enablement to migrate on their own.

The decision of how much responsibility you shift towards application teams depends on their capacity, skills, experience, operating model, application type, and overarching priorities. I recommend using the three models in tandem to address different use cases and maximize impact.

Typically, organizations start by building a central migration team to deliver on initial migrations end to end (“do-for” mode). This helps expedite experience and establish initial standards. This is particularly suitable in organizations with a traditional split of responsibility, in which application engineers have no administrative access to their application infrastructure. Over time, the central migration team can start onboarding application engineers to assist with application migrations (”do-with” mode) and expose migration tooling to self-serve (”let-do” mode). Figure 1 provides a visual overview of the three models.

Figure 1. Engagement models to support application teams moving to the cloud

Example use cases (Figure 1):

A) Application teams have insufficient capacity and experience to deliver on a strict timeline so central teams perform most tasks.

B) Application teams have the capacity to support the migration (but are not self-sufficient) learn on the job alongside experienced engineers.

C) Self-sufficient application teams are onboarded under the central program to manage cross-team dependencies and strict timelines.

D) Self-sufficient application teams move at their own pace and consume the migration tools and solutions offered by central teams to reduce effort and ensure compliance.

Model 1: Deliver (“do-for”)

This model builds experience baseline around a central migration team. This expedites organizational learning and the development of standard migration process and tooling. As the migration team is assuming migration responsibility and effort centrally, its focus is typically on keeping the engagement with application teams as efficient as possible.

This model offers an easy way to bring in external expert know-how such as system integrators and scale it across the organization. The downside of centralizing the migration team is a common denominator approach to cloud migrations. For example, the central team may not have the capacity and flexibility to accommodate for special requests such as custom system architectures.

Model 2: Assist (“do-with”)

With this model, you maintain control over the migration progress while sharing migration tasks with application engineers. The central team’s focus is on establishing mature processes for knowledge-sharing, onboarding and upskilling via formal training and hands-on learning. Onboarding of application engineers on the central migration program can occur in multiple steps with increasing responsibility. For example, application engineers start by shadowing how migration engineers build the development environment for their application. They reverse-shadow the migration of the integration environment, before assuming full responsibility for the production migration.

This model suits well with teams who see the migration as opportunity to upskill themselves and avoid handovers between migration and application teams. Usually, full-time dedication of application engineers is essential for the success of this model. Caution is advised as third-party commercial or legal arrangements may prevent application teams from sending their engineers for training and enablement. In such cases, the self-serve model provides an alternative.

Model 3: Self-serve (“let-do”)

As organizational maturity increases and knowledge spreads across teams, moving applications to the cloud becomes commodity. This provides opportunity to reduce the central team involvement for common use cases like migrating two or three-tier systems with load balancers, virtual machines, container services and relational databases. The role of the central team shifts toward offering tools for self-serve migrations. In addition, self-serve migrations free up central team capacity for enhanced support of custom use cases with a high value-add.

This model is particularly desired in large development organizations which have the capacity to migrate on their own and in federated IT organizations with many vendors and distributed ownership. Self-serve migrations allow application teams to migrate at their own pace. Since the central team has limited control over the migration progress, they use a platform to provide migration services that allows them to maintain visibility over the actual consumption. For example, using AWS Migration Hub or an internal developer platform such as Backstage.

Comparison

The three models differ along the following aspects (Table 1).

• Governance level – what is managed centrally by the migration program?
• Role of application engineers – what is the responsibility split and degree of autonomy?
• Use case – when is each model applicable?

Table 1. Engagement model comparison

For best outcomes, complement each model with governance mechanisms. For more information consult the Project governance playbook for AWS large migrations. The governance level and scope vary from coordinating tasks to providing solutions and tracking their adoption.

Benefits

The three models can be used in tandem to fit different use cases and application team arrangements. Organizations expanding their engagement with application teams will gain the following benefits.

• Personalized migration experience instead of a one-size-fits-all approach.
• Higher flexibility to accommodate custom requests which don’t fit the central team standards.
• Greater migration outcomes by encouraging active participation by application teams without the need to increase central budgets or add more contractors to do the work.

Conclusion

This blog post discussed three common models of how to engage application teams during a cloud migration. The three models can be used in tandem to address different use cases and maximize impact in your organization. The decision of how much responsibility is shifted to application teams depends on your organizational maturity.

Additional resources

• Large migrations to the AWS Cloud
• Designing a successful cloud migration: top five pitfalls and how to avoid a stall

About the author