Modernization | The AWS Blog

AWS Transform makes migration assessments more conversational, but data quality still wins

Emiliano Montesdeoca — Wed, 24 Jun 2026 00:00:00 +0000

Migration assessments are rarely wrong because the spreadsheet formula is hard. They are wrong because the inventory is incomplete, assumptions are stale, and the business case changes every time a stakeholder adds context.

The AWS Migration & Modernization Blog post on accelerating migration assessments and planning with AWS Transform is interesting because it treats assessment as an interactive workflow instead of a static report.

What changed

AWS Transform assessments can ingest inventory data from common discovery sources, generate a TCO business case, recommend AWS targets, and then let teams refine assumptions through chat. The source article shows examples such as adding missing servers, adjusting on-premises costs, modeling non-EC2 services, and exploring what-if scenarios.

That changes the assessment loop. Instead of recollecting data and regenerating a report for every new question, teams can refine the model conversationally.

Why builders should care

Migration planning is full of partial information. A CMDB misses servers. RVTools exports do not capture every cost. Licensing assumptions change. Some workloads are heading to managed services, not EC2. Finance wants a different depreciation model. Application owners remember a dependency late in the process.

An interactive assessment tool can keep momentum when those changes happen. That is valuable during early planning, executive conversations, and portfolio prioritization.

But the output is only as good as the inputs and assumptions.

The trade-offs

Conversational planning can make weak assumptions feel more authoritative than they are. A polished business case is still a model.

Builders and migration leads should keep three things explicit:

Data source quality: where inventory came from, when it was collected, and what is missing.
Assumptions: utilization, licensing, storage growth, network costs, support model, and target services.
Decision status: directional estimate, planning baseline, or approved migration wave.

AWS Transform can help generate and adjust the assessment, but it should not replace stakeholder validation. Application owners, finance, security, and operations still need to review the model.

What to do next

Use AWS Transform early, but label the results honestly. Start with directional estimates, then improve confidence as discovery data gets better.

A practical workflow:

Import existing inventory instead of waiting for perfect data.
Generate a first-pass business case.
Use chat to add known missing costs and workloads.
Review assumptions with finance and platform teams.
Convert high-confidence groups into migration waves.
Reassess after each wave to improve the next one.

The useful takeaway is that migration assessments can become living documents. That is a big improvement over static PDFs, as long as teams keep data quality and assumption ownership visible.

S3 Files makes Lambda file workflows simpler, but not automatically better

Emiliano Montesdeoca — Wed, 24 Jun 2026 00:00:00 +0000

A lot of Lambda code that works with S3 is not complicated because the business logic is complicated. It is complicated because the function has to download an object, manage /tmp, process the file, upload the result, and clean up after itself.

The AWS Compute Blog post on modernizing Lambda and S3 workloads with Amazon S3 Files shows a different model: mount an S3-backed file system and let the function use normal file paths.

That sounds small. For many workloads, it changes the shape of the code.

What changed

S3 Files lets a Lambda function mount an S3 bucket as a file system at a path such as /mnt/data. Code can open, read, write, list, and organize files using filesystem operations while S3 remains the durable backing store.

The source article uses examples such as image processing, ETL pipelines, and multi-agent shared workspaces. In each case, the function moves away from explicit S3 transfer code and toward direct file I/O.

That removes a surprising amount of glue:

no manual download before processing,
no upload step after writing output,
less /tmp capacity management,
fewer cleanup paths for failed invocations,
simpler handoffs between functions that share a workspace.

Why builders should care

The strongest use case is modernization of existing file-oriented libraries. Many image, document, ML, and data-processing libraries expect file paths. Without S3 Files, Lambda code often has to adapt object storage into temporary local files before real work can start.

S3 Files lets builders keep file-based code and still use S3 as the storage layer. That can make Lambda more attractive for workloads that previously moved to containers only because file handling became awkward.

The shared workspace pattern is also interesting for AI agents. If multiple Lambda functions collaborate on a session, a directory tree can be easier to reason about than a collection of object keys and serialized state blobs.

The trade-offs

I would not replace every S3 API call with file I/O.

Object APIs are still excellent when you want explicit object boundaries, event-driven processing, presigned URLs, lifecycle policies, replication, and direct control over metadata. File systems are easier for some code, but they can also hide transfer and consistency behavior behind familiar syntax.

Builders should validate:

throughput for large files,
behavior under high concurrency,
consistency expectations between producers and consumers,
VPC and mount target requirements,
IAM permissions for mount and write operations,
failure behavior when a function exits while writing.

Also remember that simpler code is not the same as simpler operations. If many functions share a writable workspace, you need naming conventions, cleanup policies, and safeguards against accidental overwrite.

What to do next

Look for Lambda functions where more code is spent on S3 transfers than on the actual business logic. Image resizing, report generation, data conversion, document processing, and agent workspaces are good candidates.

For each candidate, compare two versions:

current S3 API flow with /tmp,
S3 Files flow with mounted paths.

Measure duration, memory, error handling complexity, and cost. The winning design may be different per workload.

The useful takeaway is not that file systems are better than object APIs. It is that Lambda now has a cleaner option when the workload is naturally file-shaped.

Lambda runtime upgrades need campaigns, not reminders

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

Lambda runtime upgrades are easy to postpone because the function still works today. Then a deprecation date becomes a support risk, a security exception, or a rushed platform campaign.

The AWS Compute Blog post on upgrading Lambda function runtimes at scale with AWS Transform custom is useful because it treats runtime upgrades as a repeatable modernization workflow, not a calendar reminder.

What changed

AWS Transform custom can analyze codebases, identify runtime upgrade risk, apply transformations, update dependencies or configuration, and validate against exit criteria. The source article focuses on Lambda runtime upgrades, including cases where code changes are required, such as moving callback-style Node.js handlers toward async patterns.

For platform teams, the more important piece is campaign management. A large organization rarely has one repository and one owner. It has hundreds of functions across many accounts, teams, IaC stacks, and CI/CD systems.

Why builders should care

Runtime upgrades fail when ownership is unclear.

An application team may not know a function exists. A platform team may see the deprecated runtime but not understand the deployment path. Security may see the exposure but not own the code. The result is a spreadsheet-driven migration with too many manual exceptions.

A transformation tool can help, but only if it plugs into an operating model:

inventory functions and repositories,
map functions to owners,
assess code and dependency risk,
create pull requests or transformation branches,
validate with tests and alarms,
deploy with safe rollout and rollback,
track completion centrally.

That is a campaign, not a one-off task.

The trade-offs

Automated transformation is not a substitute for test coverage. It increases the value of tests because it can make changes faster than humans can manually review every edge case.

Before trusting a runtime upgrade, teams should check:

unit and integration tests for handler behavior,
dependency compatibility with the target runtime,
infrastructure definitions that set the runtime,
packaging and build pipeline changes,
observability after deployment,
alias or version-based rollback strategy.

For platform teams, the other trade-off is centralization. Pushing changes across many repositories can be efficient, but service owners still need to understand and approve behavior changes. The best model is usually centralized orchestration with distributed ownership.

What to do next

Start with inventory. Use AWS Config, Trusted Advisor, CLI scripts, tags, or deployment metadata to find functions approaching deprecation. Then group them by owner, runtime, business criticality, and test readiness.

For low-risk functions with good tests, an automated transform can move quickly. For high-risk functions with poor tests, the first transformation should probably add documentation, tests, or alarms before changing the runtime.

The lesson from this AWS post is broader than Lambda. Modernization work becomes manageable when it is continuous, visible, and validated. If runtime upgrades are still handled as emergency cleanup, the tooling can help, but the process needs upgrading too.