Trilogix Cloud

Migrating to AWS (or the cloud in general): Road-map

AWS provides Infrastructure as a Service or IaaS and elastic computing resources.  AWS is actually several ‘clouds’ regionally-based, named as Data Centres and within these, zones of availability.  Firms can avail themselves of these data centres and zones, with their associated server resources, through a set of APIs or application programming interfaces.  AWS’ main innovation is to present to their clients a coherent and easy-to-use API access to complex virtualised server, hardware, compute, network, and storage services.

Just to be clear, EC2 or Elastic Cloud Computing is not the ‘Cloud’. AWS services by themselves are not a ‘Cloud’. EC2 London UK region, is a cloud, and is my ‘private cloud’.



There are several strategies for migrating applications to new environments.  Any phase-approach will run into reality and the pressures of bias, time, money, and pain.  Practicably, firms can shape the methodology to their situation.  AWS’ Cloud Adoption Framework (CAF), itself based on TOGAF (The Open Group Architecture Framework), are parameters and useful checklists.  They are not commandments carved in stone.

Migrations are difficult business.  There is plenty to worry about including the following what CAF and TOGAF cover: Business Requirements; Skills and Resources; Money and budgets; Governance; Security; Business Impact; Deployment and Operations; Maintenance; ROI etc. CAF provides an action plan model given below:


Figure 1:  CAF Management Portal example


The issues on the left in the above diagram need to be managed with a SaaS application if possible. Keep in mind that about 70% of all projects in IT fail to some degree.  Much of this is due to poor project management, change management and the usual problem of not understanding requirements and providing the proper solution.  Scope creep, changes and technical resource gaps are also common.

To help develop the migration plans real-world scenarios can be used.  Each typical scenario that one finds in the marketplace can help describe the application architecture, a migration process, and the technical benefits of migrating to AWS’ Cloud.


Table 1: Scenarios

Scenario NameSolutionUse case 

Motivation for the migration

Additional BenefitsServices Used
Firm ABatch processing CRMSFA, CRM, Client based data and sales automationImprove sales, improve cash flow, collapse the call centreAutomation and improved development productivityEC2, EBS, S3, RDS, ELB, CW, Pilot Light
Firm BWeb ApplicationE CommerceScalability + Elasticity with backend integrationAuto Scaling, pro-active event-based scaling, ease of maintenanceEC2, S3, EBS, AS, ELB, CW, RDS, MemCache


Reality and Rationale

Almost every firm has legacy investments in applications and code.  They want to keep these alive, if not improve and refactor them.  An important use case within AWS is keeping old applications alive and providing a platform for either improvement (rebuilding the app to make it Cloud-Native friendly) or decommissioning the app and going to a SaaS application model.

Imagine an organization with 3 different CRM/SFA systems, all with different models, data types, flows and processes; hosted on different platforms and ageing hardware, in different locations.  A sensible plan might be the following:  keep these legacy apps alive, reduce operating and data centre costs by migrating to AWS; and then in the background, over time, migrate the data into a SaaS platform to ensure that all staff, in every location are following the same basic processes within the sales cycle.  Then decommission the legacy apps.  Gone are the maintenance and other costs of keeping these COTS (Customized off the Shelf Software) alive. The SaaS provider is now responsible.  The firm’s staff become simply consumers of an on-demand service.

A key rationale behind using AWS is to keep COTS alive, provide a future journey and migration plan to application improvement, and instil best-of-breed infrastructure, platform and application development practices (if appropriate); for your firm.  AWS is mainly about best practices.  Security for example, is best of breed within AWS – you just have to know how to deploy AWS’ various security models and services.

Keep in mind as well that on-going support, patching, upgrades, security refinement, monitoring, logging and associated analysis and improvement (which could include cloud-native-based refactoring), will cost 5 times or greater, the cost of moving to, or building de-novo, a Cloud system.  Operational considerations, including AWS skills, network knowledge, security management, back-up, disaster-recovery, OS, DB, application monitoring, patching and trouble-shooting are often downplayed or not well thought out.

Figure 2: Migration COTS to SaaS


