Embrace the Power of the Migration Tower Manager

In the “Accelerate Your Enterprise On-Premises Migration to AWS Cloud” blog, we explored the top five guiding principles to review before starting a large-scale migration. One of these principles is to “Issue a Leadership Executive Directive.” Without a clear mandate for cloud adoption, the migration process can become disorganized, leading to a lack of consensus on the migration’s direction.

In this blog post, we will explore the principle of issuing a leadership directive for your migration strategy. We will explore this as it relates to a new role for consideration in your migration strategy, the Migration Tower Manager (MTM). These managers act as the drivers and implementers of the leadership directive throughout the lifecycle of your migration program.

The MTM role was developed to address the challenges faced by complex organizations with federated IT departments. Federated IT organizations often struggle to gain business buy-in for large-scale migrations, even with leadership directives from a Chief Technology Officer (CTO) or equivalent C-level executive. The absence of business buy-in in a federated organization often manifest as a culmination of technical issues that delay or stall migrations. These include: a lack of appetite for migration; gaps in the migration intake and scheduling processes; and insufficient technical skills. In addition, this slows the development of patterns to address specific application migration requirements; and dilutes accountability for the migration program’s progress. This results in low migration velocity, rescheduling and reshuffling of workloads during migration planning, and an unusually high number of technical rollbacks during the migration waves.

Recently, a large organization with a federated IT department experienced approximately 50% of the workloads planned for the large-scale migration being rescheduled unexpectedly during the migration. This was largely due to missed technical dependencies and changes in application owner priorities.

1. The Migration Tower Manager Persona

1.1 What is a Migration Tower Manager?

A MTM is an experienced project manager or delivery manager responsible for application dispositioning, planning, and full tracking of applications throughout the migration process. The MTM is the single-threaded point-of-contact for application owners throughout the migration process within their assigned tower.

A “tower” is defined as a distinct business unit, portfolio, or geography within the enterprise. The tower may have its own reporting structure up to the C-suite, and could even have its own IT department within the larger organization.

1.2 Who should be a Migration Tower Manager?

MTMs are experienced project managers or delivery managers with deep institutional knowledge of and relationships throughout the IT and business organizations. They are adept at managing complex projects and programs. This level of organizational depth and breadth is required so the MTM has the influence necessary with application owners, managers, and other stakeholders within the tower. They can then work to remove organizational obstacles and objections to migration.

MTMs will be responsible for monitoring and tracking all migrations within their assigned tower. This includes complex migrations requiring coordination across different IT groups and support teams. The MTMs should have certifications relevant to leading and delivering large projects and programs. These could include the Project Management Institute’s Project Management Professional (PMP®) or SAFe® Release Train Engineer certification. These certifications accredit the holder with the knowledge and proficiency to manage complex engagements, or in our case, large-scale migrations.

With an understanding of the MTMs’ role, we will next explore how they integrate into the migration governance framework.

2. Migration Tower Manager within the Migration Governance

2.1 Defining Towers and Assigning MTMs

In our scenario, the towers are defined based on our organization’s business units (or departments) during the Assess phase of the migration program: Research and Development, Finance, Manufacturing, Legal, Sales and Marketing, and Technology Services. These specific tower delineations were made in collaboration with the organization’s program sponsor and key stakeholders, based on their intimate knowledge of the organizational structure.

In this example, each tower is an autonomous department led by a single Senior Vice President (SVP), and each SVP reports to a C-suite executive. A MTM has been assigned to each tower. The towers and MTM assignment is a 1:1 relationship; each tower has one MTM, and a MTM cannot be assigned to more than one tower. Figure 1 illustrates this SVP organizational structure with MTM assignments.

Figure 1: Organizational Structure with MTM Assignment

