Every application migration eventually reaches the same question: where should this workload run once it leaves the data center or the old platform? For most modern migrations, the realistic options are a Kubernetes cluster, a managed container service or a serverless platform. Teams often treat the choice as a matter of taste, so one group standardizes on Kubernetes for everything while another declares a serverless-first strategy. Both approaches leave value on the table. In 2026 the decision is also more nuanced than it used to be, because cloud providers have blurred the boundaries: serverless functions can now run long workflows and sit on dedicated instances, and container platforms increasingly scale to zero. This guide offers a practical framework for choosing a target platform per application, based on workload characteristics, team capabilities, cost profile and migration strategy.
Start with the Migration Strategy, Not the Platform
The target platform depends on how much you intend to change the application. AWS Prescriptive Guidance describes seven common migration strategies, often called the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor or re-architect. For large migrations, AWS recommends favoring rehosting, relocating, replatforming or retiring where possible, and modernizing after the move, because refactoring is the most complex and costly option.
That guidance has a direct implication for the containers versus serverless debate:
- Rehost usually means virtual machines. Neither containers nor serverless apply until a later modernization step.
- Replatform is where containers shine. Packaging an existing application into a container image and running it on a managed container service often requires modest code changes, such as externalizing configuration and session state.
- Refactor is where serverless becomes realistic. Breaking an application into event-driven functions and managed services typically means significant redesign.
- Repurchase moves the capability to SaaS, removing the platform question entirely for that workload.
- Retire is always the cheapest platform. Migration discovery regularly finds applications nobody uses.
Deciding the strategy first prevents a common mistake: forcing a large legacy application into functions during a time-boxed migration, or conversely, wrapping a naturally event-driven integration in a container that runs idle most of the day.
The Platform Options in 2026
Each major cloud offers a similar spectrum, from maximum control to maximum abstraction.
Managed Kubernetes
Services such as Amazon EKS, Azure Kubernetes Service and Google Kubernetes Engine provide a managed control plane and a consistent, portable API. Kubernetes offers the most flexibility: custom networking, service meshes, operators for stateful software, GPU scheduling and a vast ecosystem. The cost is operational: cluster upgrades, add-on lifecycle management, capacity planning and security hardening. AWS’s container decision guide is explicit that Kubernetes requires investment in DevOps and SRE skills, and that smaller teams may prefer more managed options.
Managed Container Services
Services such as Amazon ECS with AWS Fargate, Azure Container Apps and Google Cloud Run run containers without exposing cluster management. Developers provide an image and a few settings; the platform handles placement, scaling and load balancing. Several of these services can scale to zero for request-driven workloads, which narrows the cost gap with functions. You give up some flexibility, such as deep network customization or running arbitrary operators, in exchange for far less operational work.
Functions and Serverless Platforms
Functions as a service, such as AWS Lambda, Azure Functions and Google Cloud Run functions, run code in response to events with per-invocation billing and automatic scaling. Combined with managed queues, event buses, API gateways and databases, they allow teams to build applications with almost no infrastructure to manage. Historically, the constraints were cold starts, execution time limits, limited control over the runtime environment and awkward handling of long-running workflows.
The New Hybrids
Recent launches show how much the boundaries have moved. AWS Lambda Managed Instances lets Lambda functions run on current-generation EC2 instances in your account, with AWS handling provisioning, patching and scaling. AWS documents it as suited to high-volume, predictable workloads and performance-sensitive applications, priced as EC2 capacity plus a management fee, with support for EC2 savings plans on the compute portion. Execution environments can handle multiple concurrent invocations, and scaling is based on CPU utilization without cold starts, though environments scale to a minimum rather than to zero. Separately, Lambda durable functions allow a single execution to span up to a year, using checkpoints and replay so that workflows survive interruptions and pause without compute charges during waits. Together, these features remove two classic objections to serverless: unpredictable cost at sustained volume and the inability to run long-lived processes.
Decision Criteria That Actually Matter
Rather than starting from a preference, evaluate each application against a small set of criteria. AWS’s container guidance lists operational overhead, workload characteristics, portability, organization size and skills, and ease of deployment. In practice, six questions settle most decisions:
- What is the traffic shape? Spiky, intermittent or event-driven traffic favors serverless and scale-to-zero containers. Steady, high-volume traffic favors containers on reserved or committed capacity, or hybrids such as functions on managed instances.
- How long does work run? Request-response APIs fit everywhere. Long-running background processing, streaming consumers and stateful services fit containers better, although durable function models now cover many multi-step workflows.
- How much runtime control is needed? Custom binaries, specific operating system packages, sidecars, GPUs or specialized networking point toward containers, and often Kubernetes.
- How portable must the workload be? If multi-cloud or on-premises deployment is a hard requirement, standard container images and Kubernetes manifests travel better than code tightly coupled to one provider’s event sources.
- What can the team operate? A small team without platform engineers will struggle to run Kubernetes well. A large organization with an established internal platform may get more value from consolidating on it.
- What does it cost at realistic volume? Model costs at current and projected traffic, including data transfer, observability and the people needed to operate the platform, not just compute.
Choose the platform per workload, not per organization. A portfolio with a few well-chosen platforms, each used where it fits, will beat any single-platform dogma on cost, speed and reliability.
A Practical Decision Matrix
The following heuristics summarize how these criteria typically play out for workloads encountered in migration programs:
- Web applications and APIs being replatformed: managed container services are usually the best first target. They accept existing code with minimal change and offer autoscaling and simple deployment.
- Event-driven integrations, file processing and scheduled jobs: functions are often ideal, because the work is intermittent and naturally triggered by events or schedules.
- Multi-step business workflows such as order processing or approvals: durable functions or a workflow service like AWS Step Functions, with business logic in functions or containers.
- High-throughput, steady services: containers on committed capacity, or functions on managed instances if the team prefers the serverless programming model.
- Platforms with many services, custom networking or stateful components: Kubernetes, ideally operated by a platform team that provides golden paths to application teams.
- Machine learning inference and GPU workloads: Kubernetes or specialized managed inference services, depending on scale and control requirements.
- Legacy applications with heavy OS dependencies: rehost on virtual machines first, then containerize when the application is stable in the cloud.
Cost: Avoid the Two Classic Traps
Cost comparisons between containers and serverless are often misleading because they compare unit prices rather than total cost. Two traps are especially common.
The first trap is assuming serverless is always cheaper. Per-invocation billing is excellent for intermittent workloads, but for steady, high-volume traffic, always-on containers on committed capacity can cost less. This is precisely the gap that options like Lambda Managed Instances aim to close, by letting teams keep the function programming model while paying instance-based prices.
The second trap is ignoring people costs. A Kubernetes cluster might appear cheaper per CPU hour, but it requires engineers to upgrade clusters, manage add-ons, patch nodes and respond to incidents. For a small number of services, those labor costs can exceed any infrastructure savings. Conversely, at large scale with an established platform team, Kubernetes amortizes well across many workloads.
Build a simple model for each candidate workload: compute and request costs at realistic volume, managed service fees, networking and data transfer, observability, and an estimate of operational effort. Revisit it after a few months in production, when real usage data replaces assumptions.
Security, Observability and Operations
Platform choice also changes how you secure and operate applications. With Kubernetes, your team owns a large share of the security surface: node hardening, network policies, admission control, secrets handling, image provenance and timely upgrades. Managed container services shift node patching and much of the runtime hardening to the provider, while you remain responsible for images, identities and network exposure. Serverless functions narrow the surface further but multiply the number of deployable units and permissions, so least-privilege identity per function and careful handling of event payloads become central controls.
Observability needs similar care. Containers fit naturally with standard metrics, logs and tracing agents, while serverless applications depend on distributed tracing across functions, queues and managed services to make failures understandable. Whatever the mix, standardize on a common telemetry approach, such as OpenTelemetry, so that teams can follow a request across containers and functions in one view. Define service-level objectives per application before migration and verify them after each wave; they are the most objective way to judge whether a platform choice was right.
Migration Playbook: From Assessment to Production
Applying the framework across a portfolio works best as a structured process:
- Assess and classify. During discovery, record each application’s traffic profile, runtime dependencies, statefulness, integration patterns and business criticality, alongside its chosen migration strategy.
- Define a small platform menu. Agree on two or three supported targets, for example a managed container service, a serverless stack and, if justified, a shared Kubernetes platform. Each target gets templates, pipelines, security baselines and observability defaults.
- Map workloads to targets. Use the decision matrix to propose a target for each application, and have architects review edge cases.
- Prepare applications. For containers, externalize configuration and state, add health checks and make logging go to standard output. For serverless, identify event sources, idempotency requirements and execution limits.
- Migrate in waves. Start with low-risk applications that exercise each target platform, refine templates, then scale.
- Optimize after the move. Revisit platform choices once real usage and cost data are available. Some workloads will move from containers to functions or vice versa, and that is a healthy sign of a learning organization.
Worked Example: A Mixed Portfolio
Consider a hypothetical distribution company migrating about 30 applications from an aging virtualized data center. Discovery shows a mix: a customer portal and several REST APIs written in Java and .NET, a set of nightly file-based integrations with suppliers, an order approval process that can take days, an internal reporting tool used weekly and an old inventory system tightly coupled to a specific operating system version.
The company defines a menu of three targets. The customer portal and APIs are containerized and moved to a managed container service with autoscaling, requiring only configuration and session-handling changes. The supplier integrations become functions triggered by file uploads to object storage, eliminating servers that previously ran idle most of the day. The approval process, previously a polling batch job, is rebuilt as a durable workflow that waits for approvals without consuming compute. The weekly reporting tool moves to a scale-to-zero container. The inventory system is rehosted on virtual machines and scheduled for a later modernization decision, possibly a SaaS replacement. Two rarely used applications are retired.
The company does not run Kubernetes at all in this first phase, because no workload requires it and the team has no platform engineers. That may change if the portfolio grows or if machine learning workloads arrive, but the decision is made on evidence rather than fashion.
Pitfalls to Avoid
- Choosing a single platform for every workload because it simplifies governance on paper.
- Adopting Kubernetes without the platform engineering capacity to run it securely and keep it upgraded.
- Decomposing applications into many functions during a time-boxed migration, turning a migration into an unplanned rewrite.
- Ignoring execution limits, idempotency and retry behavior when moving logic to event-driven functions.
- Comparing compute prices while ignoring data transfer, observability and labor costs.
- Coupling business logic tightly to one provider’s event formats when portability is a stated requirement.
Outlook
Expect convergence to continue. Container services will keep adding serverless traits such as scale to zero and per-request billing, while serverless platforms will keep adding container traits such as dedicated capacity, longer execution and richer runtime control. Durable execution models are becoming mainstream for business workflows and AI agent orchestration alike. The practical skill for architects is therefore less about picking a camp and more about understanding workload characteristics deeply enough to place each one on the platform that fits it best, and revisiting those choices as both the workload and the platforms evolve.
Conclusion
Containers and serverless are not rival philosophies but complementary tools, and in 2026 the distance between them is smaller than ever. Decide the migration strategy first, evaluate each application on traffic shape, run duration, control, portability, team capability and total cost, and offer a small menu of well-supported platforms. Migrate in waves, measure real usage and adjust. That approach delivers the speed of managed services where they fit, the control of containers where it matters and avoids paying for complexity that no workload needs.
How Hanoi Technology Can Help
Hanoi Technology helps organizations assess application portfolios, choose the right container or serverless target for each workload and migrate in well-governed waves.