An important aspect in migrating assets, keeping COTS alive, or deploying existing and functional systems onto AWS is the infrastructure flexibility of what AWS provides. This gives businesses a freedom to choose the programming models, languages, operating systems and databases they are already using or familiar with. This is especially so with LAMP models or basically open source-based systems (Linux, Apache, MySql, Php).

There are cases where you will not migrate certain assets to AWS.  They are not cloud ready.  They are too vital to risk a migration in the short term.  They function perfectly fine within a private data centre, or co-location facility.

However, usually there are several assets within an organization that can be moved to the Cloud today with minimal effort. The step by step, phase-driven approach, discussed in the paper will help you identify ideal projects for migration, build the necessary support within the organization and migrate applications with confidence.  Typically, you will migrate ‘incrementally’, unless the client, or organization must migrate more assets due to a data centre being shut down, a merger or acquisition, pending bankruptcy, or other pain points in which following a logical-phase-time insensitive road-map is simply not practical.


Figure 3: Classic migration phaseology


Whether it is a rush, or a slower process a successful migration largely depends on three key factors:

  1. The complexity of the application architecture;
  2. How loosely coupled the application is (with databases and other dependencies); and
  3. How much effort you are willing to put into the migration including skills development and operational support once you have deployed

The more documentation you have the better.  Conceptual, logical, network, component and entity diagrams are necessary.  Very few firms have these, complicating the migration.  However, by following the phases outlined in this paper you will likely achieve success, even if your application documentation, is absent.


A Phased Strategy for Migration: Step-By-Step Guide

Figure 3 presents the classic, ‘perfect world’ scenario to do a migration.  Figure 4 is a common road map based on this ideal.

Figure 4:  Assessment-POC-Data Migration-Application Migration-TOM-Operational Optimisation


It is a sensible approach, outlining the basic phases and milestones.  If we ignore real-world pressures including pain points, disasters and client demands (sometimes unreasonable); this phaseology is quite good.  The table below summarizes the main efforts per phase:

Table 2:  Phases


Important Elements

Some Benefits

1Cloud AssessmentFinancial Assessment (TCO calculation)

Technical Assessment (Classify application types)

Identify the tools available, or necessary Internal resource assessment (re the Cloud)

Current Estate Documentation and Discovery

Security and Compliance Assessment

License fees and impacts on contracts

Create a plan and what success looks like

Business Requirements understood,

Purpose of the project

Understanding weaknesses of the legacy system ROI, Time frames,

Resource gaps,

External help identified,

Thorough understanding of technology components and dependencies

2Proof of ConceptBuild a pilot and validate the AWS platform

Test existing software applications in the cloud

Learning by doing,

Become familiar with constraints and issues

Beta test version deployed

3Migrate the DataUse appropriate storage services

Migrate fileservers to Amazon S3

Migrate commercial RDBMS to EC2 + EBS or RDS

AWS DMS, Schema conversions, Workbenches and other tools and gateways investigated

Redundancy, Durable Storage, Elastic Scalable Storage

Automated Management Backup

Replication and live feeds

4Migrate the ApplicationForklift migration strategy

Hybrid migration strategy

Refactor or build Cloud Native code if needed

Create AMIs for each component, Hybrid or Golden

Automation of the process

Confidence with the AWS api’s

Reduce risk by validating the architecture

5Leverage the CloudLeverage other AWS services as necessary (ELB, EBS etc)

Automate HA, DR Harden security and create security templates (JSON, Cloud Formation)

Leverage multiple availability zones

Agile, DevOps focus

Best of breed scalability, resiliency

Automation and improved productivity

Automated HA and DR

6OptimiseOptimize usage based on demand

Operational support with SMEs planned, budgeted

Security enhancements

Implement advanced monitoring

Re-engineer your application (?)

De-compose RDMS & re-model if necessary

Increased utilization

Better visibility through advanced monitoring and automatic alerts


Post-it Note: The order of the phases is really important.  All the ‘phases’ need to be addressed and documented, confirming an ROI and rationale for the migration to the Cloud.


Leave a Comment

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