The SVP for Technology Services is the executive sponsor of our large-scale migration. The Technology Services department provides general IT services for each department. However, each department also retains its own federated IT staff to address department-specific applications and specialized IT needs. For example, the Research and Development (R&D) department maintains research lab sites with specialized equipment and software on isolated networks. Finance has payroll and financial tracking applications. The Manufacturing department has specialized computer numerical control (CNC) machines with software and barcode scanners. And, the Legal department uses document management software for the in-house legal staff with coded customizations. The federated IT staffs of each department are responsible for their department-specific software and hardware. In parallel, the Technology Services department maintains the data center infrastructure (network, storage, compute), enterprise software, and end user workstations consumed across the organization.

Our Technology Services SVP does not have the authority to prioritize programs and projects for the other SVPs. Each SVP’s federated IT department has its own function-specific responsibilities and projects. Consequently, fostering cross-departmental alignment and securing buy-in for the migration necessitates consideration of each department’s unique projects, schedules, and proprietary technology concerns. This requires careful planning and skillful negotiation tailored to each tower, led by a seasoned MTM.

With an understanding of how towers and MTMs are defined, we will now explore the interactions between MTMs and the key personas within each tower.

2.2 Understanding Roles within the Towers and MTM Interaction

Within each organizational tower, there are key personas with whom the MTMs must interact and secure buy-in: Technology Managers and Application Owners.

In our organization, each tower’s federated IT department includes Application Owners responsible for operating and maintaining their applications. These applications are grouped by business function into portfolios and overseen by a Technology Manager. Although multiple levels of technology management may exist, we will assume Technology Managers report directly to the SVP of the tower. Figure 2 illustrates this intra-tower organizational structure for our Research and Development (R&D) tower.

Figure 2: Intra-Tower Organizational Structure with MTM Assignment

In our R&D federated IT department, we have three application portfolios: Data and Statistical Analysis, Research Labs, and Computer-Aided Design (CAD). Each portfolio has unique requirements that must be captured and addressed during migration planning by the MTM.

2.2.1 Data and Statistical Analysis Portfolio Example

The Data and Statistical Analysis portfolio includes specialized software for statistical analysis, modeling, and data visualization (using tools such as Python, NumPy, and R). These applications are supported by high-performance workstations with substantial CPU and memory resources. These are required for running complex models and rendering visualizations that standard workstations cannot handle.

As the migration sponsor, the Technology Services SVP has instructed that all workloads be right-sized based on average compute and memory utilization to optimize costs. However, R&D’s high-performance workstations use maximum resources in bursts rather than continuously. Thus, using average utilization for right-sizing may lead to under-provisioned workstations and a less effective user experience post-migration. Our R&D MTM should work closely with Application Owners to capture specific performance requirements. The MTM may request exceptions to the standard right-sizing approach to confirm proper workstation sizing is accomplished.

2.2.2 Research Laboratory Portfolio Example

The Research Lab portfolio is composed of lab sites equipped with instruments such as spectrometers, microscopes, and chromatographs. These instruments connect to laboratory applications on workstations for analyzing and managing data. These lab networks are isolated, and protected with firewalls from the corporate network. This is due to the sensitive nature of the research data, and the use of non-standard ports for communication between laboratory instrumentation and workstations.

The R&D MTM collaborates with Application Owners during the migration planning phase to understand these isolated networks. The MTM then works with the Research Lab Technology Manager to determine whether the laboratory software will be included in the eventual migration.

This may involve coordinating with the Technology Services’ enterprise network and firewall teams to secure firewall exceptions to establish connectivity between the sites and AWS. The MTM will develop a custom migration project plan. This would include tasks for firewall exception requests, rule implementation, and connectivity testing as part of pre-migration activities.

2.2.3 Computer-Aided Design (CAD) Portfolio Example

The Computer-Aided Design (CAD) portfolio includes applications used by R&D engineers for designing and modeling prototypes. These applications are licensed for physical workstations, and the application owners have expressed concerns about the lack of vendor support for cloud-based licensing.

