Cloud migration is usually assessed through security, availability, performance and cost. Portability often comes later, when an organisation needs to change providers, satisfy a regulator or renegotiate a major contract.
For KenyaBank, portability must be designed in from the start.
KenyaBank is a Tier-1 Kenyan commercial bank serving about 4.2 million customers through 68 branches. It is modernising a legacy core banking environment running on Oracle WebLogic and Oracle Database in its Westlands data centre. The target architecture introduces AWS services such as Amazon Aurora PostgreSQL, Amazon DynamoDB, Amazon EventBridge, Amazon MSK, AWS IAM Identity Center, AWS Systems Manager and AWS CloudFormation.
These services reduce infrastructure work and speed up delivery, but each one creates a different level of AWS dependency.
The useful question is not:
Does the architecture contain vendor lock-in?
Almost every cloud architecture does.
The better question is:
Is the lock-in understood, controlled and justified by the business value it provides?
This article reviews five AWS-specific dependencies in KenyaBank's target architecture, estimates the effort required to replace each one and assigns an overall portability score.
Current and Target Context
KenyaBank's current environment includes:
- A monolithic Java EE core banking application
- Oracle WebLogic application servers
- A 3.8 TB Oracle 11g database
- A legacy internet banking application
- Local teller servers in 68 branches
- On-premises Microsoft Active Directory
- MPLS connectivity between branches and the Westlands data centre
The target architecture uses the Strangler Fig pattern to modernise gradually. Internet banking will be containerised, the database will move towards Aurora PostgreSQL, and applications will increasingly communicate through events and managed messaging services.
This improves scalability and resilience, but it also introduces AWS-specific APIs, data models and operations.
What Vendor Lock-In Means Here
Vendor lock-in exists when moving an application, its data or its operations away from a provider would require significant time, cost or redesign.
For this assessment, lock-in is grouped into three types:
| Type | Meaning | Example |
|---|---|---|
| API lock-in | Application code depends on provider-specific SDKs, APIs, event formats or behaviours. | Code built around DynamoDB PutItem, Query and UpdateItem cannot simply point to PostgreSQL. |
| Data lock-in | Data is stored in a model or format that is hard to reproduce elsewhere. | DynamoDB partition keys, indexes, access patterns and consistency behaviour may need redesign. |
| Operational lock-in | Deployment, identity, monitoring, patching or support processes depend on provider tools. | An app may be portable, but the operating model may need to be rebuilt. |
Scoring Method
Each dependency is assessed using five factors:
| Factor | Question |
|---|---|
| Application coupling | How much code uses AWS-specific APIs? |
| Data coupling | How difficult is the data to export and remodel? |
| Infrastructure coupling | Can the deployment definition run elsewhere? |
| Operational coupling | Must procedures and skills be rebuilt? |
| Replacement availability | Is there a mature portable alternative? |
Portability is scored from 1 to 5:
| Score | Interpretation |
|---|---|
| 1 | Highly proprietary; substantial redesign required |
| 2 | Significant lock-in; migration would be difficult |
| 3 | Moderate lock-in; migration is feasible with planning |
| 4 | Mostly portable; limited provider-specific changes |
| 5 | Highly portable; based mainly on open standards |
Exit effort is expressed in engineering effort, not cost, because a financial estimate would require details such as table count, event volume, test coverage, staff rates and recovery requirements.
Dependency 1: Amazon DynamoDB
KenyaBank plans to use DynamoDB for session storage. This is attractive because DynamoDB provides managed scaling, high availability and low-latency key-value access without database server administration.
It is also the strongest source of lock-in in the assessed architecture.
| Assessment | Result |
|---|---|
| Lock-in type | API and data |
| Portability score | 2/5 |
| Estimated exit effort | High, about 12-20 person-weeks |
| Justification | Partly justified |
DynamoDB applications often depend on partition keys, sort keys, secondary indexes, conditional writes, TTL attributes, streams, capacity behaviour and AWS SDK models. Exporting the records is only the first step. KenyaBank would still need to design a target schema, translate data types, recreate indexes and expiration behaviour, rewrite the data-access layer, migrate active sessions, test performance and cut over without invalidating customer sessions.
For ordinary session storage, DynamoDB may create more coupling than necessary. Redis, PostgreSQL or MongoDB could provide a more portable model depending on the session requirements. Redis is especially worth testing because it supports short-lived session workloads and can run across cloud and self-managed environments.
Recommended control:
- Validate whether the expected session volume genuinely requires DynamoDB.
- Place a repository interface between application code and DynamoDB.
- Keep business logic dependent on
SessionRepository, not the AWS SDK. - Maintain alternative implementations such as
RedisSessionRepositoryorPostgreSqlSessionRepository.
This will not remove data migration work, but it reduces the amount of application code that must change.
Dependency 2: Amazon EventBridge
EventBridge can route business and operational events between loosely coupled components. It is useful for AWS service integration, but it can become risky if core banking events are defined around EventBridge itself.
| Assessment | Result |
|---|---|
| Lock-in type | API and operational |
| Portability score | 2/5 |
| Estimated exit effort | Medium to high, about 8-14 person-weeks |
| Justification | Yes, at AWS integration boundaries |
Coupling can appear in the EventBridge event envelope, PutEvents calls, event-pattern syntax, rule-to-target configuration, IAM permissions, dead-letter handling, Scheduler usage and AWS-specific target integrations.
If producers publish raw EventBridge events directly, a move to Kafka, Google Cloud Pub/Sub or another event platform would require changes across many applications. Consumers may also become dependent on fields such as source, detail-type, account, region and detail.
The control is to separate the business event from the transport. KenyaBank should use a portable event specification such as CloudEvents and treat EventBridge as one possible delivery mechanism.
Recommended control:
- Standardise domain events using CloudEvents.
- Publish through an internal
EventPublisherinterface. - Keep AWS SDK calls inside adapters.
- Store schemas in a provider-neutral repository.
- Avoid placing business rules only in EventBridge rule definitions.
- Use EventBridge mainly for AWS-native operational events.
Dependency 3: AWS CloudFormation
CloudFormation gives KenyaBank repeatable AWS deployments, change tracking and automated infrastructure management. The problem is that CloudFormation templates use AWS-specific resource types such as AWS::S3::Bucket and AWS::EC2::VPC.
| Assessment | Result |
|---|---|
| Lock-in type | Operational |
| Portability score | 2/5 |
| Estimated exit effort | Medium, about 8-16 person-weeks |
| Justification | Not for the long-term target state |
The deployed resources may use standard technologies, but the infrastructure definition cannot run directly on Azure, Google Cloud or on-premises platforms. Coupling increases with intrinsic functions, nested stacks, StackSets, exports, transforms, Lambda-backed custom resources and CloudFormation-specific pipelines.
Moving from CloudFormation to Terraform or OpenTofu would require stack inventory, resource mapping, state import, dependency rewrites, non-production testing, production safeguards and careful retirement of stacks without deleting live resources.
The risk is not rewriting YAML. The risk is transferring control of running infrastructure without accidental replacement or deletion.
Recommended control:
- Use Terraform or OpenTofu for new infrastructure.
- Create modules around capabilities, not individual resources.
- Keep environment values separate from reusable modules.
- Stop adding new CloudFormation custom resources.
- Apply deletion protection and lifecycle safeguards before importing production resources.
- Retain CloudFormation templates until rollback is no longer needed.
Dependency 4: AWS IAM Identity Center
IAM Identity Center provides workforce access across AWS accounts. KenyaBank plans to connect its existing Active Directory environment using SAML 2.0 and SCIM, with permission sets assigned to teams such as Banking Operations, Technology Operations, Development and Audit.
This dependency is more acceptable because the identity federation interfaces are based on open standards.
Top comments (0)