View a markdown version of this page

Migration lifecycle phases - AWS Prescriptive Guidance

Migration lifecycle phases

Structure your OpenShift to Amazon EKS migration using a phased approach that aligns with standard software development lifecycle (SDLC) practices. Each phase requires specific activities and effort allocation.

The migration lifecycle includes the following phases:

  1. Assessment phase – Discovery, workload inventory, and complexity analysis

  2. Infrastructure setup – Amazon EKS cluster provisioning and AWS service configuration

  3. Application migration – Workload containerization, manifest conversion, and deployment

  4. Security and AWS Identity and Access Management (Amazon IAM) – Policy migration, Role-Based Access Control (RBAC) configuration, and access control implementation

  5. Networking – Network policy translation, ingress configuration, and service mesh setup

  6. Storage – Persistent volume migration and storage class configuration

  7. CI/CD pipeline migration – Build and deployment pipeline reconfiguration for Amazon EKS

  8. Monitoring and logging – Observability implementation with Amazon CloudWatch and related services

  9. Testing – Functional validation, performance testing, and acceptance criteria verification

  10. Cutover and go-live – Production migration execution and post-migration validation

Per-workload effort breakdown

The following sections provide detailed effort estimation guidance for each migration phase on a per-workload basis.

Create a spreadsheet to track effort estimates for each of the following phases.

Assessment and discovery

The assessment phase establishes the foundation for accurate migration planning. Use the following templates to capture essential information during discovery activities. Complete documentation enables informed effort estimation and risk identification.

Task

Base Hours

Your Input

Calculated

(Base hr * Number of resources)

Count total applications

4

No of apps

___ hrs

Document namespaces

2/namespace

No of ns

___ hrs

List deployments/pods

1/app

No of apps

___ hrs

Catalog ConfigMaps

0.5/map

No of maps

___ hrs

Catalog Secrets

0.5/secret

No of secrets

___ hrs

Document PVCs

1/pvc

No of pvcs

___ hrs

Network policies audit

2/policy

No of policies

___ hrs

Routes/Ingress mapping

1/route

No of routes

___ hrs

ImageStreams inventory

0.5/stream

No of streams

___ hrs

BuildConfigs analysis

2/config

No of configs

___ hrs

total

___ hrs

Dependency mapping

Task

Hours

Complexity Factor

Notes

Inter-service dependencies

4 per 10 apps

Low=1x, Med=1.5x, High=2.5x

External service integrations

3 per integration

Database connections

4 per database

Message queue connections

3 per queue

Third-party API integrations

2 per API

Shared storage dependencies

4 per share

Infrastructure build-out

In some organizations, platform teams manage Amazon EKS cluster provisioning and infrastructure configuration independently from application migration activities. If your platform team handles infrastructure setup outside the migration project scope, exclude the cluster setup estimates provided in this section from your overall effort calculation.

EKS cluster setup(optional)

Component

Simple

Standard

Production

Total Hours

(Number * Hr)

Amazon Virtual Private Cloud (Amazon VPC) design

8

16

32

Amazon EKS cluster creation

4

8

16

Node groups config

4

12

24

Amazon IAM roles/policies

8

24

48

Security groups

4

12

24

Elastic Load balancer setup

4

8

16

DNS configuration

2

4

8

AWS Certificate Management

4

8

16

Cluster Autoscaler

4

8

16

Karpenter (if used)

0

12

24

Supporting infrastructure setup

The following estimates apply when the listed infrastructure components are required for your migration. Include these effort allocations in your overall project estimate based on your specific infrastructure requirements.

Component

Hours

Applicable?

Total Hours(if Y then calculate Hr)

Amazon Elastic Container Registry (Amazon ECR) Repository setup

8

Y/N

AWS Transit gateway (hybrid)

24

Y/N

Direct connect config

40

Y/N

VPN configuration

16

Y/N

PrivateLink setup

12 per endpoint

Y/N