Given these concerns, the R&D MTM will address the potential issues by collaborating with the program’s technical leadership. The MTM will propose and test solutions that meet the CAD software’s licensing and hosting requirements. The MTM will create a pilot migration plan to conduct a proof-of-concept (POC) migration. This will validate AWS hosting of the CAD software, and build confidence among the CAD Technology Manager and Application Owners before completing the migration schedule.

2.2.4 Summarizing MTM’s Role and Interaction with Application Owners and Technology Managers

Each R&D application portfolio presents unique business requirements and technical constraints that may not be covered by a standard migration approach. The MTM’s role is crucial in addressing these specific needs by working closely with Technology Managers and Application Owners. The MTM plays a key role in managing pilot projects, such as the CAD software migration. These are effective mechanisms that build trust and demonstrate suitability for hosting cloud applications.

With a clear understanding of MTM interactions within a tower, we will now shift to a broader view to examine the MTM’s role within the migration governance model.

2.3 Towers and MTMs within the Governance Model

Large migrations typically consist of several core workstreams: Foundation, Program Governance, Portfolio, and Migration. Together, these workstreams form the overall governance structure for the migration. Figure 3 depicts a governance structure of the core workstreams during the mobilize, and migration and modernization phases with the MTM persona.

Figure 3: Migration Governance Model with MTM Persona

2.3.1 Governance Workstream

Our model places the Governance workstream upstream from both the Portfolio and Migration workstreams. Akin to a program management office (PMO), this Governance tier is responsible for developing, implementing, and facilitating program management processes and program-wide governance. Common tasks include setting the organizational model, communication and escalation plans, building RACIs, status, risk, and issue reporting.

Although the MTMs do not have responsibilities within the Governance workstream, they will collaborate with the Governance workstream. This collaboration will generate high-level content to share the program within their respective towers.

For further description of the Governance Workstream, reference AWS Prescriptive Guidance, Migration Governance workstream.

2.3.2 Portfolio Workstream

In our model, the Portfolio workstream is positioned downstream from the Governance workstream and upstream from the Migration workstream. It encompasses the six previously defined towers, each with an assigned MTM. MTMs are the primary resources driving the Portfolio workstream within their respective towers. They act as ambassadors and single-threaded contacts for the migration program, liaising with application owners, technology managers, and stakeholders. The majority of their efforts are devoted to performing migration assessments and conducting wave planning within their respective towers.

2.3.3 Migrate Workstream

Our model places the migrate workstream downstream from both the Governance and Portfolio workstreams. This migrate workstream is staffed with AWS Certified Cloud Infrastructure Architects (CIAs) overseeing migration pods, which include migration engineers. These resources handle the cut-overs of servers from on-premises to AWS, based on the wave plan schedule. Because the migration factory process is agnostic of where the servers reside, the migrate workstream resources cover all towers. This is depicted in Figure 3 as a solid horizontal rectangle crossing through all vertical towers.

Although the migration pods are responsible for performing the primary function of the workstream—migration—the MTM still plays a role. The MTM remains the single-threaded contact for application owners and stakeholders within their respective towers throughout the migrate workflow. This is illustrated in Figure 3 as the Tower extending vertically through the horizontal Migrate Workstream.

3. Migration Tower Managers within the Migration Phases

The MTM has a role in each of the AWS phases of our large-scale migration: Assess, Mobilize, and Migrate. Figure 4 is a ‘Responsible, Accountable, Consulted, Informed’ (RACI) matrix focused on the MTM persona throughout the migration phases. The RACI matrix defines the major MTM-related tasks sequentially within each migration phase. It also defines the RACI roles by workstream. Within the Portfolio workstream, the matrix further delineates tasks between MTMs and the other personas.

3.1 Migration Tower Manager in Assess

During the Assess phase of our large-scale migration the program sponsor and key stakeholders defined the Towers and assigned our MTMs. Once assigned, the MTMs will begin their new role by identifying the key stakeholders within their respective towers and upskilling on AWS Cloud.

