Exiting a shared datacenter: a governed AWS Landing Zone and lift-and-shift migration

The client is a housing-finance company operating in India's BFSI/NBFC sector, serving customers through a nationwide branch network supported by a portfolio of core business applications, file services and databases. Prior to this engagement, the client's production and non-production IT estate was hosted on a shared, multi-tenant private cloud datacenter operated by a third-party managed services provider, where compute was provisioned as virtual machines and application data resided on NAS file shares and SAN block storage managed by the service provider.

• As the client's business and data volumes grew, the constraints of a shared datacenter model — fixed capacity, limited administrative control and slow provisioning cycles — increasingly restricted the organisation's ability to scale and respond to business demand. The client therefore decided to exit the shared private cloud and migrate its workloads to Amazon Web Services. CitiusCloud was engaged to plan and execute a lift-and-shift (rehost) migration of the client's servers and storage to AWS, to build a governed, multi-account AWS Landing Zone using AWS Control Tower and AWS Organizations, and to establish a secure, high-throughput data transfer pipeline using AWS DataSync for the migration of NAS- and SAN-resident data.

The client's workloads ran on infrastructure that was shared with other tenants and wholly operated by the incumbent provider. This left the client with limited administrative control over the environment, a dependency on provider-managed change windows for even routine capacity or configuration changes, and little visibility into how the underlying resources were allocated and consumed. Provisioning additional capacity required commercial and procurement cycles rather than an on-demand request, which slowed the delivery of new business initiatives.

• Storage was a particular constraint. Application and user data was spread across NAS file shares and SAN block volumes with fixed, pre-purchased capacity that could only be expanded through hardware refresh cycles. As data volumes grew, this created recurring capacity pressure, an inability to tier ageing data to lower-cost storage, and rising costs that were difficult to attribute back to individual applications under the shared chargeback model.
• The migration itself presented a significant technical challenge. Moving a large volume of unstructured file data from NAS and block data from SAN into AWS had to be achieved over constrained network links, without disrupting business operations, and with verifiable data integrity at the destination. The migration also had to minimise application downtime during cutover, as several of the workloads support customer-facing and branch operations.
• Finally, the client had no existing AWS foundation. As a regulated BFSI entity subject to RBI/NBFC guidelines, the IT Act and the DPDP Act, the organisation could not simply migrate workloads into an unstructured cloud account. It required a governed multi-account structure with preventive and detective controls, centralised identity, centralised logging and audit trails, and a documented security baseline in place before production workloads could be accepted onto the platform. Business continuity and disaster-recovery capability in the legacy environment was also limited and needed to be strengthened as part of the move.

The solution followed a structured, wave-based migration approach. A discovery and assessment exercise was carried out first to build an inventory of servers, applications, storage volumes and interdependencies, and to map each workload to a migration disposition. Given the client's priority of exiting the shared datacenter quickly and with low risk, the majority of workloads were dispositioned for rehost (lift and shift) with minimal or no application change, deferring modernisation to a later phase. Workloads were then grouped into migration waves based on dependency, criticality and acceptable downtime, so that each wave could be migrated, validated and cut over independently.

