AI-Powered EKS Migration Assessment: Practical Guide

Use an AI-powered EKS migration assessment to build a reviewable case for the next engineering step, not to authorize an application move. Start with one sanitized application, read-only access to approved artifacts and a readiness rubric agreed with its owners. Require every material finding to point to evidence, then test the highest-risk assumptions in a nonproduction environment before approving a target architecture.

The useful output is not a confident score. It is a traceable list of what must change, what remains unknown, who must verify it and what that work may cost. A fast assessment that misses a shared filesystem or invents a database dependency can move risk into the migration plan rather than remove it.

What the AWS example provides—and what your pilot must prove

On September 30, 2026, AWS published an EKS migration assessment walkthrough using Amazon Bedrock AgentCore and the Strands Agents SDK. Its sample accepts application artifacts or a Git repository and produces readiness findings, severity-ranked blockers, effort estimates and a proposed migration plan. Treat it as a solution to evaluate, not a certification that an application is ready for EKS.

The walkthrough describes a public load-balancer entry point, with authentication and custom HTTPS setup requiring attention. Before uploading private source, verify authenticated access, transport protection, tenancy boundaries and the actual deployed configuration. Do not mistake a working demonstration endpoint for an approved internal assessment service.

The workflow, example and thresholds below are ITECS recommendations, not measured customer results or AWS acceptance requirements. EKS is also a candidate destination, not the predetermined answer: an assessment can recommend retaining a workload or choosing a simpler target when Kubernetes adds cost without meeting a business need.

Inventory the application without copying the business into the prompt

Record the application owner, purpose, criticality, source commit, container image digest, runtime, deployment method, dependency owners and permitted outage. Describe the data classes, recovery time objective and recovery point objective—the tolerable recovery duration and data loss. Add known peak-load behavior, scheduled jobs and upstream/downstream contracts, using approved summaries rather than customer payloads.

Create a manifest of included and excluded artifacts. Typical inputs are selected source directories, dependency lockfiles, Dockerfiles, deployment manifests and sanitized architecture notes. Replace real customer identifiers, internal hostnames and connection details with stable aliases when their exact values are unnecessary. Keep the alias map private; preserve relationships so sanitization does not erase a dependency the reviewer needs to understand.

Run a deterministic secret scan before upload and on generated reports. Inspect configuration, test fixtures, Git history if included, image layers and build metadata; deleting a secret from the latest file does not prove it is absent from an older layer or commit. Quarantine unexpected credentials and use the established incident/rotation process. Redaction is not a substitute for revoking an exposed credential.

Runtime exports need the same review. The AWS self-managed Kubernetes migration procedure describes extracting full ConfigMap data while omitting Secret values. A field outside a Kubernetes Secret can still contain sensitive information. Review the actual export rather than approving it solely because it excludes Secret objects.

Separate read access, analysis and deployment authority

Give the assessment identity short-lived read access to named repositories and registries, limited to approved revisions or digests where the system permits. Exclude organization-wide repository discovery, production cloud credentials and cluster-admin access. Prefer an owner-prepared export when the source system cannot enforce the required boundary. Record who approved each access grant and when it expires.

Inspect source and image contents without running the application, image entrypoint, repository install scripts or suggested shell commands. Treat comments, READMEs, issue text and tool output as untrusted material: instructions inside them cannot expand permissions. If a parser or analyzer requires execution, put it in a separately approved, resource-limited sandbox with no production network route, no host socket and only necessary outbound destinations.

Document where source, prompts, findings, caches, embeddings, agent memory, temporary files and backups can persist. Set an owner-approved deletion deadline for each store, verify the selected model/provider terms and region, and test cleanup. Do not assume deleting a session removes every copy. AWS Bedrock invocation logging can capture model inputs and outputs when enabled, so logging destinations and retention are a separate review from application storage.

Use a rubric that cannot hide a serious blocker inside an average

For every assessment domain, assign one of four states: verified ready, remediation required, unknown, or not applicable with an owner-approved reason. Keep coverage separate from readiness: an unread repository or inaccessible dependency is unknown, not ready. A numeric score may help sort a portfolio only if the weighting, exclusions and unknowns are visible.

