Software Projects needed to move a live, multi-tier environment off IBM Cloud Infrastructure and onto AWS while keeping both environments securely connected throughout the transition. That created several intertwined problems DoiT needed to solve at once:

• No reliable private network path between IBM Cloud Infrastructure and AWS - an existing self-managed, open-source site-to-site VPN worked in one direction only.
• Limited internal networking expertise on the Software Projects' side, and no clear precedent for connecting IBM Classic Infrastructure to AWS at the scale required.
• A need for accurate, granular cost forecasting (storage, compute, and discounting options) to plan the migration budget before workloads moved.
• A requirement to keep production stable and monitorable throughout the transition, with fast root-cause response if issues arose.
• Once migrated, a need to keep cloud security tooling right-sized so spend stayed proportional to actual risk and workload footprint.

The Environment: A Four-Tier, Dual-Site Architecture

Before migration, the team at Software Projects ran a single, well-defined architecture in two IBM Cloud regions, sized for resilience: a larger primary site and a smaller secondary site. Each site followed the same four-tier pattern:

• Load balancing: a small fleet of HAProxy instances fronting production, development, and tracking traffic separately.
• Application: web and tracking servers, a scheduled-job runner, a code-quality (SonarQube) server, and a VPN gateway (present on the primary site only).
• Container orchestration: self-managed Docker Swarm clusters, run as separate production and development clusters on the primary site and a single cluster on the secondary site.
• Data: a MySQL primary/replica pair alongside a three-node Cassandra cluster, replicated at both sites.

DoiT's migration plan called for a faithful, 1:1 lift-and-shift of this topology into a single AWS VPC in us-east-1 — keeping the same 24-node and 16-node footprints, but distributing them across multiple Availability Zones within one AWS Region instead of two independent, geographically separate IBM Cloud regions. The table below shows how the tier-by-tier composition carried over unchanged:

These counts held constant on both sides of the cutover — the same 24 and 16 nodes, in the same tier-by-tier proportions, simply relocated. That discipline mattered: it meant the Software Projects inherited an environment on AWS that behaved identically to the one their team already knew, while DoiT quietly removed a layer of infrastructure complexity by collapsing two data-center regions into a single AWS Region spread across multiple Availability Zones. It also set up the Modernize phase cleanly, since the roadmap already called for retiring the self-managed Docker Swarm clusters in favor of a managed container platform once the environment was stable on AWS.

The Approach: AWS MAP, Delivered End to End

DoiT ran the engagement across the three AWS MAP phases, with each phase building the technical and financial foundation for the next - delivered end to end by DoiT's Forward Deployment Engineering team.

1. Assess: Building a Defensible Migration Budget

Before any workload moved, the team at Software Projects needed a clear, per-service view of what AWS storage and compute would cost. DoiT built a detailed cost breakdown covering EBS and EFS — modeling monthly storage, IOPS, and throughput costs across volume types and storage classes — so Software Projects could forecast short- and medium-term spend for its migration roadmap. DoiT also worked through discounting strategy for the Software Projects' database compute, comparing DoiT Flexsave (a discounted Compute Savings Plan-equivalent with no upfront commitment) against standard and convertible Reserved Instance pricing, and explained the tradeoffs of each in the context of a possible future move to a managed database service.

2. Mobilize: Solving Cross-Cloud Connectivity

Connectivity between IBM Cloud and AWS was the critical path for the entire migration, and it did not have an out-of-the-box answer. DoiT ran a structured evaluation of options — AWS Direct Connect, a dedicated IBM Direct Link circuit, virtual router appliances, and a lightweight mesh VPN — weighing cost, stability, and setup complexity for each:

• Assessed AWS Direct Connect and IBM Direct Link Dedicated (including BGP, IP range, and billing constraints) as a dedicated-circuit option.
• Piloted a mesh VPN overlay as a fast, zero-cost fallback while longer-term options were evaluated.
• Guided Software Projects through deploying and tuning a virtual router appliance on the IBM side, including VLAN routing behavior and Layer 2 troubleshooting with IBM support.
• Helped Software Projects move from IBM Classic Infrastructure to IBM VPC to gain more flexible networking, then stood up an IPSec site-to-site VPN between IBM VPC and an AWS VPC.
• Diagnosed and resolved a subnet-overlap and routing gap between IBM Classic and AWS by allocating a dedicated, non-overlapping IP range and adjusting static routes — the fix that finally unblocked bidirectional traffic between all three environments.

