Skip to main content
Citius Cloud Services
  • BFSI
  • AWS
  • Cloud

Decommissioning the last physical datacenter for a SEBI-regulated stockbroker

Introduction

The client is a SEBI-registered stockbroker and depository participant, providing equity, derivatives, IPO, mutual fund and margin trading services to retail and high-net-worth investors, and is a trading and clearing member of India's principal stock exchanges as well as a depository participant with both NSDL and CDSL. Its trading and post-trade platforms are time-critical systems: any loss of availability during market hours has an immediate impact on clients, on settlement obligations and on the firm's regulatory standing.

  • While the client's production workloads already ran on AWS, its disaster-recovery estate remained on-premises in a self-managed datacenter — the last significant physical infrastructure footprint the firm operated. This left part of the estate dependent on ageing hardware that had to be procured, housed and refreshed on a capital cycle, and that was operationally and architecturally divergent from the rest of the environment. CitiusCloud was engaged to migrate these workloads out of the on-premises datacenter into the AWS Asia Pacific (Hyderabad) region — establishing a governed AWS Landing Zone, rehosting the servers, transferring the associated file and block data, and decommissioning the on-premises site once the migration had been validated.

Problem Statement (Challenges)

The client's disaster-recovery workloads ran on-premises on dedicated physical infrastructure that the firm had to procure, house, patch and refresh itself. Because the estate was sized against a fixed hardware footprint, capacity could not be adjusted to match changing demand, and additions required procurement lead times measured in weeks or months rather than minutes. Maintaining a physically distinct technology stack also carried a continuing operational burden — separate hardware support contracts, separate patching and monitoring processes, and a separate skill set — for an environment that delivered no elasticity in return.

  • The arrangement was also capital-inefficient and difficult to cost accurately. Substantial investment was tied up in hardware that had to be sized against peak requirement and refreshed on a fixed cycle regardless of actual utilisation, and because the infrastructure was shared across workloads within the datacenter, running costs could not be attributed cleanly back to individual applications. Any expansion was a capital decision rather than an operational one, which slowed the firm's ability to respond to changing business requirements.
  • The migration itself presented real execution risk. Moving server workloads and a large volume of associated file and block data out of the on-premises datacenter had to be achieved over constrained network links, without disrupting live services, and with verifiable data integrity at the destination. Because the client's platforms are time-critical during market hours, cutover windows were narrow and largely confined to periods outside trading, so the migration needed a method that allowed each workload to be replicated, test-launched and validated well ahead of the actual switchover rather than moved in a single high-risk event.
  • Finally, the workloads could not simply be lifted into an unstructured cloud account. As a SEBI-regulated stockbroker and depository participant, the client operates under obligations covering data residency within India, geographic separation between sites, access control, encryption and auditability, with supporting evidence required on a periodic basis. A governed multi-account structure with preventive and detective controls, centralised identity, centralised logging and a documented security baseline therefore had to be in place and validated before any production workload could be accepted onto the target platform.

Solution Proposed

The engagement began with a structured discovery and assessment exercise that built a full inventory of the in-scope servers, applications, storage volumes and interdependencies, together with their data volumes and acceptable downtime. AWS Asia Pacific (Hyderabad) was selected as the target region because it keeps all workloads and data within India, satisfying data-residency expectations, while providing meaningful geographic separation — including a different seismic zone — from the firm's existing AWS footprint. Given the priority of exiting the on-premises datacenter quickly and with low risk, workloads were dispositioned for rehost (lift and shift) with minimal application change, and were grouped into migration waves by dependency and criticality so that each wave could be migrated, validated and cut over independently.

  • 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, with AWS CloudTrail delivering centralised, immutable audit logging into the log archive account. Centralised workforce access was implemented through 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 on-premises datacenter and AWS using AWS Direct Connect, with AWS Site-to-Site VPN as a resilient backup path, and AWS Transit Gateway provided scalable, centralised routing between the corporate network and the landing zone VPCs. Server workloads were then rehosted onto Amazon EC2 using AWS Application Migration Service, which performed continuous block-level replication from the source machines into a staging area in AWS, allowing each wave to be test-launched into an isolated subnet and functionally validated ahead of cutover.
  • Data and storage were re-platformed onto native AWS services as part of the rehost. File shares were migrated to Amazon FSx and Amazon EFS where shared file-system semantics were required, while archival and unstructured content was moved into Amazon S3 with lifecycle policies tiering ageing data into lower-cost storage classes. Block volumes were mapped onto Amazon EBS attached to the rehosted instances, and databases were moved onto Amazon RDS. AWS DataSync was deployed as the bulk data transfer pipeline, with in-flight encryption, bandwidth throttling, incremental synchronisation, and built-in integrity verification.
  • Each wave was cut over during an agreed window outside market hours, with a documented rollback path available until the migrated workload had been validated in AWS. Once all waves were complete and verified, the on-premises datacenter footprint was decommissioned. AWS Backup provided centralised, policy-driven backup, Amazon CloudWatch delivered centralised metrics, logs, alarms and dashboards, and AWS Cost Explorer and AWS Budgets gave the client per-account and per-workload cost visibility that the on-premises arrangement had never provided.

Services Used

The governance and migration 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 rehosting the on-premises servers onto Amazon EC2, and AWS Migration Hub together with AWS Application Discovery Service for discovery, dependency mapping and migration tracking.

  • In the target environment, Amazon EC2 with Auto Scaling provides the 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. Connectivity and network isolation are delivered through Amazon VPC, AWS Transit Gateway, AWS Direct Connect, AWS Site-to-Site VPN, Elastic Load Balancing and Amazon Route 53. Security and operations are 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.

Benefits

The migration allowed the client to decommission its remaining on-premises datacenter footprint altogether, removing the capital cost, hardware refresh cycles, physical facilities overhead and specialist support contracts associated with running a self-managed site. Because the migrated workloads are now built from the same AWS services, tooling and automation as the rest of the firm's estate, the environments no longer diverge, and changes can be applied consistently through a single governed process rather than reconciled manually across two different platforms.

  • Fixed hardware was replaced with elastic, on-demand infrastructure. Capacity that previously required a procurement cycle and a capital decision is now provisioned in minutes, and storage that was constrained by pre-purchased volumes is now served by elastic Amazon EBS, EFS, FSx and S3, with lifecycle tiering moving ageing data automatically into lower-cost classes rather than occupying premium capacity. The migration method itself also proved low-risk: AWS Application Migration Service provided continuous replication and pre-cutover test launches so that each wave was validated before it went live, while AWS DataSync's incremental synchronisation and integrity verification kept cutover windows short and gave the business confidence that no data was lost or corrupted in transit.
  • Landing the workloads inside a governed AWS structure also strengthened the client's control and compliance position. Every migrated workload now sits within a Control Tower landing zone with guardrails, centralised identity, encryption and immutable audit logging already in place, and all data remains within India in a region that provides genuine geographic separation from the firm's existing AWS footprint — a materially stronger position for demonstrating alignment with SEBI expectations than the on-premises arrangement allowed. Centralised AWS Backup policies and unified Amazon CloudWatch monitoring replaced siloed operational processes, while AWS Cost Explorer and AWS Budgets introduced per-account and per-workload cost visibility.

Get in touch

Tell us about your requirements and our team will get back to you.