Skip to content

Cloud Modernization

Service ownership

Owner: professional-services (ps-pm@clouddigit.ai) — Status: GA — Last audited: 2026-05-11

Re-platforming and re-architecting toward cloud-native patterns — typically the wave after a lift-and-shift.

What it is

A scoped engagement to move workloads from "running on cloud" to "designed for cloud":

When to invest

  • After lift-and-shift, when the app is stable on cloud and the team has cycles
  • When you have enough confidence in cloud operations to reduce VM count without losing sleep
  • When sovereignty / scale / availability requirements exceed what lift-and-shift gave you
  • When the app is being re-written for other reasons anyway — bundle the modernization

Anti-patterns to avoid

  • "Big bang" rewrites — high failure rate, year+ delays, bad ROI
  • Modernizing before stabilizing — adding two unknowns at once
  • Modernizing without business signal — modernization for its own sake delivers nothing

Engagement shape

Smaller and more iterative than Migration. Typical engagements:

  • 4 weeks: containerize one application
  • 8 weeks: stand up a CI/CD platform with one pilot service
  • 12 weeks: end-to-end re-platform of a single application
  • 6 months: full estate re-platform (multiple applications, in waves)

Deliverables

  • Architecture decision records (ADRs) for each major choice
  • IaC modules (Terraform) — yours
  • CI/CD pipeline templates — yours
  • Runbooks for the new operating model
  • Hand-off training for your operators

Pricing

T&M or fixed-fee per scope; T&M is more common because the unknowns are higher. See Pricing.

Operate this service

Refactoring applications to be cloud-native — containerization, microservices, managed services adoption.

When to engage

After lift-and-shift, customers often want to take advantage of cloud-native capabilities: - Container & K8s adoption - Managed-DB instead of self-hosted - Serverless for spiky workloads - Auto-scaling, distributed caches, etc.

Modernization happens after migration. Don't combine; scope explodes.

Engagement model

Modernization is consulting-led: - CD architects + customer team - 3-9 month engagements typical - Sprint-based delivery

IAM

Same as migration; CD principals get scoped access for the duration.

Pricing

T&M for architecture phases, fixed-price for execution phases. Customer team co-invests time.

Outcomes

Workload type Modernization path
Monolithic app Containerize first; extract services iteratively
Self-hosted DB Migrate to managed
VM-based scaling Move to ASGs or K8s
Static-asset serving Move to CDN + object storage
Scheduled jobs Move to Serverless
Authentication Adopt SSO/SAML/OIDC if not already

Engagement structure

Phase 1: Assessment (2-4 weeks) → Current state, gaps, target state, roadmap Phase 2: Foundation (4-8 weeks) → Platform setup: K8s, CI/CD, monitoring, security Phase 3: Refactoring sprints (3-6 months) → Workload-by-workload modernization Phase 4: Handover (2-4 weeks) → Training, runbooks, transition to BAU

Sprint cadence

2-week sprints with: - Sprint planning - Mid-sprint demo - Sprint review with metrics - Retro

Each sprint produces a working, deployed increment.

Workload patterns

Strangler fig for monoliths: - Route specific endpoints to new microservices - Gradually carve out - Decommission old monolith piece-by-piece

Database extraction: - Replicate data to new schema/store - Dual-write during transition - Cut reads; cut writes

Metrics tracked

Metric Notes
modernization.workloads.containerized Cumulative
modernization.workloads.self-hosted-db-migrated To managed DBs
modernization.deploy_frequency Pre-engagement vs post
modernization.lead_time Code commit → prod
modernization.mttr Mean time to recover

Knowledge transfer

Critical for sustainability: - Customer engineers paired with CD on every workstream - Documentation co-authored - Runbook walkthroughs - Transition checklist before handover

Avoid the "CD did the work; customer team can't operate it" failure mode.

Customer team can't operate after handover

CD did the work, customer feels lost: - Knowledge transfer was checkboxed, not internalized - Extend hypercare to 60-90 days - Optional: ongoing co-management retainer

Prevention: continuous knowledge transfer through the engagement.

Workload doesn't refactor cleanly

Some workloads resist modernization: - Hard dependencies on host (filesystem assumptions, hardware-specific code) - Critical 24/7 with no scheduled maintenance window - License-bound to specific architecture

Options: - Leave on VMs (modernization scope reduced) - Plan re-architecture as separate engagement - Skip the workload entirely

Sprint scope expanding

Each sprint takes longer than planned: - Discovery gaps (dependencies surfacing as work progresses) - Customer team capacity less than estimated - Scope creep (customer adds requirements mid-sprint)

Address in retro; adjust roadmap.

Customer team disengaged

Customer engineers attending but not contributing: - Re-affirm engagement model (co-build, not delegate) - Surface to customer leadership - May need re-staffing on customer side

Engagement value reduces if customer team isn't growing capability.

Architecture decisions disputed

CD recommends approach X, customer wants Y: - Architecture review with senior CD architect - Document trade-offs - Customer decides; CD implements

Modernization often surfaces fundamental architecture decisions; healthy disagreement expected.

Post-modernization regression

Workload performs worse after modernization: - Microservices added latency - New stack less efficient than old - Observability gaps masking issues

Profile, tune, sometimes revert specific components.