Client Overview
Our client is a UK-based retail bank that has been supporting customers since 1997 and now serves over 3 million account holders. Through a strategic partnership with a significant financial institution, it offers a broad range of banking products and services. Customers can manage their accounts online, via mobile, or over the phone, with dedicated service centres available seven days a week for additional support. The bank places a strong emphasis on delivering accessible, reliable services while maintaining regulatory compliance. Its people-focused culture empowers teams to grow, stay customer-driven, and make money management simpler every day.
Business Objective
Our client was looking to modernize its API management platform by migrating from Apigee OPDK to Apigee Hybrid on Amazon EKS. The primary intent was to get a scalable and future-ready platform that could meet their demands. This ensured the security of sensitive data within the bank’s own network, maintained compliance, and leveraged Google Cloud services for configuration, monitoring, and analytics. Beyond immediate stability, the bank also aimed to establish a platform capable of cost-effective scaling and more efficient day-to-day operations.
Challenges Faced
Here are a few challenges that our client was facing due to the existing OPDK setup:
- The OPDK setup offers limited flexibility to meet modern API demands.
- Banks required zero downtime, as any disruption to API services would directly affect customer-facing systems and third-party integrations.
- Our client required strict security control-based access and an environment that aligns with their financial regulations.
- Risk in migrating APIs, applications, and traffic from OPDK to a hybrid environment.
How NeosAlpha Helped?
As an Apigee Partner, we adopted a seven-stage migration strategy to ensure a seamless transition from Apigee OPDK to Apigee Hybrid. All the stages are designed so that each addresses a specific set of challenges faced by our client.
1. Discovery & Planning
To offer a better solution, we first gain complete visibility into our client’s existing OPDK set, including APIs, shared flows, authentication methods, and backend integrations. This analysis helped us to identify hidden dependencies and undocumented configurations that could otherwise cause migration issues. We collaborated with the Bank’s architects to capture non-functional requirements (NFRs), assess the current API catalog, and design a detailed migration plan.
2. Infrastructure Setup
Our client was looking for a modern solution that is quite familiar with the existing setup to avoid workflow disruption. We built Amazon EKS clusters for both non-production and production environments, ensuring they were multi-zone for high availability. Our solution included infrastructure such as VPCs, firewall rules, DNS configuration, and connectivity to the backend.
This ensured continuity across environments (dev, test, pre-prod, prod) but in a Kubernetes-native setup.
3. Security Hardening
Being a bank, compliance with regulatory and InfoSec standards was one of their primary concerns. We integrated single sign-on with Google Cloud, mapped user access to their internal IDP groups, and restricted permissions to Apigee resources only. Moreover, we introduced secure secret management using AWS Secrets Manager. Earlier attention to security concerns and challenges reduced the risk of delays in later phases and ensured the new platform was hardened before any real traffic was moved.
4. API Migration
The most complex challenge was migrating the API without breaking downstream systems. We migrated APIs, shared flows, KVMs, and environment configurations incrementally and updated certain assets as per requirements. To avoid service disruption, we used header-based and path-based routing at the application load balancer, enabling selective traffic redirection to the new Hybrid environment.
Our approach solved the risk of massive cutovers and allowed us to validate individual APIs and roll back instantly when needed.
5. Testing
To ensure a successful migration, we supported their QA and performance team with load testing, penetration testing, and UAT to ensure that the platform could handle production-scale traffic. Testing was done in pre-production so we could solve the performance issue.
6. Observability Setup
To manage APIs effectively, our client needed real-time visibility into performance, errors, and traffic trends. Our Apigee set up monitoring dashboards, alerting rules, and error-handling playbooks tailored to their operations team. This solved the problem of operational blind spots, ensuring that once APIs moved to Hybrid, our client could proactively detect and respond to anomalies rather than relying on reactive troubleshooting.
7. Production Cutover
The final challenge was migrating live traffic without downtime. We set up the production EKS cluster, ran rollback tests, and piloted with a few low-risk API keys before gradually cutting over all traffic. This staged rollout allowed the bank to validate performance in live conditions while retaining a fallback option. Once confidence was established, we executed the complete cutover and provided two weeks of post-go-live support. This solved the risk in the final stage and ensured a smooth transition to business-as-usual operations.
Technology Stack
- Apigee OPDK
- Apigee Hybrid
- Amazon EKS
- Google Cloud
Results
As an Apigee Partner, here is how we successfully migrated from OPDK to Apigee Hybrid on Amazon EKS.
- Successfully migrated from Apigee OPDK to Apigee Hybrid with zero downtime and disruption.
- Strengthened security with hardened environments, role-based access controls, and SSO integration.
- Enhanced the visibility through observability dashboards, monitoring rules, and error-handling playbooks.
