Technology today allows for many different paths to cloud-based infrastructure and IT. Regardless of whether your CIO has decided to focus on applications and data, implying a Platform-as-a-Service (PaaS) solution, or perhaps keeping the middleware layer too, and transitioning only servers and virtualization to a third-party vendor, meaning Infrastructure-as-a-Service (IaaS), any underlying infrastructure transformation will result in some sort of an application migration.

Through our experience, we have found the greatest path to a successful migration is to not over-engineer a solution,  but to build a foundation leveraging the internal expertise an organization already has within its doors. By utilizing every available resource such as server data, software listings, dependency mapping, and even standard app catalog information, performing methodical pre-work, and gaining the trust of the resources joining you on the application migration journey, you will be well on your way to properly plan for an application migration fit to serve the needs of the organization. As you embark, regardless of whether the enterprise has 50 or 5,000 applications in its portfolio, the most critical question/data which be must be answered/obtained through your analysis is whether:

a)      Application A will need to be migrated, or

b)     Application A will stay the same (a.k.a. not be migrated)

Answering that simple question is not as straight-forward as one might think; firms can take any number of approaches from introducing a new tool to do the data gathering, heavily attended, large team workshops, or even application specific deep-dive sessions. Firms may even do a combination of all three or include additional processes and procedures believed to hold value. Any way you look at it though, the common denominator remains the personnel and expertise which already exists within the enterprise.

How you go about getting it can be the difference in how difficult your outcome will be to achieve. Until you can prove your intentions are to see the firm succeed and that the goals of a specific group align with the goals of the overall migration business case, you will struggle to achieve the engagement your analysis will undoubtedly require. A simple process workflow could look like the below:

While all must be performed (with a focused reminder on bringing the right audience to the table), two items are specifically worth breaking down in greater detail.

Perform Pre-Work and Send Materials Ahead of Time

Key Lesson: Do not come to the table with a blank slate and expect to receive the world.

• Do your due diligence. Attempt to run some analysis of the applications well in advance of any scheduled workshop and see what roadblocks you encounter. The goal is to come into the workshop and only ask the pointed questions which need additional consideration/verification from the pointed resources you have brought to the session.
• Do not overlook the data you may already have on hand. Utilize what is available and try and define some additional breakouts which provide even more insight into your program. Some examples could include:
  • App Value to the Business: critical to understanding how the business views and prioritizes its applications
  • Technical Complexity: allows time to plan for larger remediation needs
  • App Risk to the Enterprise: ensures clarity on high risk applications and additional prioritizations from the business
• Send materials well in advance of the session. While most will not have time to preview, the few that do will appreciate seeing your developed communication materials, an understanding of how goals align, and what exactly will be expected of them during the session. Bonus points if you can even send questions for them to think through.

Facilitate Workshop and Analyze the Apps

Key Lesson: Use this time to build a lasting relationship for an entire migration

• There should be two main objectives in these workshops; aligning on the goals of the workshop/program and working through your data validation and needs.
• Within goal alignment conversations, this is a valuable chance to learn about app owner pain points within the organization and how some of their objectives and underlying needs could be translated into action for you and your team. State your plan and let them react.
• But do not forget about the data:
  • Validate the pre-analyzed technical components. Are there additional data points to consider? How accurate are they? What is the easiest method to gather new information in larger group settings?
  • Business Drivers/Dispositioning:
    • And now, finally, we can utilize SME expertise to determine whether an app will, or will not migrate
    • At this stage, we do not need to have the exact specifics behind each application, but understanding essential components such as the application’s planned future, and whether it is already funded to do that work, will help arrive at the core of what your enterprise migration might look like. Questions like the above can usually be broken down to 3 to 4 different archetypes:
      • Will Application A be retired soon? Or its functionality replaced by something else?
      • Will Application A stay in the environment and need to go to a new platform (a.k.a. be migrated)?
      • Does Application A have technology that is too complex and so should remain the same pending further investigation?
    • Gather any additional data which is offered
      • Are there known upcoming releases, consistent freeze periods, large app consolidation efforts, or odd technology under the covers?
      • All this helps to paint as accurate a picture as possible