DC Migration Proposal

AWS / ACME
Problem statement - Our Understanding
 On Premises Data Center hosting various internal applications - a total of
145 servers:
 67 servers running VMware ESXi hypervisor hosting 214 VMs
 Other 78 servers - mostly Solaris and MS Windows Server instances.
 All the 145 servers are in use, 6 out of the 214 VMs are to be decommissioned
 Current DC lease expiring in 12 months and the intent is not to renew the
contract
 Very little AWS experience within ACME IT workforce and any migration
related risks to business critical applications need to be managed
effectively.

Progress made so far

 Initial feasibility study conducted with AWS concluding that majority of the
assets can be migrated onto AWS cloud.
 ACME has reserved 10G of network connectivity to AWS via AWS Direct
Connect
Migration Approach – Overview of workstreams
Assess
Understand the on-prem data center footprint – servers, OS, storage, network, security
Program management, Engineering and Architecture Leadership
Executive decisions, Strategy, Governance, Communications

Migration readiness assessment – feasibilty of AWS cloud as the target platform

High level estimates and approval – TCO post migration
Workshop with Stakeholders – Gather inputs from senior IT and business executives, have
Skills enhancement and Knowledge management cross-functional discussions with internal IT teams, Finance, Program management.

Mobilize
Application discovery/analysis – ADS and Athena to get EC2 recommendations and dependencies
Security and Compliance – Understand and factor in any specific security and compliance needs
Landing Zone – AWS account and org structure (how many AWS accounts to create), centralized
concepts such as Security, IAM, Network, Audit administration
Mobilize people, partners, processes – critical mass of AWS skilled people
Operations – Target cloud operating model and operations integration approach to transition to it
Migration Planning – create migration waves/phases based on information gathered in assess and
mobilize phases (criticality, release cadence, dependencies, complexity and risk )
Initial Migration/PoC – proving the migration process, architecture and tooling .

Migrate and Modernize

Workload Migration – In tranches as planned during mobilize phase. Controlled/Tracked execution
with AWS Migration Hub, AWS MGN (application migration service), HCX for VMware cloud on AWS
Operations – Monitoring and support for the migrated workloads. Optimize scaling parameters,
machine types and disk sizes as the applications continue to run in the cloud.
Modernize – Cloud native services for legacy workflow and email, Micro-services and containerized
workloads, Big Data and Analytics
Migration Methodology
AWS MGN (Application Migration Service)
•Applicable to both standalone physical servers and
VMs.
•High speed connectivity with the on-prem datacenter
using AWS direct connect for effective migration
•Requires installation of MGN agent on the on-prem
servers
•IAM settings for the replication agent with required
access
•Configuring replication settings in AWS MGN
•Configuring the EC2 launch template based on the
target instance recommendations from ADS
•Launch test instances followed by QA/testing
•Launch cutover instances
•Shutdown corresponding on prem servers
•Update routing and DNS entries as appropriate
** Pics sourced from AWS and VMWare websites

VMware cloud on AWS

•Can be a relatively risk averse option for VMware workloads
•Existing VMware account can be used to pay for the SDDC
on AWS
•Will help ease the steep and rapid learning curve required in
terms of up-skilling staff as existing server, network and
storage management tools can continue to be used.
•HCX can be used for Hot, Warm and Cold migrations as
appropriate.
•Connectivity to the remaining servers migrated using MGN
onto AWS using ENI, VMware Transit connect or AWS
Transit Gateway
 Tranches/Waves Backlog prioritization/ sequencing
Servers (non VMware) – less critical 10x5 SLA, •Installation of MGN Agents, HCX configuration(if
opting for Vmware cloud on AWS)
Sorted by CPU, Filesize, RAM
•POC – Internal email service or File Sharing Service

Vmware VMs – Sorted by CPU, Filesize, RAM.

1 •POC (VM)- BDGBNBENCWEB01 web server or IRBS