• Identify key stakeholders: Key stakeholders will set the foundation for the future tasks in which the MTM will be engaged. These stakeholders include the technology managers, application owners, and other leaders. Identifying and forging these relationships will help accelerate momentum for the migration as well. This is typically achievable within the assess phase.
• Upskill on AWS Cloud compute and migration services: Although our MTMs are well versed in project management, they may not be fluent in AWS Cloud. MTMs should earn their AWS Certified Cloud Practitioner certifications, or ideally their AWS Certified Solutions Architect – Associate certifications as part of their ramp-up.

3.2 Migration Tower Manager in Mobilize

During the Mobilize phase, the MTMs share the migration program, drive the portfolio assessments and discovery. This includes leading the wave planning through prioritization exercises, and assigning applications to each migration wave.

• Create “pitch deck” migration content: A key component of the communication plan will be to create an initial outline of your migration program strategy, cloud adoption value, and capabilities. This artifact, often a slide deck, is necessary to help convey the proper messaging and capture the engagement of the key stakeholders in your organization. The content is generally authored by your Cloud Enablement Engine (CCE) resources within the Governance workstream. Our MTMs will curate and customize the content to their respective tower.
• Share migration program: As ambassadors for the migration program, MTMs will share the migration strategy with the Technology Managers and Application Owners of each portfolio.
• Lead Portfolio Assessment and Discovery: MTMs will coordinate with Technology Managers and Application Owners to assess each portfolio’s readiness for migration. This involves gathering the unique portfolio-specific requirements and technical constraints.
• Lead application prioritization and wave planning: MTMs will facilitate the prioritization of applications and plan migration waves based on technical dependencies. This will be aligned to the existing priorities within the tower’s federated IT department.
• Facilitate application “deep dives”: Complex portfolios and select applications may necessitate a solution outside of the existing migration factory. In these cases, the MTMs will facilitate “deep dives” with the Technology Managers and Application Owners. The “deep dive” session outputs include end-state technical architecture and inputs for an application-specific migration project plan. Technical resources from the Migrate workstream will help host the technical discussions to produce the end-state architectures. The MTM will help to capture the inputs for the application-specific migration project plan.
• Create application-specific migration project plans: For the portfolios and applications for which our MTM performed an application “deep dive,” they will produce a migration project plan. The purpose of the application specific project plan is to capture activities not already accounted for in the migration factory’s process or T-minus schedule.
• Manage Mobilize phase related dependencies and escalations: MTMs will manage all Mobilize-phase related dependencies and escalations for their respective towers through the process defined by the Governance workstream.

3.3 Migration Tower Manager in Migrate and Modernize

In the Migrate phase, MTMs manage migration project plans and dependencies and escalations related to the migration.

• Manage application-specific migration project plans: For the portfolios and applications that required a “deep dive,” the MTM performs task tracking, monitoring and control within the application specific project plans.
• Manage Migrate phase related dependencies and escalations: MTMs will manage all Migrate phase related dependencies and escalations for their respective towers. This is done through the process defined by the Governance workstream. This differs from technical escalations that may occur due to migration related issues encountered by the Migrate workstream, which spans all towers.

4. Conclusion

In this blog post we defined the: 1. MTM Persona, 2. MTM within the Migration Governance, and 3. MTM within the Migration Phases. We discovered how MTMs deployed effectively within our governance model have the power to translate your leadership executive directive into actionable, organized migration efforts.

In essence, MTMs embody the leadership directive throughout all phases of the program. They review the strategic goals set by executives, and operationalize the goals throughout the migration timeline. The MTMs’ ability to operate in complex, federated environments, address unique departmental requirements, and facilitate communication and coordination among various stakeholders solidifies their role as a lynchpin in a successful migration strategy. MTMs are drivers and implementers of the leadership directive, making the migration process systematic, efficient, and aligned with the business objectives of the organization.

About the Author