Advancing Centurion Lounges’ Cloud Platform for Enterprise Scale

Acquisitions create a complex engineering challenge: how do you integrate a fast-growing digital platform into an enterprise environment without slowing innovation or disrupting customers?

After American Express acquired LoungeBuddy, the Lounge Technology team inherited a platform supporting lounge discovery, access, check-in, partner integrations, and operational tooling across hundreds of lounges at the time of acquisition. As the platform continued to grow, supporting that scale required more than moving applications between cloud environments. The team needed to strengthen resiliency, simplify operations, enhance enterprise controls, and modernize how applications were built and deployed.

This blog examines the Lounge Technology team’s journey from stabilization through modernization and migration, highlighting the engineering decisions, cross-functional collaboration, and lessons that ultimately helped create a reusable approach for integrating acquired platforms at enterprise scale.

From Landing Zone to Target Zone

Following an acquisition, applications initially enter a Landing Zone: a controlled American Express cloud environment where the acquired platform can operate while its architecture, dependencies, and requirements are assessed.

The longer-term destination is the Target Zone, an environment designed to support those technologies within American Express’ enterprise infrastructure and engineering standards.

For the Lounge Technology team, the starting environment was complex. It spanned five cloud regions and included more than 20 applications running across 10 services, 15 databases, and 35 third-party tools. It also relied on manual operational processes, older application runtimes and libraries, and deployment approaches that differed from American Express’ enterprise delivery standards. Infrastructure limitations increased operational complexity and the potential risk of production incidents.

The team therefore treated the move to Target Zone as a modernization program, not a simple relocation.

Stabilize First, Then Modernize

Before migrating workloads, the team focused on improving stability and addressing the most urgent operational and control gaps. This created the capacity to modernize without transferring existing problems into the destination environment.

Rather than applying one migration pattern to every workload, the team used a phased strategy. Depending on its purpose and condition, each service was refactored, replatformed, retired, or migrated. Services were evaluated by operational criticality, runtime condition, dependency complexity, and the amount of change required to meet Target Zone standards. This workload-by-workload approach helped the team avoid unnecessary refactoring while reducing the risk of reproducing legacy issues in the new environment.

The original database estate was evaluated in the same way. Databases across different platforms and deployment models were consolidated, modernized, or retired, reducing structural complexity and simplifying ongoing operations.

Standardizing the Engineering Platform

A major part of the modernization effort was creating a more consistent application and delivery platform. The 10 services were moved to a cloud native Kubernetes platform.

The platform introduced capabilities such as autoscaling, which adjusts capacity as demand changes, and self-healing, which restarts or reschedules failed workloads. Standardizing services on a managed Kubernetes platform also gave teams a consistent unit of deployment and recovery, reducing environment-specific operational work.

The team also adopted Infrastructure as Code (IaC), managing infrastructure through version-controlled definitions instead of manual configuration. Versioned infrastructure definitions made changes reviewable through the engineering controls similar to those used for application code and reduced configuration drift between environments.

Software delivery was standardized through a modernized enterprise code repository. Continuous integration and continuous delivery (CI/CD) pipelines standardized build, test, and deployment workflows, reducing release variance and manual handoffs across services. Observability also improved through standardized instrumentation across applications, providing more consistent traces, metrics, and logs. Centralized logging gave teams one place to investigate application and infrastructure events, accelerating diagnosis and supporting operational and compliance reviews.

Treat Networking as a Core Workstream

Networking became the program’s critical path.

Applications needed secure connectivity across the Landing Zone, Target Zone, American Express’ internal private cloud, software-as-a-service providers, and other enterprise systems. Routing, domain name services, access controls, and third-party connectivity all had to evolve together.

Domain name management moved to enterprise-managed services. Network access controls were updated to support the new architecture, while connectivity constraints involving third-party services required coordinated troubleshooting across application, infrastructure, network, and security teams.

The lesson was clear: networking cannot be treated as a late-stage dependency. It must be designed alongside the application and platform architecture.

Shared Ownership and Reusable Patterns

The migration succeeded because the Lounge Technology, Site Reliability Engineering, cloud, infrastructure, network security, and application teams operated through a shared delivery and support model.

That collaboration became particularly important when problems crossed traditional organizational or technical boundaries.

The program also produced reusable Identity and Access Management (IAM) integration patterns. IAM provides managed identities and permissions so applications do not need to rely on embedded credentials. The architecture supported common enterprise data patterns including regional databases, search, caching, and object storage services.

Those patterns extended the value of the work beyond a single migration by creating approaches that could be applied to future migrations.

Results and Key Learnings

All 10 services were migrated into Target Zone, with no operational disruption during each production cutover.

Platform availability improved to near-continuous uptime. No infrastructure-related incidents were recorded during the post-migration measurement period. Query optimization reduced latency, outstanding security and compliance gaps were remediated, and reliance on third-party tooling was reduced.

The deployment footprint was consolidated and simplified while maintaining multi-region resilience and disaster-recovery capabilities through a primary region and a separate recovery region.

More important than any individual technology choice was the repeatable engineering approach that emerged from the program:

• Stabilize before migrating. Reducing existing operational risk first created room to modernize safely.
• Choose the migration path workload by workload. Not every service benefits from the same level or type of change.
• Design networking and identity early. Treating them as part of the architecture helped prevent late-stage blockers.
• Create shared ownership across teams. Cross-functional collaboration made issues easier to diagnose and resolve.

The broader lesson is that acquisition integration should be treated as an engineering transformation, not simply a cloud relocation.

For engineering teams facing similar migrations, sequencing matters. Reduce operational risk first, then modernize deliberately – and treat network, identity, delivery, and observability as first-class elements of the application architecture, rather than supporting workstreams added near cutover.

That approach helped create a platform that is more resilient and operable today while establishing a repeatable blueprint for integrating future acquired platforms at enterprise scale.