All VMs are tier 0 or 1 (24x7) •Migration low risk workloads – less complexity and
dependency,less CPU and storage

•Probable list of servers and VMs in attached screenshots

2 •Migrate domain controllers and evaluate replacement

with AWS Directory Service

•Migrate non production workloads

•Next set of applications – medium complexity and

dependency

•Migrate internal and staff facing applications

3 •Migrate 3rd party applications that have a ready

replacement in AWS Marketplace like Checkpoint
security manager and firewall (GAIA servers) and SAP

•Migrate load balancers onto Amazon ALB or NLB

•Most complex and critical applications, Any servers not

supported by MGN, Internet facing applications,

** Pic sourced from internet – Google cloud blog 4 •Migrate application and DB servers handling sensitive
data subject to regulations

•Migrate Jump Servers – evaluate replacement with

Systems Manager

•Replace internal DNS server with Route 53 private

Migration tranches to be decided based on ADS findings (no of EC2 instances, dependencies), release cadence, interdependent
workflow analysis, down-time allowed. Tranches will be iterative in nature and the foundational activities of the subsequent
tranche to be started while the current wave is being tested.
Target State (representative)
•Multiple AWS accounts setup in line
with the customized Landing zone
•Multiple application VPCs
•External Load balancers, Checkpoint
security firewalls etc in external facing
Presentation VPC.
•Provision of a sidecar VPC for
outbound internet connectivity.
•3-tier layering between web server
layer, application server layer and DB
in each application VPC
•Cross VPC connectivity using VPC
Endpoints.
•Connectivity to AWS services like S3,
Systems Manager, Lambda functions
etc using VPC endpoints.
•Connectivity to ACME network using
AWS Direct Connect for other on-prem
datacenters and staff access.

Disaster recovery considerations

Multi AZ deployment for maximum resilience Existing Disaster Recovery Site is assumed to be on-prem

Multi Region deployment can be considered for DR Need further clarity on DR objectives and current setup

A mix of multi site active/active or active/passive DR strategy can be setup based on Application Tiers (RTO/RPO objectives)
Migration Team Structure
CIO Office
Migration Steering Committee
Business Representatives

Cloud Migration Lead

Platform Engineers Engineering Leads

Migration execution
Cloud COE
Experts/Trainers workgroup QA Leads

Cloud Competency Operations Leads

Program Office Architecture Migration Team Operations Team

Project Managers Solutions Architects Engineering team Cloud Ops - Monitoring

Scrum Masters Network Architects Testing team Support

Program Managers Security Architects Dev-ops team Automation

People – Skills and Culture

 Cloud migrations involves significant changes to ways of working

 A successful migration requires people to be supportive of the cloud first

strategy
 The strategy needs to be well communicated along with the key drivers and
benefits.
 Cloud center of excellence needs to be setup dedicated to mobilize the
appropriate resources and leading the journey to the cloud
 Cloud learning goals to be outlined, learning resources and trainings made
available.
 Sand Box environments for learning and POCs

 Set up ring fenced migration teams of skilled people

 Cloud Governance – Processes for approvals to be stream-lined, well

communicated and understood by all teams
Migration – Risks and Assumptions
Risks
 Productivity risk - Resistance from current engineering and operations staff

 Shortage of AWS platform and network engineering and administration skills

 Regulatory and Compliance aspects related to sensitive and PII data

 Latency during transition states – while some of the apps are on-prem.

 Challenges around data locality and isolation

 Legacy infrastructure unsupported by migration tooling

Assumptions
 DR mechanism exists in line with application tiers and more details will be shared

 Any major changes/releases planned for the impacted applications will be readily
communicated
 The servers marked to be decommissioned will be sunset on-prem and need not
be migrated onto AWS cloud.
 Decisions around SAP upgrade will be taken shortly and the concerned servers to
be included in (accounted for) the migration.
T H A N K Y O U !