Migrating to AWS. Summary of the approach, practicalities.

 

Introduction

Migrating to AWS can be complex depending on the number, size and dependencies not just of the applications, but related middleware and infrastructure. To do a proper migration you will need to sort out the infrastructure (AD, LDAP, SSO, File Servers, NFS, DFS) first; move these over first to AWS, then second, migrate the applications and databases (data, machine images).  Obviously, you will need to understand the dependencies to do this (an example would be Citrix on premise to Citrix, not AWS, Cloud, middleware, SAN, NAS application dependencies, certificate management etc). 

 

In short, this is best accomplished using native AWS services (Discovery, DMS, SMS), an Agile-Factory approach of cross-company co-operation including integrated testing; operations, the Business Owner, SMEs; based on a complete understanding of dependencies, application and database size and complexity.  We will build tranches of similar applications, which the cross-functional team will move over, using standard tools and processes to AWS, and fulfill key requirements.  We would also propose setting up a Cloud Center of Excellence (CCOE) governance process (if one does not exist, or if it does, to help with any improvements); to ensure standards and compliance.  Cloud projects need a dedicated Cloud Governance model.

 

Key Requirements

For example, a typical migration has common key requirements. 

1-Migrate from a DC or Co-Lo in a short period of time to both IaaS and PaaS depending on the DB platform

2-Use AWS Discovery agents, move all related and relevant assets to AWS including Code, Applications, data (application, database), Networking, Security, LDAP, SSO, file servers, NAS, Storage devices,

3-Accomplish the migration using a ‘Factory Approach’ (platform dedicated cross functional Agile-Team) using AWS native tools

4-Ensure there is no business or end-user disruption and migrate according to Principles, a Cloud Environment Strategy

5-Network, setup the receiving environments, security configurations, do a DNS cutover to the new environment and decommission the existing DC or Co-Lo

 

Current Estate and Future Estate

1. Use AWS tools to perform a discovery of the types of applications and related server configurations using the AWS Discovery agent or agentless tool (depending on type of VM).  We will need the results of this discovery and any information related to application types.  This would include VMWare, Oracle, SAP, DB2, MySQL, SQL, COTS, or home-built applications.  
2. Building the Target Platform in AWS.  We assume that the target VPC will be built by our Client, or co-jointly with our Engineers.  We can build the underlying infrastructure using Cloud Formation Templates or similar tools.

 

Process & Approach:

We use the standard AWS CAF approach to migration with a view to ‘accelerating’ the process.  We work with our clients on joint teams to do this.  Given that most Clients are familiar with this approach, we will not explain every phase in detail.  We have a detailed High-Level Design for migrating to AWS which contains the entire stack (networking to application layer, including security).  We can share this document with our Client (it is a 30-page template we fill in on our projects). 

 

(Figure:  Governance will be best enforced by a CCOE)

 

Process:

1-Set up the CCOE or at least a Project-Governance Team for AWS comprised of CTO, EA’s, TA’s

2-Create a plan for moving the applications and related assets to AWS including tooling, testing, security and the exact process for each platform (e.g. Oracle), timeframes, RAID, RACI, Operational management and Runbooks

3-In parallel create the inter-firm Agile teams which will perform the work who will build out their documentation based on the Master Document (use Jira, Confluence, Agile methods, Scrum etc)

4-Use best practices such as native AWS tools, or existing Client tools as much as possible

 

The 5 Factory phases for Cloud Migration would include: -

1. Discover: AWS Discovery (assume this is done).  Sizing, capacity, storage, usage patterns, code assessment if necessary.  This drives the creation of the target platform in AWS.
2. Assess: We need to assess the code of the applications and will use AWS SMS, VM Import/Export or similar.  An example might be embedded SQL Logic within Oracle that precludes re-hosting in AWS and means a code refactor.  IaaS vs PaaS applicability. 
3. Migrate: Based on patterns (we have pattern books), standard tools (by platform), updating the OS (if necessary), perhaps migrating the code base and using AWS Services such as DMS, VM Import/Export or similar.  This includes data replication (can use Oracle Tools for eg if needed, or AWS services), backup, storage (S3 for example), moving NFS to EFS and related artifacts in the DC. CFT, Terraform can be used in IaC.  Security Models and Monitoring need to be set up using AWS Security services, AWS Config, Trail etc.   We have detailed approaches to allow us to control compliance, costs and security.  Backup, DR running.
4. Transform:  After migration to automate, optimize, improve the CI-CD and DevOps.  It may include re-architecting and rewriting code, but that analysis can be done after the migration.  
5. Operate and Manage: Service management, maintaining run cost optimizations, compliance with agreed SLA’s and adherence to defined policies for governance are a few of the major activities being performed for delivering cloud hosted solutions.  Flexible Operations (we can do it with our Client, become your MSP, or create a custom approach) are possible.

 

 

Future (‘Transformed’) Architecture: Automation and the leveraging of infrastructure as code, configuration management techniques to deal with day 2 operational challenges such as server sprawl, configuration drift, fragile infrastructure, software entropy etc. The ‘R’ Strategy depends entirely on what the application is, purpose, end-users, how long lived, and whether it is monetised.