3 min read
Once the experimenting is done, the envisioning is done and everyone in the team is bought into your cloud migration plan, it’s finally time to get moving. But, where do you start? For anyone preparing to migrate to the cloud, it’s a perfectly natural question.
The only way to answer it starts with creating a catalog all of the applications managed by IT, categorizing them one-by-one, based on their various attributes (document classification type, server count, etc.) and then bucketing these into sets of overall attributes that fall under top-level criteria. Typical criteria include performance, architecture, financial attributes, risk, operations, and security/compliance.
When creating your catalog, it’s useful to approach applications from two different vantage points: the top-down approach is focused on where applications should go to best serve the business, whereas the bottom-up approach is concerned more with the technical feasibility of where an application could go and still function.
The Top-Down Assessment
If you read the first post in this series then you’ll understand that one of the chief goals of moving to the cloud is to transform every facet of your business, and to be able to harness the full potential of the cloud and cloud-based services like machine learning, data analytics, etc. The top-down approach is focused on reaching that goal and begins with an evaluation of the various technical and security aspects of each application:
- Categorization of data, compliance, sovereignty and security risk requirements
- Current complexity of interface, authentication, data structure, latency requirements, coupling and application life expectancy of the application architecture
- Operational requirements like SLAs, integration, maintenance windows, monitoring and insight
Once analyzed, all of these aspects generate an overall score that reflects the difficulty of moving that application to the cloud. The top-down assessment also involves evaluating the application’s financial benefits:
- Operational efficiencies, TCO, return on investment (or similar measurements)
- Overall computer load, seasonal fluctuations in usage levels, types of users (casual vs. expert, always online vs. only occasionally), necessary levels of scalability or elasticity
- Business continuity and resiliency requirements, any dependencies in the event of a service disruption
Together, the outcomes from each of these two appraisals generate an overall score that reflects the difficulty of migrating the application against the financial payoff of migrating it. With the top-down method you can more easily identify which applications have the highest degree of value and success from migration, and prioritize these applications as you begin to map out the migration process.
The Bottom-Up Assessment
Simultaneous to the top-down assessment, a bottom-up assessment can also be performed. And because this is more about the technical requirements and where an application could go, much of the information can be pulled from the Configuration Management Data Base. Requirements typically addressed with a bottom-up approach include:
- Max. memory, number of processors, operating system disk space, data disks
- Network interface cards
- Network load balancing
- OS/ DB version
- Domains supporting
- Third-party components/ software packages
The Microsoft System Center Suite and Microsoft Assessment and Planning Toolkit both offer automated solutions for assessing your IT environment.
Having completed these assessments, the business liaison and operations team can then work with the respective business units to establish a list of top priorities. In general, it is best to start with less-complex projects and gradually increase the complexity as the migration progresses and your confidence level increases.
For more guidance on developing a migration plan, details about Microsoft’s own migration and how to get the most out of the cloud, check out the Enterprise Cloud Strategy ebook. You’ll benefit from the collective knowledge of me, co-author Barry Briggs, and many of our colleagues who contributed based on their own experience and conversations with several companies moving to the cloud.