Amazon S3 Buckets (logs/backups)

4

Y/N

AWS KMS Key setup

8

Y/N

AWS Secrets manager setup

8

Y/N

AWS Systems Manager (SSM) Parameter store migration

4 + (0.25 × params)

Y/N

Application migration

Per-application effort matrix

The following estimates correspond to the workload complexity tiers (t-shirt sizes) established during the discovery phase. Apply these effort ranges based on each application's assigned complexity category.

App Type

Count

Hours/App

Total Hours

Stateless - Simple (no deps)

___

8

Stateless - Standard

___

16

Stateless - Complex (many deps)

___

32

Stateful - Simple

___

24

Stateful - Standard

___

48

Stateful - Complex

___

80

Legacy/Monolith

___

120

Custom Operators

___

60

OpenShift-specific conversions

Item

Count

Hours Each

Total

Route → Ingress conversion

___

2

DeploymentConfig → Deployment

___

3

BuildConfig → Pipeline

___

8

ImageStream → ECR migration

___

2

SCC → PSP/PSS migration

___

6

OpenShift Templates → Helm

___

12

oc commands → kubectl scripts

___

4

OAuth config migration

1

16

Storage migration

Persistent volume migration

Storage migration is a critical prerequisite for stateful application migrations. Complete storage class configuration, persistent volume provisioning, and data migration activities before migrating applications that depend on persistent storage.

Storage Type

Volume Count

Size (GB)

Hours formula

Total hours

Block (gp2/gp3)

___

___

2 + (0.01 × GB) per vol

Amazon EFS/NFS shared

___

___

8 + (0.02 × GB) per vol

Database (Amazon RDS migration)

___

___

16 + (0.05 × GB) per db

Object (S3)

___

___

4 + (0.001 × GB)

Storage class mapping

Task

Hours

Analyze current storage classes

4

Design Amazon EKS storage class mapping

8

Amazon EBS CSI driver setup

4

Amazon EFS CSI driver setup (if needed)

8

Test storage performance

16

Data validation procedures

8

Security and compliance

Security and compliance requirements are critical considerations for every organization. Carefully evaluate security controls, access policies, and regulatory requirements during migration planning.

Recommended approach: Engage security and compliance teams early in the planning process. Their involvement ensures that IAM policies, network security controls, encryption requirements, and audit logging configurations align with organizational security standards and regulatory obligations.

Identity & access

Task

Base

Complexity

Total Hours

Role-Based Access Control (RBAC)mapping analysis

16

Role/ClusterRole conversion

2 per role

Service account migration

1 per SA

IAM Roles for Service Accounts (IRSA) configuration

4 per app

OpenID Connect (OIDC) provider setup

8

AD/LDAP integration

24-40

SSO reconfiguration

16-32

Security Policies

Task

Hours

Security Context Constraints (SCC) → Pod Security standards mapping

16

Network policy conversion

2 per policy

Open Policy Agent (OPA)/Gatekeeper policies

4 per policy

Image scanning setup (Amazon ECR)

8

Secrets encryption config

8

Audit logging setup

12

Compliance documentation

24-40

CI/CD pipeline migration

Most organizations have existing CI/CD pipelines that require reconfiguration to deploy applications to Amazon EKS. The following estimates cover integration effort for common CI/CD platforms and deployment workflow updates.

Refer to the following table to estimate effort based on your tooling.

Pipeline Conversion

Source pipeline type

Count

Target

Hours Each

Total

OpenShift pipelines

___

Same Openshift

8

OpenShift pipelines

___

AWS CodePipeline

16

Jenkins (on OpenShift)

___

Jenkins (EKS)

12

Jenkins (on OpenShift)

___

AWS CodePipeline

24

Custom buildConfigs

___

CodeBuild

16

GitLab CI

___

GitLab CI (reconfig)

6

GitHub Actions

___

GitHub Actions (reconfig)

4

Registry migration

Task

Hours

Amazon ECR setup & organization