The result was a stable, verified private network path connecting IBM Classic Infrastructure, IBM VPC, and AWS — the foundation that let the team at Software Projects move workloads on their own timeline without losing connectivity back to systems still running on IBM.

Keeping Production Healthy Through the Transition

During the migration window, DoiT also provided rapid operational support on the AWS side. In one case, an EC2 instance lost SSM connectivity unexpectedly with no SSH fallback available. DoiT used console-output diagnostics to identify the root cause — the root volume had run out of disk space, which prevented the SSM agent from starting — and provided a step-by-step remediation plan (volume expansion and filesystem resize) along with proactive CloudWatch disk-utilization alarms and SNS notifications to prevent recurrence, with particular attention to protecting production systems from the same failure mode.

3. Modernize: Containers and Continuous Cost Optimization

With the migration complete, the engagement moved into the Modernize phase. Software Projects' production and development stacks were still running on self-managed Docker Swarm clusters — functional, but carrying the operational overhead of manually patched managers and workers. DoiT is now helping the team at Software Projects retire those Swarm clusters in favor of a managed container platform on AWS (Amazon EKS), building directly on the consolidated, multi-AZ VPC foundation established during Mobilize rather than re-architecting from scratch.

As part of that same modernization push, DoiT is keeping cloud spend disciplined while the environment evolves. Using DCI Insights, DoiT reviewed the Software Projects' AWS Detective and GuardDuty configuration and found that security tooling costs had grown to a significant share of overall spend, driven primarily by high-volume flow-log ingestion rather than by security value delivered. DoiT quantified the tradeoffs — including which high-severity finding types depended on which data sources — and gave Software Projects a clear, evidence-based set of options for right-sizing security coverage without losing the highest-value detections. This same disciplined, evidence-first approach is carrying forward into the containerization work: right-sized from the start, rather than optimized after the fact.

The Solution: Powered by DoiT Cloud Intelligence (DCI)

Alongside the hands-on engineering, Software Projects leveraged several DoiT Cloud Intelligence (DCI) capabilities throughout the engagement — pairing an experienced delivery team with self-serve visibility into their own AWS environment:

The last two capabilities are active day to day: as the team at Software Projects modernizes onto containers, DCI AWS Intelligence and DCI Datadog Insights give them continuous visibility into total cloud and observability spend, rather than waiting for a monthly bill to surface an issue.

• Established the first working private network path between IBM Cloud Infrastructure and AWS, after earlier self-managed attempts had failed in one direction.
• Migrated all 40 servers, the full four-tier load balancing, application, orchestration, and data topology, to AWS with the tier-by-tier composition unchanged, so the team inherited a familiar environment on day one.
• Consolidated two geographically separate IBM Cloud regions into a single AWS VPC spanning multiple Availability Zones, simplifying the network and operational footprint without sacrificing the resilience of a dual-site design.
• Gave Software Projects a granular, defensible cost model for storage and compute ahead of migration, reducing budget surprises during the move.
• Resolved a production-impacting SSM outage with clear root cause and left Software Projects with proactive monitoring to catch the same failure earlier next time.
• Delivered all three AWS MAP phases — Assess, Mobilize, and Modernize — under one continuous engagement, carrying migration context forward instead of resetting it at each phase boundary.
• Positioned the customer to retire self-managed Docker Swarm clusters in favor of a managed container platform, with security and cost posture already right-sized before the next phase begins.
• Left the customer with self-serve visibility into their own environment — DCI Cloud Diagrams for infrastructure mapping, and DCI AWS Intelligence and DCI Datadog Insights for continuous cloud and observability spend tracking.

Software Projects' AWS environment is now the stable foundation for its next phase of modernization. DoiT continues to partner with the customer as it moves workloads onto containers, applying the same combination of technical delivery and ongoing cost discipline that carried the migration from initial assessment through to a fully connected, production-ready AWS environment.