The Ledger 

This regional bank relies on a substantial technology estate to offer banking, mortgage, and other services to its customers. Years of mergers and acquisitions had resulted in its platforms becoming widely distributed across multiple legacy data centers, with thousands of servers, petabytes of data, and hundreds of applications in the mix. The size was getting too big to maintain. The bank needed to vacate its legacy data center without disrupting its day-to-day operations. But undocumented dependencies made a straightforward lift-and-shift too risky. 

A Sizable Legacy Portfolio 

The bank’s timeline and systems required special care. 

Complexity Over Time. As mentioned, the environment reflected years of organizational change. Applications, databases, infrastructure, and ownership boundaries all lived in different places. That made the infrastructure shift even trickier. 

Critical Applications with Shared Dependencies. The real sticking points of the migration were the applications the bank used to support important workflows. Each application had to migrate to the new environment, along with its own shared dependencies from across databases and integrations. 

A Tight Deadline. Once the migration got off the ground, it would need to sustain its momentum and preserve continuity for critical services while the bank closed its data facilities. 

Future Growth and Scale. Even if the migration was successful, the bank still faced a larger problem. How could it find a repeatable way to support 3,000 virtual machines, while making room for rightsizing, application sunsetting, and future modernization? 

It was a big ask for anyone. With so much at stake, the bank couldn’t rely on standard migration services. It needed to invest in a partner that could connect application knowledge to infrastructure execution and overarching strategy. 

The New Investment Plan 

This engagement aligned with three areas of AHEAD’s expertise. 

Platform & Workload Modernization: Assessing and then designing AWS target states and migration patterns for critical operating systems, databases, and applications. 

Secure & Resilient Architectures: Supporting continuity during and after migration with multi-Availability Zone designs, dedicated VPCs, hybrid connectivity, recovery planning, and security controls. 

Operational Excellence: Establishing a Cloud Migration Factory with strategic and tactical pods for overlapping migration waves. 

The work unfolded across three phases: 

Advise 

AHEAD began with a six-week migration discovery effort that focused on four core business applications:  

• P8/FileNet: Content management 
• MorTrac: PowerBuilder client-server 
• LoanTrac: Java and Angular 
• Document Management System: Bank-specific platform 

These, plus a shared Oracle database, with connections to internal and external systems. 

Together, AHEAD and the bank mapped dependencies and reviewed testing protocols, then established performance baselines with documentation for current- and future-state architectures. 

Why the Groundwork Mattered: Teams were able to plan target designs, modernization efforts, and workload tests and sequences based on application-specific evidence. Each critical workload had a documented migration path. 

Build 

AHEAD and the bank then moved forward migrating the four key applications they had discussed. 

The AWS architecture pattern used multi-Availability Zone Amazon EC2 in dedicated VPCs for workloads that were tightly coupled to existing operating system and runtime stacks: 

• Amazon EFS for shared storage 
• AWS Direct Connect and AWS Transit Gateway for hybrid connectivity 
• Amazon Route 53 and AWS Certificate Manager for DNS and TLS 

All bolstered by supporting services that included Amazon CloudWatch, AWS Systems Manager, AWS Backup, and endpoint detection and response. For MorTrac, Amazon AppStream went one step further, providing a modernization path for client delivery while the server components moved to EC2.  

Following this, the teams evaluated Amazon RDS for Oracle against Oracle on EC2, based on availability, latency, and scalability. AWS Database Migration Service also identified where lower-downtime database migration was appropriate, and the bank’s own AWS team used AWS CloudFormation templates to support repeatable deployment. 

How It Came to Life: Altogether, the execution meant the bank could carefully coordinate application owners, infrastructure and database teams, and then test its stakeholders and vendor dependencies around cutover plans, validation, and rollback. When the initial RACI didn't fully support internal teams and their work, it was revised to improve collaboration and access. 

Run 

Once the applications moved, AHEAD established an AWS Cloud Migration Factory built around two complementary pods. 

The strategic pod: For application intake, portfolio assessment, wave planning, rightsizing, sunsetting analysis, target architecture, and program governance.  

The tactical pod: For preparation, migration execution, cutover orchestration, validation testing, and post-migration stabilization. 

The factory used overlapping three month waves. Each wave focused on discovery and planning, preparation and execution, and finally delivery, validation, and optimization. Quarterly checkpoints allowed the bank to review progress and incorporate feedback, so the next wave could be adjusted before the program got too far off track. 

How It Kept Delivering: The factory made the work repeatable without treating the workloads as identical. At the same time, the waves were still guided by the same disciplines: documentation, architecture updates, runbooks, and explicit attention to rightsizing and potential application retirement. 

In Good Standing 

The bank kicked off its massive production migration with a durable operating model. 

A Validated Migration Pattern. The initial application work produced current- and future-state architectures, dependency maps, migration runbooks, cost profiles, and scenario models that could all inform later waves. 

A Factory Built for Scale. The strategic and tactical pod model meant the bank could now manage an estate of approximately 3,000–3,043 VMs, with a target throughput of more than 100 VMs per month and approximately 300 VMs per quarter. 

Better Decisions Before Cutover. Application discovery, performance baselining, rightsizing analysis, and workload-specific architecture decisions gave the bank a disciplined way to determine what should move, how it should move, and what should be left behind. 

What’s Next 

With the Cloud Migration Factory, the bank’s strategic planning can now run parallel to the migration itself. As workloads keep moving, the bank can keep refining its target architecture and operating procedures. 

Regulated financial institutions are no stranger to complex legacy environments. AHEAD's approach combines discovery, architecture, financial modeling, and program governance, so data center exits aren't just about meeting a deadline but setting up the next phase of modernization.