Trilogix Cloud

AWS Cloud Migration Services

If migrating to the Cloud, just use the native tools provided by the main cloud vendors.  Don’t invent such tools yourself.  AWS has a plethora of tools, along with Azure and Google.  The following looks at the key AWS services which will allow for a smooth and cost-effective transition to the Cloud.




1-Cloud Adoption Readiness Tool or CART

Online report driven by user input, premised on the AWS Cloud Adoption Framework or CAF (based on TOGAF).  Assesses 6 key CAF areas in relation to moving to AWS:  Business, Organisation, People, Security, Operations, Platform.  You will need to supplement this report with your constraints around time, skills, budgets, and applications-database details.




Move data from on-premises into S3 (or EFS) and then into the re-platformed applications.  Can migrate full and then incremental copies of the data.


3-Server Migration Service


Agentless migration of live on-premises workloads to AWS with scheduling and tracking.  AMIs are automatically created in a three-tier architecture which has commonality between servers with multiple Application and Web servers performing the same function allowing AMI reuse.  Example.

1. Microsoft SQL Server – Database Tier
2. Ubuntu Server – Application Tier
3. IIS Web server – Webserver Tier


4-CloudEndure Migration

Migrate large estates into AWS fairly quickly without long cut-over Windows, or needing to worry about the Target machines networking and server details (drivers, keys etc).  This is a re-platforming tool, you can re-architect if needed later.

CloudEndure will continually replicate the source machines into a staging area in an AWS account without causing downtime or impacting performance.  Production environment can be created or launched with an automatic conversion of machines from their source infrastructure to the AWS infrastructure so they will boot up and run natively in AWS.


  1. Install the CloudEndure Agent on the selected source machines (does not require a reboot nor does it impact system performance in any noticeable way.)
  2. Agent connects to a self-service, web-based CloudEndure User Console, which then issues an API call to the selected target AWS Region to create a staging area in the customer’s account designated to receive the source machine’s replicated data.
  3. The staging area consists of both lightweight EC2 instances that act as Replication Servers and low-cost staging EBS volumes. Each source disk is mapped to an identically sized, low-cost EBS volume in the staging area.
  4. The Replication Servers receive data from the CloudEndure Agent running on the source machine and writes this data onto staging EBS volumes. One Replication Server can handle multiple source machines replicating concurrently.
  5. Replicate all source disks and update in real time via continuous asynchronous replication (block level).
  6. Configure a Target Machine Blueprint in the CloudEndure Console, which defines where each machine should launch and how it should be provisioned at the time of test or cutover.
  7. Launch Target Machines and CloudEndure Migration will set-up a temporary Machine Converter responsible for modifying the Target Machine to be able to boot and run natively in AWS (including drivers, bootloader changes, network adapters, OS activation, KMS). The conversion process normally takes under a minute, irrespective of the size of the machine, and is executed on all launched machines in parallel.


5-Database Migration Service

AWS Database Migration Service helps you migrate either homogenous (eg Oracle to Oracle RDS) or heterogenous databases (eg. MySQL to Aurora) to AWS. The source database remains fully operational during the migration, negating impacts on the application using the datastore.  There is continuous data replication.  You can also migrate the data to Redshift to build a datawarehouse, or into S3 to build data-lakes.


6-Schema Conversion Tool

When the database engines are different (Oracle to Amazon Aurora, Oracle to PostgreSQL, or Microsoft SQL Server to MySQL) obviously the schema structure, data types, and database code of source and target databases can be quite different, requiring a schema and code transformation before the data migration starts.  These constraints make a heterogenous migration a 2-step process.

First use the AWS Schema Conversion Tool to convert the source schema and code to match that of the target database.

Second after this is completed, use the AWS Database Migration Service to migrate data from the source database to the target database.

All the required data type conversions will automatically be done by the AWS Database Migration Service during the migration. The source database can be located in your own premises outside of AWS, running on an Amazon EC2 instance, or it can be an Amazon RDS database. The target can be a database in Amazon EC2 or Amazon RDS.

A useful use-case combining the Schema mapping service and DMS is consolidating datastores into a data warehouse or similar on AWS.  An example could be the conversion of 3 different MySQL engines, one on-premise, on as a COTS on EC2, and one as an RDS; and moving all 3 to Aurora.



Leave a Comment

Your email address will not be published. Required fields are marked *