Midland Microfin Ltd is an ‘NBFC-MFI’ registered with the Reserve Bank of India(RBI registration No. B-06.00458) having Head Office at Jalandhar, Punjab to deal in microfinance in India. Its vision is to be a world-class, role model, fintech-led international microfinance institution providing support to economically & socially underprivileged section of the society in their entrepreneurial journey. Midland believes in bringing innovations, leveraging fintech solutions in the process to ensure the effective delivery of their services. Midland’s financial product offering comprises of JLG loan, Individual loan, Dairy loan, Water Purifier loan, and Solar light loan.
Midland uses a web-based software application named E-FIMO that is designed to handle large volumes of accounts and transactions. It is equipped with customizable modules, menu driven interfaces and rich parameters that can run on any standard browser. E-FIMO is a scalable solution that allows the MFIs and Banks to continue to support their growing business requirement.
The customer was looking for a partner who could help them migrate their E-FIMO application Workload to the AWS Cloud and provide them with a proper perspective on the business benefits of migrating to a cloud infrastructure. They wanted to understand the cost and service uptime implications of migrating to AWS Cloud.
• The Midland had a relatively large number of customers; thus, they needed their service to be available round-the-clock. To maintain its infrastructure in good working order constantly, Midland was spending a lot of money on routine maintenance. But they were having issues with uptime because of regular hardware failures, which was harming the reputation of the business with its customers.
• The customer’s client base was increasing exponentially, and the customer was finding it challenging to scale up the on-prem infrastructure proportionately. This resulted in a revenue loss.
• The customer was apprehensive of the data security on AWS and wanted to be sure that sensitive data would not be compromised or lost when stored on the Cloud.
1. Members from the Workmates Sales and Technical Support Teams visited the customer’s stakeholders and involved with them in a holistic discussion to
understand their current concerns and understand both their business and technical objectives.
2. The customer was made aware of the AWS Cloud uptime SLA and was introduced to the AWS Cloud’s scalability and high-availability features. They
were also made aware of the cost benefits of migrating their on-prem infrastructure to AWS.
3. The customer was introduced to the security and data durability features of the AWS Cloud. They were explained the various security standards,
procedures and services available on the AWS Cloud and the high precision durability of AWS Cloud Storage technologies like S3.
4. It was advised to the customer that the process for Migration Readiness Assessment (MRA) be undertaken but the customer was not very keen on sitting through the detailed data gathering exercise as is required in an MRA.
5. In order to obtain a detailed utilization report of the customer’s existing infrastructure and to obtain the right-sizing information for hosting the resources on the AWS Cloud, the AWS Migration Evaluator Tool was used with the customer’s consent. The customer was presented with a detailed report highlighting the 3-year cost and performance benefits of migrating their current application infrastructure to the AWS Cloud with right-sized server instances.
6. The dependencies for the existing application infrastructure were determined and the applications were migrated to the AWS Cloud in various phases using the Cloud Endure tool following AWS best practices.
7. For migrating the customer’s MSSQL databases, the AWS Database Migration Service (DMS) was used, adhering to all AWS specified best practices.
8. All the Application and Database servers were migrated to private subnets. The public subnets were provisioned with Application Lod Balancers to provide secure access to the applications by external Internet users.
9. SSL Certificates were implemented on the Application Load Balancers to provide HTTPS based secure access to all applications.
10. SSL VPN servers were implemented on the public subnet to provide RDP and SSH based access to the technical team for administrative and application development activities.
11. NAT Gateways were created in the public subnets for providing safe and secure Internet access to the Application and Database servers in the private subnets.
12. AWS enterprise tool CloudWatch was implemented for monitoring server resources and trigger alarms in case of any service outage issues.
13. AWS S3 with an object-based storage was provisioned as a native backup site to accumulate the data backups of the database servers daily. To protect unwanted access to backups, the S3 buckets were encrypted with SSE-S3.
14. AMIs of the server instances and EBS snapshots of the server hard disks were scheduled to be regularly taken to restore the server instances in the rare case of any service outage.
15. The servers were configured with the latest updated versions of Windows and Linux Server OS according to customer requirements. The root EBS volumes for all servers were kept only for the OS. An additional EBS volume was used for data related to the applications and databases.
16. Periodic patching activities for the servers were configured through AWS SSM Patch Manager.
[email-download download_id=”3481″ contact_form_id=”3284″]