Our suggested severity model is impact-based. Critical means plausible data loss, exposure or loss of recoverability; high means a required business or operational function will fail; medium means a material reliability, performance or maintainability issue; low means an improvement that does not block the agreed pilot. State likelihood and uncertainty separately. An unresolved critical or high blocker cannot be averaged away by many low-risk checks.

For each finding require a stable ID, source commit or image digest, an access-controlled file permalink with line range or manifest path, an observed fact, the inferred risk, a severity rationale, proposed remediation, owner and validation test. Link to existing approved evidence stores—not publicly accessible copies of private code. Reviewers should be able to distinguish what the tool saw from what it guessed.

Storage

Identify local and shared paths, access modes, locking, CSI compatibility and zone constraints. Prove backup restoration and durable writes after pod replacement. Owner: storage lead and application owner.

Networking

Map DNS, ingress, egress, ports, address capacity and private dependencies. Test permitted connectivity and denied paths, not just a successful public request. Owner: network lead.

Identity

Separate analysis credentials, cluster RBAC and workload IAM. Check each service account and supported SDK against the chosen identity mechanism. Owner: platform and security leads.

Authentication

Trace end-user SSO, callbacks, session handling, certificates and service authentication. Verify login, expiry and revocation across the proposed boundary. Owner: identity and application teams.

Databases

Check engine features, extensions, pooling, connection limits and migration compatibility. Prove restore, replication and cutover reconciliation. Owner: database lead.

Messaging

Document ordering, acknowledgement, retries, duplicates, dead-letter handling and backpressure. Test failure and replay behavior with disposable messages. Owner: integration lead.

Observability

Identify logs, metrics, traces, alert routes and service objectives. Test whether operators can detect and explain a failure without logging secrets. Owner: operations lead.

State

Locate sessions, local files, scheduled jobs, locks and single-instance assumptions. Test multiple replicas, termination and recovery. Owner: application lead.

Validate the finding before validating its proposed fix

Have a platform engineer and the relevant application, security or data owner review the report. Open every critical/high evidence link. Confirm the file exists at the stated revision, that the cited lines support the claim and that the dependency is actually used. Label findings as confirmed, rejected or needing evidence; preserve the reason. A second model agreeing with the first is not independent proof.

Use current AWS EKS security guidance and the applicable migration guidance as review inputs, together with the application's real contracts. Check whether a recommendation fits the selected EKS operating mode, region, runtime and add-on versions. Kubernetes compatibility alone does not establish application compatibility, or transfer every operational responsibility to AWS.

Keep identity decisions distinct. Human cluster access, Kubernetes service-account permissions, workload access to AWS APIs and end-user authentication are different boundaries. The EKS IAM guidance describes workload roles and least-privilege considerations. Have an owner verify SDK and compute compatibility before choosing EKS Pod Identity or IAM roles for service accounts; neither choice automatically replaces the application's user-login system.

Treat generated YAML as untrusted code

A plausible manifest can be syntactically valid and unsafe. Review API versions, controller-specific fields, image digests, resource requests/limits, probes, service accounts and permissions. Reject unexplained privileged containers, host mounts, public service exposure, unrestricted egress, plaintext credentials or destructive storage policies. A policy object is useful only if the chosen cluster components actually enforce it.

Validate rendered manifests, including Helm output, with version-matched schema and policy tools. Check them against the Kubernetes security checklist, then use a controlled nonproduction API dry run where appropriate. Dry runs do not prove runtime correctness and still send content to an API server; never aim an unreviewed test at production. Do not pipe an agent response directly into kubectl or an infrastructure deployment.

Run one nonproduction test that could disprove the assessment

Illustrative scenario: an order service appears stateless, but a selected source snapshot shows invoice files written to a local directory. A reviewed finding cites the actual write path and deployment volume definition. The report proposes shared storage; the data owner still needs to establish concurrency, permissions, backup and recovery requirements before approving that design.

