Executive Summary
Nesta Lab LLP was running workloads across three separate environments: Microsoft Azure, Google Cloud Platform, and on-premises servers. As the company grew, managing three platforms created real operational problems: inconsistent security controls, fragmented monitoring, and no unified way to scale infrastructure.
Nesta Lab partnered with Teleglobal to consolidate everything onto AWS. The migration was planned and executed in five structured phases, covering all workloads from source environments to a secure, multi-AZ AWS architecture in the Mumbai region. The cutover was completed with minimal data loss, and the new environment gave the team a single platform to manage, secure, and scale.
About Nesta Lab LLP
Nesta Lab LLP is a technology company running application services, compute workloads, and data processing systems that require consistent availability and strong security. Over time, their infrastructure had grown across three separate environments: Microsoft Azure, Google Cloud Platform, and their own on-premises servers.
Each environment had its own tooling, billing, and security model. What had started as a practical arrangement became increasingly difficult to manage as workloads grew and the team needed tighter control over performance, security, and costs.
The Challenge
Running workloads across Azure, GCP, and on-premises simultaneously created five problems that were getting harder to manage as the business scaled.
- Operational complexity
Every administrative task required switching between different platforms, each with its own console, APIs, and support model. This added overhead to routine operations and slowed the team down.
- Security gaps across environments
Enforcing consistent security policies, encryption standards, and access controls across three separate environments was difficult. Each platform had its own identity and access model, and making them work coherently was a constant challenge.
- No unified approach to scaling
Scaling workloads required separate decisions in separate environments. There was no single mechanism to add capacity quickly and consistently across the infrastructure.
- Fragmented monitoring
Without a centralised monitoring layer, the team had incomplete visibility into system health. Issues were harder to detect and took longer to diagnose because there was no single view across all environments.
- Cost inefficiency
Managing resources across multiple platforms made it difficult to track total spend, identify waste, or optimise resource utilisation. Each platform had its own pricing model and cost management tools.
Migration Approach
Teleglobal worked with Nesta Lab to design a structured migration using AWS Application Migration Service (MGN). The migration was executed in five phases, each with clear objectives and a rollback plan in place throughout.
Phase 1: Assessment and planning
Before moving anything, Teleglobal documented the full situation: server configurations, application dependencies, data flows, and security requirements across all three source environments. Based on this, the target AWS architecture was designed with a multi-AZ VPC in ap-south-1, public and private subnets, and secure network routing.
Phase 2: AWS environment setup
The destination environment was built and hardened before migration began. AWS IAM, VPC configuration, subnets, gateways, security groups, CloudWatch monitoring, and KMS encryption were all configured upfront so workloads would land in a ready and secure environment.
Phase 3: Migration enablement and replication
AWS Application Migration Service was configured and replication agents were installed on source servers across Azure, GCP, and on-premises. MGN continuously replicated workload state to AWS using encrypted replication, with no disruption to running services.
Phase 4: Testing and cutover
Test launches were performed for each workload to validate behaviour in the AWS environment before committing to cutover. The final cutover was executed in a planned maintenance window. A rollback plan was prepared and available throughout.
Phase 5: Post-migration validation
After cutover, each application was verified for functionality, performance, and data integrity. This confirmed zero data loss and that all workloads were operating correctly in the new environment.
What Was Built on AWS
Compute and networking
Amazon EC2 instances, including GPU-enabled instances, are deployed inside a secure multi-AZ VPC. An Application Load Balancer distributes traffic across availability zones, and private subnets keep backend workloads isolated from the public internet.
Security and access control
AWS IAM governs access across the environment with least-privilege policies. AWS WAF protects applications at the edge. AWS KMS handles encryption of all data at rest and in transit, with centralised key management.
Storage and analytics
Amazon S3 provides durable object storage for application data and backups. Amazon OpenSearch Service handles search and analytics workloads that were previously split across separate tools on different platforms.
Monitoring and notifications
Amazon CloudWatch provides a single monitoring, logging, and alerting layer across the entire environment. Amazon SNS, SQS, and SES handle messaging and notification workflows, replacing what was previously fragmented across platforms.
AWS Services Used
| Service | How It Was Used |
| AWS Application Migration Service (MGN) | Agent-based encrypted replication of workloads from Azure, GCP, and on-premises to AWS EC2 |
| Amazon EC2 | Scalable compute for migrated workloads, including GPU-enabled instances |
| Amazon VPC | Multi-AZ network isolation with public and private subnets and secure routing |
| Application Load Balancer (ALB) | Traffic distribution across availability zones for high availability |
| AWS WAF | Application-layer protection against web threats at the perimeter |
| AWS IAM | Centralised identity and access management with least-privilege policies |
| AWS KMS | Encryption key management for data at rest and in transit |
| Amazon S3 | Object storage for application data, backups, and archives |
| Amazon OpenSearch Service | Centralised search and analytics replacing fragmented tools |
| Amazon CloudWatch | Unified monitoring, logging, metrics, and alerting across all workloads |
| Amazon SNS, SQS, SES | Messaging, queuing, and notification services |
Results
The migration delivered practical improvements across every area that had been causing problems.
| Area | Before | After |
| Infrastructure management | Three separate platforms to manage | Single unified AWS environment |
| Security enforcement | Inconsistent across Azure, GCP, and on-prem | Centralised IAM, WAF, and KMS across all workloads |
| Availability | No unified high-availability design | Multi-AZ architecture with ALB for fault tolerance |
| Monitoring and visibility | Fragmented across multiple tools | Single CloudWatch view across the entire environment |
| Cost management | Multiple billing models, difficult to optimise | Single platform, easier to track and control |
| Data integrity | Risk during any cloud-to-cloud move | Zero data loss confirmed post-migration |
“By migrating to AWS, we have streamlined our infrastructure and significantly improved our operational efficiency. The centralised environment provides better control, enhanced security, and the scalability required to support our growing business needs.”
— Head of Infrastructure, Nesta Lab LLP
What’s Next
With a stable, unified AWS foundation in place, Nesta Lab is now in a position to optimise and expand:
- Right-sizing EC2 instances and evaluating Reserved Instance pricing as workload patterns stabilise on AWS
- Expanding CloudWatch coverage with custom dashboards and automated alerting thresholds
- Evaluating AWS AI and ML services to add intelligence to existing application and data processing workloads
- Strengthening the security posture further with Amazon GuardDuty for threat detection and AWS Config for continuous compliance monitoring