Application Migration (Refactoring) to Cloud

Introduction

EXL is a leading operation management and analytics company that helps businesses enhance growth and profitability in the face of relentless competition and continuous disruption. Using our proprietary award-winning Business EXLerator Framework™, which integrates analytics, automation, benchmarking, BPO, consulting, industry best practices and technology platforms, EXL looks deeper to help companies improve global operations, enhance data-driven insights, increase customer satisfaction, and manage risk and compliance. EXL serves the insurance, healthcare, banking and financial services, utilities, travel, transportation and logistics industries. Headquartered in New York, New York, EXL has approximately 25,000 professionals in locations throughout the United States, Europe, Asia (primarily India and Philippines), Latin America, Australia, and South Africa.

EFMFM is enterprise telematics and end to end ERP platform developed by NGFV, to manage complete employee transportation process for large enterprise clients encompassing fleet management, intelligent routing, live tracking, compliance, and security. EFMFM has successfully managed to resolve EXL’s employee transportation problem across multiple locations in India.

With the growing number of enterprise customers, the team needed a scalable Cloud solution with disaster recovery option. The customer was already using TMS (Transport Management System) which is Windows-based Desktop Application with BCP from hot standby DCs. Multiple Instances of TMS were running at each facility (Location wise across India).

Current System overview:

The customer was using TMS (Transport Management System) which is Windows-based Desktop Application. Multiple Instances of TMS were running at each facility (Location wise across India).

TMS (Transportation Management System) is a software application designed to manage and optimize inbound and/or outbound transportation operations. Typically, TMS serves both shippers and logistics service providers, including Employee Transport management. Furthermore, its functionalities make it suitable for organizations that not only have complex logistics operations, but also those that may have basic transportation needs.

Key Business/Systems requirements:

• Automated application Provisioning.
• Software Installation & Configuration
• Continuous Monitoring
• Scheduled Backup implementation
• High availability of DB and other services

Solution Considerations

The primary objective was to re-platform the transport management application from On-Premises to AWS cloud to optimize TCO and utilization of resources. The on-premise application was robust and must perform exactly in the same fashion in the public cloud. Customer Migrated from TMS to EFMFM, for several reasons including its rich features, availability of Mobile apps for colleagues, Drivers, Vendors and Transport Admins and availability of application on AWS Cloud.

EXL includes 11 facilities across the country using EFMFM with desired Key features and Integration.

Choice of Migration approach

With a deep understanding of the AWS features to address the client requirements, Newt Global execute the sequence of actions all the way up to application migration.

• Refactor the code base to run on EFMFM platform
• Launch AWS MySQL relational databases thru RDS
• Implement AWS autoscaling with Elastic Load Balancer
• Leverage S3 bucket, Java Spring 5, Android studio, IOS (Objective C), Angular JS for Dev, QA, Stage and Prod environments.
• Multiple availability zones (AZ) were also Created for global rollout (South Africa, Philippines, Mexico, and India).

Design Considerations:

Architecture

To build the confidence of the customer, the application was hosted in a staging environment to validate all the functionalities are fully tested with the client data set. For a period of 6 weeks, this environment was used to make changes as required and get them validated with live data sets for performance.

Staging Environment

The staging environment is the replica of a Production environment and will also be referred to as Pre-Prod. Pre-Prod was used for

1. User Acceptance Testing
2. Load / Performance Testing
3. Regression Testing
4. Sanity Testing

The Pre-Prod RDS will be a snapshot taken out of Prod RDS on some defined interval of time.

Implementation Phase:

Since the application is running on a SaaS platform,  the initial set-up and provisioning of services is quite fast and follows a templated approach. The configuration of DB and porting of data was done in 3 weeks’ time. Additional customization of UI and enhancements tool for 4 weeks.

Start of the project: January 2018 – Completion of all sites: August 2018.

Timelines

The customer had planned a progressive roll-out plan for 11 sites with 25,000 users spread across. A round robin approach was taken to complete the different phases of the implementation.

• Freezing the customization requirements took 2 weeks.
• Setting-up the staging environment took 1 week
• Developing enhancements took 2 weeks
• UAT with actual data took 3 weeks
• Configuring and launching the production environment took 1 week
• Roll-out to subsequent sites took 1 week each

Team structure

The team size for the first site was 6 people (2 developers, 1 architect, 1 QA, 1 DBA, and 1 implementation engineer) all of them relevant AWS certification.

The implementation team for each of the subsequent sites has two-member teams to complete the tasks.

RACI Matrix

Use of DevOps tools

Git Hub, Jira, Confluence, Ansible, and Jenkins were used in the process of migration extensively.

AWS services used are EC2, S3, ELB, Cloud Watch, and RDS.

EFMFM AWS Config.

• Elastic Compute Cloud – EC2 with Autoscaling.
• Relational Database Service – RDS
  1. My SQL Database on RDS Cloud Server
• S3 – Storage

Key Integration

• SSO (Single Sign-On) Integration
• Leave & Attendance (L&D)

Deployment architecture

Newt Global successfully replaced the current on-prem solution with cloud-based solution along with data migration from current systems to AWS. Currently, the team is also looking at Aurora as a special requirement for one of the clients needing 5 times faster output than MySQL.

Some of the features tested before production cut-off were:

• Infra Failure
  • EC2 Failure
  • Server Failure
  • RDS Failure
  • Region Failure
• Application Failure
• HOT Sites
  • The secondary is the replica of Primary and always in active mode. The Secondary RDS will always sync with Primary RDS. If the DR happened the EFMFM team will change the DNS entry (ELB URL) It will take 5 mins to up the sites.
• Warm Sites
  • Secondary RDS will be in active mode. The EC2 instance of Secondary sites will be in passive mode. The AWS team will make EC2 instance active and the EFMFM team change the DNS entry (ELB URL). it will take 15 mins to up the sites.
• Cold Sites
  • Secondary RDS will be in reading replica. The AWS team will promote the Secondary RDS and make it as Write replica. The AWS team will launch the instance from AMI. The EFMFM team will deploy the application and start the server. The EFMFM team will change the DNS entry (ELB URL) in Go Daddy. It will take 1 hrs. time to up the sites.

Security considerations and implementation

The focus on security was present right through the process of migration and the enterprise has clear guidelines around this and the project team implemented them.

• Hardened Image provided by Enterprise AWS AMI Team
• Enabled with SSO login
• VPC design, security groups, network access control were implemented with the help of the IT team at the client place.
• Application specific IAM Policy which applies in EC2, S3, RDS in all resources
• TLS Enabled from the application end

Business benefits of the migration:

The migration after refactoring is envisaged to give the following benefits to the client in a virtual data center environment as and when the application is on AWS.

Availability: 99.99 % availability for business continuity and user satisfaction

Autoscaling: Application able to handle 25000 users at peak time

Disaster Recovery: System can be replicated and recovered quickly into AWS without disruption or data loss

Pro-active Monitoring and remediation

Centralized Login mechanism