Congratulations on completing the migrating from an end of life data center to AWS
In this learning path we used a practical scenario to help us learn how to approach and solve business problems using cloud tools and services.

In our scenario Our customer has asked for help solving an end of life data center issue and help transforming their online legal business expertiseplease.com.

We migrate a business application from an end of life data center to Amazon Web Services.

The team used tools like the AWS Cloud Adoption Framework and AWS design patterns to define a future state, target architecture and project timeline for expertiseplease.com.

The team then discussed the details of the solution design, the transformation stages and how we tackle a variety of implementation considerations such as database migration key management and image ingestion / storage.

We defined a future state based on the requirements and constraints provided by the customer.

We then defined a reference architecture for that future state

We broke our tasks in to swim lanes and did some rough time boxing to work out a high level outline for our project

We identified the must do task as solving the storage exhaustion issue as it had a hard time constraint, so we prioritized that in the project time line with a shift to Amazon S3 using Snowball appliances.

We designed our VPC and how we would add connectivity between the VPC and the Data center. We opted for a VPN connection first as while Direct Connect was our preferred connectivity solution - as it provides reliable connectivity without using the Internet, it will take 10-15 days to provision a direct connect connection via an AWS partner. So VPN first, DC going forward.

We used as many managed services as possible in our reference architecture. Managed services mean HA and provisioning is taken care of for us, and allows us to implement services quickly.

Stage one - lift and shift. We want to move as much as the environment as possible without changing core systems. The first step is to deal with the storage exhaustion issue, we identifed a number of options to deal with this, including archiving of old objects, creating a hybrid architecture for storing new objects on AWS.

In our design brainstorm we discussed whether to move applications or servers. If the environment was running on VMware we could have made use of the AWS Server Migration Service to migrate servers. There are also multiple third-party solutions exist to support the migration of existing servers to AWS.
However we have a bespoke app, so we opt to containerize the existing application and run it on AWS ECS, this simplifies the migration and enables the customer to work with other AWS partners on configuration and management.

Stage two is all about optimization so in this stage we want to continue to implement as many AWS managed services as possible.

Stage three
The third and last step of our transformation approach needs to happen before the 18-month deadline. ExpertisePlease struggled to deliver new features because of the monolithic application. So stage 3 consists of re- architecting the application to become even more micro-service orientated, so that each module can be maintained and can evolve separately.

Where possible we try to leverage serverless services such as Amazon API Gateway to allow us to build both web and mobile applications using the same common services; again, using AWS Lambda and Amazon Dynamo DB, however for those modules which require more significant change we can use managed application services such as Elastic Beanstalk to provide Java based application environments.

With a future state, reference architecture and project time boxes defined we then ran a structured walk through to look for any dependencies, issues or hidden constraints. This is the point to capture as many hypothetical situations as possible to stress test and optimize our proposed design. This aspect is important for the overall success of your project. . A huge benefit of AWS is how quickly we can get straight in to building things. As a practitioner try and temper your enthusiam to start building until you know you have thought through all possible outcomes of your design.

Some parts of the solution will be best done as prototypes, as cloud practitioners we are builders and that is how we achieve such great customer outcomes. But try to keep one eye on the detail and the other on the project as a whole - most importantly - on the people who will use or may be impacted by this new solution. A good user experience is key to your success.

Can’t stress this point enough. No migration project should be an island and no re-engineering solution should be done in a vacuum. As an architect or tech lead it is your job to encourage as much feedback as possible before you start doing the work. If stakeholders feel they are included and have been heard the more likely they are to want to help you, and the less likely they are to resist change when change is required. Ideally use a structured walk through or design review to create and populate risk register for the project. That is core to any root cause analysis you may need to do during or after the project. The more stress testing we can do before actually building anything the more successful we are likely to be at achieving results within the time frame.

Use formats like a structured walk through to get as many stakeholders together and to walk through the design in as much detail as you can. Make it clear you will be taking notes of any comments made and assigning owners to any items that are identified as Invite people from other business units so they feel included in the project and have an opportunity to raise any questions before you start. The more poeple you involve at this stage, the more likely you are to get help and acceptance later in the project.

We have done a number of hands on labs to build our understanding and familiarity with some of the services included in our design. As a next step I suggest completing further labs or courses from the library, and as an exercise, think about a business you’ve used or worked with in the past. Now think how you might approach a cloud migration of that business application. What frameworks and steps might you look to use to help you define the project better? What tools and services would you look to use?

Please let us know your feedback on this learning path. We really enjoyed putting it together for you. If there's other ways we could do it better, let us know, please and good luck in your endeavors. Well done, Cloud Academy ninjas.