Travel technology · Cloud transformation
Moving a live travel platform to AWS without betting everything on one cutover
A phased migration across applications, data, connectivity, security, backup and operational readiness.
76
virtual machines migrated
~38 TB
of data transferred
29%
lower operating cost
<90 min
final cutover disruption
In brief
A long-established travel platform ran from two data centres supporting live bookings, partner integrations and historical data. A single-event migration was too risky, so ClimsTech designed a phased hybrid model — private connectivity and DNS, Terraform-built AWS infrastructure, dependency-grouped workload waves, and modernised storage, backup, monitoring and security.
Working constraints
- Live customer bookings
- Partner and supplier integrations
- Two existing data centres
- Limited downtime
- Large historical data volumes
- Private network dependencies
- Legacy application assumptions
- Need for rollback by migration phase
The problem
What was actually going wrong
The platform had accumulated years of infrastructure dependency and undocumented operational knowledge. The migration had to protect live transactions while creating a modern foundation for future change.
What discovery surfaced
- 1Application dependencies crossed data-centre boundaries.
- 2DNS and network assumptions were embedded in application configuration.
- 3Historical data had the same storage treatment as active data.
- 4Backup and recovery procedures varied.
- 5Some services could move independently; others required grouped cutover.
- 6Security controls had grown inconsistently.
The engineering
What we built and changed
1Discovery and dependency mapping
Applications, data flows, integrations, network requirements, and criticality were documented.
2Hybrid connectivity
Private connectivity and name resolution supported coexistence between the data centres and AWS.
3AWS foundation
Terraform created repeatable infrastructure, network segmentation, monitoring, and security controls.
4Workload migration
Applications moved in waves based on technical dependency.
5Data and storage
Active, backup, and archival data were separated into appropriate storage classes.
6Security and operations
Activity logging, web protection, threat detection, patching, and runbooks were standardised.
The team moved from data-centre-specific operations to a repeatable cloud model with clearer security, monitoring, backup, and infrastructure standards.
The architecture
Before and after
- Data Centre A
- Data Centre B
- Application workloads
- Shared data storage (no tiering)
- Varied backup and recovery
- Inconsistent security controls
- Users and partners
- DNS, CDN and WAF
- Load balancing
- Multi-AZ application tier
- Highly available data tier
- Object and archive storage
- Monitoring and logs
- Threat detection and audit
Judgement calls
Decisions that shaped the outcome
Why maintain hybrid coexistence?
It reduced transition risk and allowed dependent systems to move in manageable groups.
Why separate active and archival data?
Different access patterns require different storage economics and recovery expectations.
Why migrate by dependency instead of business team?
Technical communication paths determined cutover risk more accurately than organisational ownership.
Verified outcomes
What changed for the business
- 76 VMs migrated
- Approximately 38 TB transferred
- Final cutover under 90 minutes
- Operating cost reduced by 29%
- Backup spending reduced by 34%
- Recovery improved from 8 hours to 2.5 hours
- Programme completed within 16 weeks
- Availability improved to 99.96%
What this engagement proves
Large migrations are safer when the transition architecture is treated as a first-class design, not temporary plumbing.
Field notes on this class of problem
All field notesCloud migration ROI: why optimisation debt compounds — and how to break the cycle
Lift-and-shift reproduces data-centre waste at cloud rates — the discipline to come out ahead.
18 min read
SRE & reliabilityDisaster recovery in the cloud: RPO, RTO and tested restores
Two numbers, a cost-justified tier, and a restore drill you have actually run.
19 min read
DevOps & deliveryZero-downtime deployments: rolling, blue-green and canary
Rolling, blue-green or canary — and the database problem that defeats all three.
18 min read