• In parallel, a governed AWS Landing Zone was established before any workload was migrated. AWS Control Tower was used to deploy the landing zone on top of AWS Organizations, providing a multi-account structure with dedicated management, log archive and audit accounts, and organisational units separating production, non-production and shared-services workloads. Preventive guardrails were enforced through Service Control Policies and detective controls through AWS Config rules, with AWS CloudTrail delivering centralised, immutable audit logging into the log archive account. Centralised workforce access was implemented using AWS IAM Identity Center with SSO and MFA, and the security baseline was reinforced with AWS KMS for encryption key management alongside Amazon GuardDuty and AWS Security Hub for continuous threat detection and posture management.
• Hybrid connectivity was established between the legacy datacenter and AWS using AWS Site-to-Site VPN and AWS Direct Connect, with AWS Transit Gateway providing scalable, centralised routing between the on-premises network and the AWS VPCs. Landing zone VPCs were designed with public and private subnets across multiple Availability Zones, with security groups and network ACLs enforcing least-privilege network access. Server workloads were then rehosted onto Amazon EC2 using AWS Application Migration Service, which performed continuous block-level replication from the source virtual machines into AWS, allowing each wave to be test-launched and validated in an isolated environment ahead of cutover.
• Storage was re-platformed onto native AWS services as part of the rehost. NAS file shares were migrated to Amazon FSx and Amazon EFS for workloads requiring shared file-system semantics, while archival and unstructured content was moved to Amazon S3 with lifecycle policies tiering ageing data into lower-cost storage classes. SAN block volumes were mapped onto Amazon EBS volumes attached to the rehosted EC2 instances. AWS DataSync was deployed as the bulk data transfer pipeline for this movement: DataSync agents in the legacy datacenter performed scheduled, parallelised transfers into AWS with in-flight encryption, bandwidth throttling to protect production links, incremental synchronisation so that only changed data was re-transferred, and built-in integrity verification confirming that data landed at the destination exactly as it left the source.
• Finally, operational readiness was built into the target environment. AWS Backup was configured to provide centralised, policy-driven backup across Amazon EC2, EBS, EFS, FSx and RDS, with cross-region copies supporting the disaster-recovery objective. Amazon CloudWatch provided centralised metrics, logs and alarms across the migrated estate, and AWS Cost Explorer and AWS Budgets were enabled to give the client per-account and per-application cost visibility that had not been possible under the shared chargeback model.

The governance foundation was delivered using AWS Control Tower and AWS Organizations, with AWS IAM Identity Center for centralised single sign-on, Service Control Policies and AWS Config for preventive and detective guardrails, and AWS CloudTrail for centralised audit logging. Migration execution was supported by AWS Application Migration Service for server rehost, AWS DataSync for bulk NAS and SAN data transfer, and AWS Migration Hub together with AWS Application Discovery Service for discovery, wave planning and migration tracking.

• On the target platform, Amazon EC2 provided the rehosted compute layer, with Amazon EBS for block storage, Amazon FSx and Amazon EFS for shared file systems, Amazon S3 (including Glacier storage classes) for object and archival storage, and Amazon RDS for managed databases. Connectivity and network isolation were delivered through Amazon VPC, AWS Transit Gateway, AWS Direct Connect, AWS Site-to-Site VPN and Amazon Route 53. Security and operations were underpinned by AWS KMS, AWS IAM, Amazon GuardDuty, AWS Security Hub and AWS WAF, alongside Amazon CloudWatch, AWS Backup, AWS Cost Explorer and AWS Budgets.

The migration allowed the client to exit the shared private cloud and operate on dedicated, elastic AWS infrastructure under its own administrative control. Capacity that previously required procurement cycles and provider change windows became available on demand, and the rehost-first approach meant workloads could be moved quickly and with low technical risk, without the delay and cost of re-architecting applications up front. Storage delivered the most immediate improvement: fixed NAS and SAN capacity was replaced with elastic Amazon EBS, EFS, FSx and S3 storage, and lifecycle tiering allowed ageing data to move automatically into lower-cost classes rather than occupying premium capacity.

• Using AWS DataSync as the transfer pipeline gave the client a reliable, repeatable mechanism for moving large volumes of file and block data, with incremental synchronisation and integrity verification that kept cutover windows short and gave the business confidence that no data was lost or corrupted in transit. Establishing the AWS Landing Zone through Control Tower and Organizations before migration meant that every workload landed inside a governed structure from day one, with guardrails, centralised identity, encryption and immutable audit logging already in place — a materially stronger position for demonstrating alignment with RBI/NBFC, DPDP and ISO 27001/SOC 2 expectations than the legacy environment allowed.
• Resilience and cost transparency improved in parallel. Multi-AZ deployment, centralised AWS Backup policies and cross-region copies gave the client a tested disaster-recovery posture in place of the limited business-continuity capability available in the shared datacenter, while per-account and per-application cost reporting replaced an opaque shared chargeback model.