8

Image migration script development

16

Image migration execution

2 + (0.1 × image count)

Image signing setup

12

Pull secret configuration

4

Lifecycle policies

4

Observability stack

Organizations approach observability implementation in different ways. Some have existing monitoring stacks that require integration with Amazon EKS, while others need to establish observability infrastructure from the ground up. Use the following effort estimates based on your organization's current observability maturity.

Monitoring

Current → Target

Hours

Prometheus (keep) → Prometheus (EKS)

24

Prometheus → Amazon Managed Prometheus

32

Prometheus → CloudWatch Container Insights

40

Grafana (keep) → Grafana (EKS)

16

Grafana → Amazon Managed Grafana

24

Dashboard migration

2 per dashboard

Alert rules migration

1 per rule

Custom metrics validation

4 per app

Logging

Current → Target

Hours

EFK → EFK on Amazon EKS

24

EFK → Amazon OpenSearch

32

EFK → CloudWatch Logs

24

Fluentd/Fluent Bit config

16

Log parsing rules migration

8

Retention policy config

4

Implementing comprehensive observability requires effort beyond basic infrastructure setup. The estimates below reflect the work required to configure monitoring dashboards, centralized logging, and alerting systems for your migrated applications.

Testing and validation

Testing effort

Test Type

Base Hours

Per App Factor

Your Hours

Unit test validation

8

+1 per app

Integration testing

24

+2 per app

Performance baseline

16

+4 per critical app

Performance validation

24

+4 per critical app

Security scanning

16

+1 per app

DR/Failover testing

24

+4 per critical app

User Acceptance Testing (UAT)coordination

40

fixed

Regression testing

16

+2 per app

Documentation and training

Documentation is an essential component of migration activities. Comprehensive documentation supports operational readiness, knowledge transfer, and long-term platform maintainability.

Deliverable

Hours

Architecture documentation

24-40

Runbook creation

4 per app

Incident response procedures

16

Admin training (per person)

8 people

Developer training (per person)

4 people

Knowledge transfer sessions

16

Project management and coordination

Activity

Formula

Project management

15% of total technical hours

Stakeholder meetings

4 hrs/week weeks

Change management

8% of total technical hours

Risk management

4% of total technical hours

Vendor coordination

8 hrs/week weeks

Executive summary

Use the following summary table to consolidate effort estimates from each migration phase. This provides a comprehensive view of total project effort based on your specific requirements and workload complexity.

Technical hours summary

Section

Hours

1. Assessment & discovery

2. Infrastructure build-out

3. Application migration

4. Storage migration

5. Security & compliance

6. CI/CD pipeline migration

7. Observability stack

8. Testing & validation

9. Documentation & training

Technical subtotal

Adjustment factor (section 3.3)

×1

Adjusted technical total

Add below Project Management effort as part of the migration effort.

Category

Calculation

Hours

Technical (adjusted)

from above

Project Management (15%)

Meetings

Change Management (8%)

Risk Buffer (10-20%)

Grand Total

COST ESTIMATION (Optional)

Organizations often require cost projections for migration activities to support budget planning and approval processes. Use the following template to translate effort estimates into financial projections based on your team composition and resource rates.

Role

Rate/Hr

Hours

Cost

Solution architect

$___

Platform engineer

$___

DevOps engineer

$___

Security engineer

$___

QA engineer

$___

Project manager

$___

Total labor

Additional Costs

Item

Monthly

Months

Total

Parallel environment

$___

___

Migration tools

$___

___

Training/certification

Contingency (15%)

Notes and assumptions

  1. Estimates assume team has basic Kubernetes experience

  2. Add 30-50% if team is new to EKS

  3. Add 20% if strict compliance requirements (PCI, HIPAA)

  4. Subtract 20% if using Infrastructure as Code already

  5. All hours are person-hours, not elapsed time

  6. Does not include AWS infrastructure costs

  7. Assumes standard business hours availability