ClimsTech

Retail technology · Application replatforming

Moving from server-specific deployment to a standardised container platform

A staged replatforming of selected services, with automated build, health management, scaling and controlled migration.

GKETerraformKubernetesCI/CD

24

services migrated

26%

lower compute cost

15 min

deployment (from 90m)

57%

fewer deployment failures

In brief

A retail technology platform ran services directly on AWS EC2, with varied deployment methods and server-specific configuration where scaling meant changing whole machines. ClimsTech assessed application suitability, containerised selected services, built a GKE platform through Terraform, standardised delivery, and migrated workloads incrementally so EC2 and GKE could coexist until validation completed.

Working constraints

  • Existing EC2 production environment
  • Mixed stateless and stateful services
  • Server-specific configuration
  • Need for coexistence during migration
  • Limited application rewrite
  • External dependencies
  • Requirement for rollback

The problem

What was actually going wrong

A retail technology platform operated application services directly on AWS EC2. Deployment methods varied, server configuration differed, and scaling required complete machine changes.

What discovery surfaced

  1. 1Some applications relied on local filesystem state.
  2. 2Configuration was embedded in server setup.
  3. 3Release procedures differed by service.
  4. 4Health checks were inconsistent.
  5. 5Scaling one service required scaling complete servers.
  6. 6Environment differences caused deployment risk.

The engineering

What we built and changed

1Service suitability assessment

Applications were evaluated for state, dependencies, operating-system requirements, and external integration.

2Containerisation

Standard images were created, with configuration and secrets externalised.

3GKE foundation

Terraform created networking, clusters, node pools, ingress, monitoring, and service accounts.

4CI/CD

Pipelines automated build, testing, image publication, and deployment.

5Migration

Services moved individually, allowing EC2 and GKE to coexist until validation completed.

Releases became service-based, repeatable, and independent of individual server knowledge.

The architecture

Before and after

Before
  • AWS EC2 instances
  • Server-specific configuration
  • Mixed stateless and stateful services
  • Manual machine-level scaling
  • Inconsistent health checks
  • Varied release procedures per service
After
  • CI/CD pipeline
  • Container registry
  • GKE platform
  • API services
  • Background jobs
  • Web services
  • Monitoring and logs
  • External data services

Judgement calls

Decisions that shaped the outcome

Why replatform instead of rewrite?

The applications could gain operational benefits from containers without the cost and risk of redesigning business logic.

Why exclude some services?

Not every workload is suitable for early containerisation; state and operating-system dependencies were handled deliberately.

Why define health and resource policies early?

Containers without production health and resource configuration simply move instability into a new platform.

Verified outcomes

What changed for the business

  • 24 services migrated
  • Compute spending reduced by 26%
  • Deployment reduced from 90 to 15 minutes
  • Deployment failures reduced by 57%
  • Capacity expansion reduced from 30 to under 5 minutes
  • Availability improved to 99.95%
  • Server-specific configuration reduced by 82%

What this engagement proves

Containerisation delivers value when it changes the operating model, not merely the packaging format.

Considering Kubernetes for existing applications?

See more engagements

Discuss application replatforming