Migration of Legacy Applications to the Cloud

Mobile Tablet Desktop

"Fabric made the decision to move to AWS easy. The approach to the PoC was lightweight and quickly validated our critical systems could run in AWS. Fabric’s iterative approach gave us continuous visibility and confidence that we would meet our deadline to decommission our legacy hardware and maintain service levels of our critical freight lodgement systems."

Angus Bissland, Head of Commercial, IT at Australia Post

At a Glance

  • Fabric uses agile/iterative methods to build a Proof of Concept and validate applications can run on AWS

  • Fabric utilised the structure of a PoC to ‘showcase’ the success criteria to Australia Post, thereby proving the process and endorsing next steps for full production migration
  • Fabric works with AWS and Australia Post to define architecture
  • Applications are re-platformed and successfully migrated with no service disruption
  • Legacy on premise infrastructure was shut down and decommissioned three months post transition
  • Australia Post was able to exit the datacentre and reduce its carbon footprint

Challenge

Fabric, a key application development and support vendor to Australia Post had managed core freight and logistics applications, hardware, network, OS in a traditional datacentre for over 6 years.

The equipment was due for refresh, however Fabric identified an opportunity to look at more strategic options that tied in with Australia Post’s cloud first policy and desire to move away from traditional on premise hardware and consolidate their data center footprint.

Fabric looked at both private and public cloud options, however on assessment found the private cloud/data center vendor cost model prohibitive and the operating model inflexible. It was at this stage that it was determined to investigate the public cloud offering from AWS further.

Once the desired target end state was agreed with Australia Post the project was broken into a number of phases.

The 1st phase involved Fabric configuring database replication to AWS to minimise risks associated with the current SAN and existing backup infrastructure.

The 2nd phase, a proof of concept (PoC) was implemented, the results of which were ‘showcased’ to the customer which included the detailed project plan, resource time and cost estimates for the end to end migration and transition. The solution pricing was sized as a “total cost” per application i.e. S, M, L (including L2 and L3 application support, infrastructure support, and service management).

The 3rd phase ensured all architecture and migration strategies was tested and defined as well as the establishment of a “Direct Connect” between Australia Post’s network and the AWS environment.

The final phase was the migration of the production applications. The migrations were cutover outside of business hours and with no business impact, with the entire project (phases 1 through 3) being delivered in less than 6 months.

Challenge

Solution

The following diagram is a visual representation of the 3 potential migration strategies for the applications. Initially all 3 applications were closer to the lift and shift approach but it was determined that this was not the ideal solution. Only application 2 kept the original operating system due to coding requirements, however, it was determined to refactor code at a later date.

Challenges during the migration necessitated the requirement to change some functions and decouple functions from EC2 instances. This ultimately this resulted in more robust applications, better suited to the AWS architecture.

Following migration, all 3 applications remained classic 2-tier designs, but now utilise AWS features such as; multiple availability zones, ELB’s, and autoscaling of EC2 instances.

A standardised approach was developed across all applications for monitoring and alerting via CloudWatch, Kinesis streams, and Elasticsearch for log capture and consolidation.

Additionally the following features were implemented per application:

Application 1

  • Update to Windows and IIS version.
  • Minor code changes

Application 2

  • Decouple processes from web servers to run on small separate EC2 instances.
  • Implement AWS auto scaling groups and utilise multiple availability zones
  • Configure AWS CodeDeploy

Application 3

  • Migrate application from Weblogic to Tomcat
  • Upgrade Red Hat Linux to AWS supported version
  • Add NGINX for URL offload
  • Setup and configure Maven, Artifactory, for moving the application towards automated deployments and configure daily tests of dependencies.
  • Introduce TeamCity for continuous integration and management of deprecated libraries.
  • Sync and migrate Oracle 11g DB to AWS EC2.
  • Cutover with minimal downtime, and outside of business hours
Solution

We'd love to hear from you