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.  It is sensible to keep these alive, reduce operating and data center costs; and then in the background, 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.  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 instill 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. 

Figure 1:  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 center, 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 below 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 center 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. 

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; and
  3. How much effort you are willing to put into migration.

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 2:  AWS classic migration phaseology

 

The figure above presents the classic, ‘perfect world’ scenario to do a migration.  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:

Phase

 

Important Elements

Some Benefits

1

Cloud Assessment

Financial Assessment (TCO calculation)

Technical Assessment (Classify application types)

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

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

2

Proof of Concept

Build 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

3

Migrate the Data

Use 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

 

4

Migrate the Application

Forklift 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

5

Leverage the Cloud

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

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

Leverage multiple availability zones

Agile, DevOps focus

 

Best of breed scalability, resiliency

Automation and improved productivity

Automated HA and DR

6

Optimise

Optimize usage based on demand

Implement advanced monitoring

Re-engineer your application

De-compose RDMS & re-model if necessary

Increased utilization

Better visibility through advanced monitoring and automatic alerts

Table 1: Phases explained

 

Post-it Note: In reality, the order of the phases is not that important.  Some firms don’t have time for phase 1, so they bull ahead into phase 2.  Some will jump and do a quick migration as given in phase 3 and ignore the first two phases.  Other firms might decide that migrating an application first, followed by the data is a better approach.