Choose a migration strategy for each application in an invented portfolio

short · 30 min · Task statement 1.3

Before you start — what this lab needs, and what it can cost

This lab runs in your own AWS account, so every command acts on something real and billed to you. Work in AWS CloudShell, opened from the console toolbar, signed in as a non-root administrative identity: an IAM Identity Center user, or an IAM user with administrator permissions. Never use the root user, and create no access keys, because CloudShell already has the AWS CLI and your credentials. The lab uses the AWS Free Tier where possible, but charges are possible, so do the clean-up the same day; each service's pricing page and the AWS Pricing Calculator give current rates. It relies on the budget alert you set in lesson 1's lab, clf-zero-spend-budget, which emails you as soon as this account starts to cost money. The commands use 111122223333 as the account ID: put your own 12-digit account ID in its place wherever it appears. Every AWS call in this lab only reads: it creates no DMS replication instance, no database and no migration project. The company and its applications are invented.

This lab ends with a clean-up. Do it the same day: anything left running in your account is billed to you.

Task

Take an invented company's portfolio of seven applications and choose one of the seven migration strategies for each: retire, retain, rehost, relocate, repurchase, replatform or refactor. Then use read-only AWS CLI calls to check two facts your plan depends on: that AWS Database Migration Service (AWS DMS) can replicate ongoing changes from a MySQL source, which is what keeps database downtime to minutes, and that Amazon RDS offers the MySQL engine a replatformed database would move to. Finally, place four situations in the AWS Cloud Adoption Framework (AWS CAF) by perspective and business outcome. You finish with a short written plan you can check against the answers.

Steps

In CloudShell, write the invented portfolio to a file:

cat > clf-lab03-portfolio.csv << 'EOF'
app,what portfolio discovery found
staff-canteen-menu,intranet page nobody has opened for over a year
lab-instrument-control,tied to specialised hardware on site and upgraded last month
order-web,forty Linux servers that must leave before the data-centre lease ends in three months
vsphere-estate,two hundred VMs on VMware vSphere that the team wants to keep on the same platform
sales-crm,self-managed CRM the sales team wants replaced with a SaaS product
orders-db,self-managed MySQL the team wants AWS to patch and back up with no code change
catalogue,a monolith whose parts must scale and change independently
EOF
cat clf-lab03-portfolio.csv

Decide a strategy for each application and write your decisions down. Open a file in the CloudShell editor with nano clf-lab03-decisions.txt, write one line per application in the form app: strategy, reason, then save with Ctrl+O and leave with Ctrl+X. Look for the amount of change each one needs, as lesson 3 teaches: none, a little, the product, or the architecture.
Check the database replication your orders-db move depends on. Ask AWS DMS whether it supports change data capture (ongoing replication) from a MySQL source:

aws dms describe-endpoint-types --filters Name=engine-name,Values=mysql Name=endpoint-type,Values=source --query 'SupportedEndpointTypes[0].SupportsCDC' --output text

True means DMS can load the existing data and then keep copying changes while the source keeps serving users, so the final cut-over takes minutes. 4. Check the target of the replatform. Ask Amazon RDS for its default MySQL engine version:

aws rds describe-db-engine-versions --engine mysql --default-only --query 'DBEngineVersions[0].[Engine,EngineVersion]' --output text

The same engine on both sides is why the schema needs no conversion. Now consider a second, invented database, billing-db, on Oracle, moving to Amazon Aurora PostgreSQL. Confirm DMS supports that target, and add a line to your decisions file saying which tool converts its schema first:

aws dms describe-endpoint-types --filters Name=engine-name,Values=aurora-postgresql Name=endpoint-type,Values=target --query 'length(SupportedEndpointTypes)' --output text

Place four situations in the AWS CAF, adding each to your decisions file as situation: perspective, outcome: (a) staff have no cloud skills and managers expect resistance; (b) the programme needs risk management and cloud financial management; (c) the team must build the landing platform and a CI/CD pipeline; (d) after the move, day-to-day patch and incident management must keep working. Then name the outcome for (e) fewer outages and security incidents, and the transformation phase for (f) the first pilot projects going into production.
Browse AWS Prescriptive Guidance (search the web for "AWS Prescriptive Guidance patterns") and open one pattern about migrating a MySQL database to Amazon RDS. Note that it is a self-service library you read, not a service you start, and that it costs nothing to read. Compare your file with the Notes and correct any line you got wrong.

Verify

aws dms describe-endpoint-types --filters Name=engine-name,Values=mysql Name=endpoint-type,Values=source --query 'SupportedEndpointTypes[0].SupportsCDC' --output text

Expected output: True.

aws dms describe-endpoint-types --filters Name=engine-name,Values=aurora-postgresql Name=endpoint-type,Values=target --query 'length(SupportedEndpointTypes)' --output text

Expected output: 1.

aws rds describe-db-engine-versions --engine mysql --default-only --query 'length(DBEngineVersions)' --output text

Expected output: 1, one default MySQL version for a replatformed database to land on.

Cost and clean-up

Nothing in this lab is billed by the hour: the DMS and RDS calls only read catalogue information. A DMS replication instance or an RDS database would be charged, which is why the lab creates neither.

Created by this lab: the file clf-lab03-portfolio.csv in your CloudShell home directory; the file clf-lab03-decisions.txt in your CloudShell home directory.

Keep a copy of your decisions if you want one (download it with Actions, Download file in CloudShell), then remove both files:

rm clf-lab03-portfolio.csv clf-lab03-decisions.txt

Check it is gone

The files are gone, and the lab made no DMS replication instance.

ls clf-lab03-portfolio.csv clf-lab03-decisions.txt
aws dms describe-replication-instances --query 'length(ReplicationInstances)' --output text

Expected output: No such file or directory for each file, then 0 in an account used only for this course.

Notes

Answers to step 2: staff-canteen-menu, retire; lab-instrument-control, retain; order-web, rehost (AWS Application Migration Service automates it); vsphere-estate, relocate; sales-crm, repurchase; orders-db, replatform to Amazon RDS for MySQL, moved with AWS DMS full load plus ongoing replication; catalogue, refactor, for example into microservices on AWS Lambda.

Step 4: billing-db needs its schema and stored procedures converted with the AWS Schema Conversion Tool (AWS SCT) first; then DMS moves the data. SCT converts structure; it does not replicate live data.

Step 5: (a) People; (b) Governance; (c) Platform; (d) Operations; (e) reduced business risk; (f) Launch.

If describe-replication-instances prints a number other than 0 in an account you share with other work, those instances were not made by this lab.

This is an independent study companion for the AWS Certified Cloud Practitioner (CLF-C02) exam and is not produced by or endorsed by Amazon Web Services. AWS, Amazon Web Services and AWS Certified Cloud Practitioner are trademarks of Amazon.com, Inc. or its affiliates.

This is an independent study companion for AWS Certified Cloud Practitioner CLF-C02 and is not produced by or endorsed by CompTIA.