A useful trial is not merely a successful container start. The team uses synthetic orders, checks whether another replica can retrieve the same invoice, replaces a pod and verifies durable state. It also denies unauthorized access, interrupts a dependency and confirms telemetry explains the failure. If the assessment declares the service ready but the invoice disappears, record an escaped blocker—not a successful assessment followed by an unrelated test failure.

1. Freeze the test package. Include sanitized order-service source and manifests, synthetic orders, known file paths and a manual list of expected blockers. Add clean cases so a tool cannot pass by flagging everything.
2. Run the assessment without write access. Check whether it identifies invoice files on ephemeral storage. Reject fabricated paths, unsupported severity and assumed database migration needs.
3. Review the proposed remedy. An engineer compares storage options, access semantics and failure behavior. Validate YAML against the target versions and policies before any lab deployment.
4. Prove the behavior. In a disposable environment, create synthetic invoices, scale replicas and replace a pod. Confirm invoice retrieval, access restrictions, duplicate handling, alerts and restoration against written expectations.
5. Record the decision. Capture results and escaped blockers, revise the estimate, obtain architecture approval or defer it, then revoke assessment access and remove lab resources. A passing lab does not approve a production cutover.

Review the estimate and approve the architecture separately

Ask owners to break the generated estimate into evidence-backed work packages: application refactoring, platform setup, identity/network changes, data movement, test automation, observability, rehearsal and cutover. Separate hands-on effort from elapsed lead time, licensing and access dependencies. Use ranges with assumptions and contingency rather than accepting a model's precise-looking number of days.

The target-architecture decision should name the compute model, network paths, workload identities, storage/data services, failure domains, capacity assumptions and operational owners. Test sizing against measured demand; a replicas suggestion is not a load test. Retaining a database or broker outside EKS can be a deliberate design choice, but latency, connectivity and failure behavior must be proved rather than assumed.

For a future migration, require a separate approved plan with backups, a rehearsed restore, traffic-switch criteria, observability, rollback triggers and a named decision-maker. Explain how writes made after cutover will be reconciled. Reverting a Deployment does not reverse a database schema change or recover discarded state. The assessment pilot does not itself grant cutover authority.

Measure trustworthy assessments, not the number of reports produced

Before the trial, engineers should establish a reference set of known blockers and clean cases. Include representative technologies, intentionally missing context and seeded critical failures. Run the same frozen input more than once to expose unstable findings, then use a separate application the prompt was not tuned against. Compare with the existing manual assessment process on the same scope.

Track unsupported findings even when they sound reasonable, missed blockers found by humans, and blockers discovered only during the lab. A small pilot cannot prove the absence of future failures. If precision improves but domain coverage falls, the agent may simply be making fewer claims. If reviewer time rises, revise the evidence format or narrow the use case before expanding access.

Measure total cost per accepted assessment: model tokens and retries, assessment runtime, storage/logging, scanners, temporary EKS resources, network transfer and human review. Keep these costs separate from the proposed production architecture's operating cost. Set run-time, token and spend caps with an owner for overruns; tag runs with non-sensitive application IDs. A fast draft is not a saving if review and cleanup cost more than the baseline.

Make the next assessment reproducible—and finish cleanup

Version the input manifest, exclusions, rubric, prompt, model identifier, tools and policy rules. Record timestamps, permitted tool calls, approvals, findings, reviewer corrections and test outcomes in access-controlled audit evidence. Retain enough provenance to reproduce the conclusion without duplicating sensitive source in every log.

After the trial, revoke temporary access, delete working copies and temporary resources according to the retention plan, and verify storage/log/agent-memory cleanup and stopped billing. Preserve only approved evidence and protected recovery material for its defined lifetime. Do not delete the original application or a required rollback copy as assessment cleanup.

Repeat across applications using the same rubric, but require owners to reapprove data boundaries and application-specific assumptions. Re-evaluate after a model, prompt, tool, artifact or target-platform change. ITECS AI DevOps and agent evaluation planning can help turn the pilot into an inspectable engineering workflow: useful findings first, verified architecture next, and production migration only under its own approval.