There are 5 basic phases in moving assets to AWS.
These steps are summarized below.
70 % of complex IT projects fail. 60% of Dev Ops fail or add no value. The reason mostly has to do with planning, which includes understanding your estate, your applications, your data, your motivations, the aims of various stakeholders and budget. The first and key diagram to be made in a migration process is the Business Architecture Overview, which is an architectural solution to the Business problem. To develop this, we need to do the following:
Understand the Business Requirements and Problem: What problem are we trying to solve with the migration? What are the pain points including: current costs, architecture, performance issues, internal resources, time-frames and competitive issues?
What is the vision of the migration and success? What will success look like? What do the stakeholders want and do they buy in?
Stakeholder buy-in: IT, Management, C Suite, the Owners, the end-user – all must buy in to the migration and change plan. If not there will be problems.
ROI and Business Plan: Can we afford it? What are the costs in moving to AWS? What are our current license fees, data centre fees, cost of infrastructure ownership? Who will be our main partner? What skills need to be upgraded and replaced internally? Do we have PM and Change Management skills? Which partner can help us with the migration and at what cost?
Once we have documented the above into a Business Requirements document and a first draft Technical Architecture model, we can proceed.
Since data is King, most firms are interested in moving over applications, be they COTS, Legacy, newly build but on-premise or hybrid. The figure below summarizes the main approaches to analysing applications.
Image source: Stephen Orban, AWS Director of Enterprise Architecture
This phase is where we inspect configuration management databases (CMDBs), and tools such as AWS Discovery Service or RISC Networks (or other network products from firms like SolarWinds), to understand what’s in their environment. Using this knowledge, organizations can outline a plan on how they will approach 2 key and oftentimes independent phases: application migration and data migration (I might want to move the data first into AWS and the application after, or vice versa). There are a few key points here:
2 .1) An added complexity in moving applications is licensing. We need to understand licensing implications of moving into AWS and potential savings from for example, moving an Oracle estate into AWS (you can even move an Oracle ERP into AWS and save considerable license fees).
2 .2) If I have very complex legacy systems (eg Mainframe) I might need to ‘wrap’ those systems in order to interface them with a SOA/Cloud Native application and architecture. This will introduce a hybrid architecture. In other words, I will move the app fed from the mainframe into AWS. Or, I might choose to lift and shift an older COTS but fork-lifting has issues, and will not resolve fundamental problems with the application and will most likely, introduce latency.
2. 3) Understand application interdependency. If many apps are co-dependent I need to evaluate what to move first and why.
Where to start? Usually simple is good. Low complexity is preferred as a starting point. An app that is ‘Friendly’ or ‘Cloud Native’ as given in the figure above, is a good starting point. This will help build experience, generate a positive outcome and provide a test case.
Migration strategy now switches from a portfolio-holistic view, to an individual application view. Each separate application is designed, migrated, and validated according to one of the 6 application migration strategies described here.
You should start with the least complex application, learn how to migrate while learning more about the target platform, and build toward the more complex application migrations as your organization becomes more cloud and migration fluent.
To help with this, we can also now introduce ‘Agile’ DevOps, or teams focused on a particular type of “migration theme.” For example, you might have themes within the application portfolio. Productivity applications need to be migrated (Sharepoint, backoffice apps, Excel apps). Line of Business apps serving certain parts of the business, built with roughly the same code base, would be another. Maybe you have legacy CRM apps or SFA sub-systems you need to move. In any event, you can create pods of excellence and some recommend a Cloud Center of Excellence that can advise and guide teams on their migrations.
Within these 2 phases you must have a strategy for testing and decommissioning the old systems. You will need to run parallel environments for a period of time while you migrate traffic, users, content and test availability and reliability in real time – and solve issues as they crop up.
Automate, optimise as much as possible within AWS. Find skills, tools and specialists to aid in this. Security, configuration, alerts, alarms, auto-scaling, load balancing, AMIs, should all be automated, templated and standardized. DevOps is also a good path for many firms to follow in helping achieve this.
Lastly, return to your ROI and Business Plan. Did we make budget, the ROI expectation, and did we satisfy business and stakeholder requirements? Are end-users content? Do we have change management models in place to facilitate corporate and IT cultural change to a Devops/Agile structure? Are we now using the AWS foundation architecture as a means to transform our business?
Transformation of the business model is the whole point of migrating to AWS.
=====
Source: Heavily amended from Stephen Orban, Enterprise Director AWS, https://medium.com/aws-enterprise-collection/a-process-for-mass-migrations-to-the-cloud-ee7ff5d7b3d1
