The manufacturing company is a US corporation that delivers a wide range of services and products across many industries, including healthcare, automotive, and manufacturing. With over 96,000 employees worldwide, it leverages more than 50 different technology platforms. The plan was to rehost approximately 80% of the overall environment, and while the customer knew its hybrid IT landscape was complex, it defined and adhered to well-defined processes designed to mitigate disruption.
“AWS recommended using TransitionManager for managing the migrations end-to-end. It provides a single pane of glass that serves as the system of record for data and drives the coordination and collaboration of planning, managing, and execution of migration waves,” said the senior professional services consultant at AWS and lead on the project. “Not only did it help us keep the project on track, it accelerated the migration project to AWS by six months.”
TransitionManager was installed behind the company’s firewall, and data was ingested from disparate systems such as CMDBs, ITSM and files. Leveraging TransitionManager’s rules engine, the team filtered out irrelevant
Upon data import, the team leveraged TransitionManager’s visual map of all applications, servers, storage and other devices across their hybrid landscape. Designed to be used by all project stakeholders, the customer limited TransitionManager access to specific users due to security policies. Data was exported from TransitionManager and displayed in an internal webpage so app owners could verify data and make updates as needed; these changes would then be quickly captured and entered back into TransitionManager.
“Our AWS team was highly efficient and productive using TransitionManager’s asset-level task management,” commented the AWS consultant. “During migration planning, hundreds of asset-level tasks needed to be created, managed, executed and closed out every week. The tasks can be large or small, and may include confirming an OS version, validating dependencies, marking assets as retired or out of scope, adding a start time for a move event, to name a few. Having the ability to track these tasks with the assets they apply to was invaluable and had a significant impact on productivity and efficiency.”
When viewing the map of their IT landscape, the customer expected complexity, but they were not aware of how interdependent their applications and other assets were when planning to rehost the vast majority of workloads. Like many organizations of its size, large database environments hosted dozens or even hundreds of applications, making a single move group impossible.
At this point, re-platforming was not an option. Creative wave planning was needed to move databases without all dependent applications without disrupting business operations.
Recreating 1,000 servers and 600 apps into smaller groups using spreadsheets would have been extremely difficult. But using ad-hoc queries and filters, the team could easily search for QA, development and other non-production systems, and identify applications that were not business critical. The results were saved as reports that could also be exported to spreadsheets or printed for reference. Each report could also be viewed in a map, making it easy to quickly identify conflicts or new dependencies.
Once large dependency groups were reduced to a manageable level, all applications in a specific move group had to be in a final state of readiness to move. This basically meant that any asset with a dependency had to be moved within the same group to be approved. This was clearly a challenge as the groups of apps were broken down from hundreds to a couple of dozen. But with the dependency analyzer view, it was easy for the team to make decisions and demonstrate how all apps with multiple dependencies would be moved, and when and how each dependency would be accounted for – without having the final readiness status. Being able to see how each asset and dependency was accounted for, the date and time it would be moved, and the duration of the move, gave the team the confidence that the wave planning team had accounted for all dependencies. And because each asset record was tracked with business facts in addition to technical facts, the team could demonstrate that the migration would meet all SLAs, RTOs, and compliance or security requirements for each asset.
On top of the obvious use of Transition Manager to store the customer’s portfolio data and manage a comprehensive two-year wave plan consisting of over 50 migration waves, the manufacturer needed a solution to managing the weekly changes.
“In over 10 years of managing wave plans, I have never seen a customer with so many weekly changes. Unfortunately, we aren’t just talking about simple changes where an application is assigned a new owner, or a server receives a different IP address; we are talking about massive amounts of relationship and dependency changes. Some weeks, we see over 300 new dependencies and an equal number of removed dependencies. We might also see dozens of net-new applications and servers,” said the AWS consultant.
The underlying issue in all of this is the application teams who are driving these changes in the environment are not aware of the downstream effects to the wave plan. Since the wave plan has been 95% created and confirmed, each of the changes described above could have wild downstream impacts. For example, a new dependency to a production database server that is being rehosted could create new relationships with other dependency groups and waves. If the newly connected dependency groups cannot be placed into the same wave, then the database team needs to reevaluate the new connection and consider a replatform instead of a rehost for that application. This is just one scenario or “rule” as we call them on this project. There are many rules like this due to the resulting new dependencies we see each week. Other rules around new web server and application server connections have their own set of complications.
To make matters even more complicated, it’s perfectly normal for these changes to affect “in flight” waves. An “in-flight” wave is to be migrated in the next 1-2 months. These waves have started their detailed planning phase which includes application workshops and other migration “gates” as we approach their cutover dates. Anything that impacts an in-flight wave must be reviewed by wave leaders and other stake holders before being committed.
The customer and AWS desperately needed a way to identify these each week. The solution was a series of custom rules created within TransitionManager’s rules engine that would be run each Monday and uses logic to identify the date and type of change BEFORE we commit them. Once exported, the user could query on a custom field called “Last Seen Date” to see if the change is present in this week’s data or not. If the change is not present in this week’s data, then it’s changed. Additionally, the same report could also filter on “New Dep” in the status column to easily identify anything new in the portfolio. These changes are then tagged with their corresponding assets and waves and presented in a weekly report on Monday afternoons. The changes to in-flight waves are highlighted and addressed with the wave leaders and stakeholders to determine which ones can be committed and which ones must be rejected.
The customer is now able to see any new changes before its committed to any wave. This is extremely crucial for in-flight waves. Consider a scenario where the SQL team installs a new database for an application slotted in wave 20. Also consider the SQL team has no idea that the application is already slotted in wave 20. Then consider wave 20 is one week from cutover. Wave 20 cutover happens, but the new database was never included into the cutover plan. Now the application is broken and we do not know why. This scenario is just one example that can happen at any given time due to the number of changes each week. Since incorporating the rules in TransitionManager, this is no longer a problem. We are easily identifying new databases and making informed decisions whether to scramble and get them included into the in-flight wave or making decisions to reject the new database and plan it for a future wave. Either way, now we know.
The customer and AWS plan to continue looking for ways to tighten our change control process to look for other ways to get in front of the highly dynamic environment. The work is paying off, and application cutover are continuing to go “unbroken.”
The team identified the top three elements critical to the success of the project.