Every engineering leader facing a cloud migration eventually confronts the same uncomfortable question: do we move fast and recreate our existing problems in new infrastructure, or do we embark on a multi-year transformation project that may never actually finish?
This is a false choice. The reality is that migration represents a unique window of opportunity—a moment when you're already touching every application, already investing in infrastructure change, and already have organizational momentum behind modernization. The question isn't whether to modernize during migration. It's how much modernization you can strategically accomplish without derailing the migration itself.
After working with teams migrating everything from decade-old monoliths to sprawling microservices architectures, I've seen a consistent pattern: organizations that treat migration as pure relocation end up disappointed. They pay cloud prices for on-premises architecture. They miss optimization opportunities that were staring them in the face. And often, they amplify technical debt by cementing legacy patterns into new infrastructure. But organizations that approach migration as strategic replatforming—containerization with targeted improvements—consistently report better outcomes with only marginally more effort.
Before diving into strategy, let's establish a common vocabulary. The migration spectrum ranges from minimal change to complete transformation:
Rehost (Lift-and-Shift): Move applications to new infrastructure with virtually no code changes. Your VM becomes a cloud VM. Your bare-metal server becomes an EC2 instance. The application remains identical; only the underlying hardware changes.
Replatform (Lift-and-Reshape): Containerize applications and adopt cloud-native operational patterns while preserving core application logic. You're changing how the application runs and is deployed without rewriting business logic.
Refactor: Make significant code changes to better leverage cloud capabilities. This might involve breaking apart a monolith, adopting managed services, or restructuring data access patterns.
Rebuild: Rewrite the application from scratch using cloud-native architectures and modern frameworks. The business requirements remain; the implementation is entirely new.
Lift-and-shift is seductive because it promises speed. "We'll migrate first, then optimize later." In practice, later rarely comes. Once an application is running in the cloud—even inefficiently—organizational attention moves elsewhere. The "optimize later" backlog grows indefinitely.
More critically, pure lift-and-shift often amplifies existing problems rather than solving them. Consider what happens when you move a VM-based deployment to the cloud without modernization:
Cost inefficiency becomes structural. On-premises servers are sunk costs—you've already paid for them. Cloud resources are ongoing expenses. An oversized, always-on VM that was "free" in your data center now generates monthly bills. The inefficiencies that were invisible become line items.
Operational burden transfers intact. If deployments required SSH access and manual configuration before, they still require SSH access and manual configuration. You haven't gained cloud-native operational benefits; you've just changed where your manual processes execute.
Technical debt gets locked in. Moving an application without addressing its dependencies, configuration patterns, or architectural issues means those issues are now part of your cloud infrastructure. Future improvements become harder because you've built new tooling around legacy patterns.
The numbers tell the story. Organizations that pursue pure lift-and-shift typically see 15-25% higher cloud costs than expected, primarily due to over-provisioned resources and inefficient architectures that weren't designed for cloud pricing models. Meanwhile, those that invest in strategic replatforming during migration often achieve 20-40% cost savings compared to their original on-premises spend—while gaining operational improvements that compound over time.
Strategic replatforming occupies the middle ground between "change nothing" and "change everything." The core insight is that containerization itself—the act of packaging an application into a Docker container and defining its deployment through a manifest—provides natural leverage points for modernization without requiring application rewrites.
When you containerize an application, you're already making decisions about how it builds, what it needs at runtime, how it receives configuration, and how it logs. Each of these decisions is an opportunity to improve. The marginal effort to do them well versus doing them poorly is small, but the cumulative benefit is substantial.
Platforms like Convox are designed precisely for this approach. The convox.yml manifest provides a declarative way to define applications that naturally encourages cloud-native patterns. Rather than fighting against modernization, the platform makes good practices the path of least resistance.
Let's examine five practical modernization patterns you can apply during migration. Each delivers immediate value while preparing applications for future improvements.
The most basic lift-and-shift containerization often produces bloated, inefficient images. A naive Dockerfile might copy everything, install everything, and result in 2GB images that take minutes to pull. Strategic containerization produces lean, secure, fast-deploying images.
Before: A single-stage Dockerfile that includes build tools, test frameworks, and development dependencies in the production image.
After: A multi-stage build that separates compilation from runtime, resulting in minimal production images.
# Multi-stage build for a Node.js application
FROM node:18 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
FROM node:18-slim AS production
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY . .
USER node
CMD ["node", "server.js"]This pattern typically reduces image sizes by 60-80% and improves security by excluding build toolchains from production environments. Smaller images mean faster deployments, reduced registry storage costs, and smaller attack surfaces.
The Convox Dockerfile documentation provides additional guidance on optimizing builds for the platform.
Legacy applications often embed configuration in files, require config changes for different environments, or mix secrets with code. This pattern separates configuration from code, enabling the same container image to run in any environment—a core principle of the twelve-factor app methodology.
Before: Configuration files baked into images, environment-specific builds, secrets in version control.
After: Configuration injected via environment variables, single image per build, secrets managed externally.
environment:
- DATABASE_URL
- REDIS_URL
- SECRET_KEY_BASE
- LOG_LEVEL=info
services:
web:
build: .
port: 3000
environment:
- DATABASE_URL
- REDIS_URL
- SECRET_KEY_BASE
- LOG_LEVELWith Convox, environment variables are managed through convox env set and automatically injected into containers at runtime. This separation means you deploy the same tested image from staging to production—only the configuration changes.
The environment variables documentation covers advanced patterns including interpolation and release-based environment management.
Legacy applications often have minimal logging, inconsistent log formats, and no metrics endpoints. Migration is the perfect time to inject observability because you're already changing how the application runs.
Before: Unstructured logs written to files, no metrics, debugging via SSH.
After: Structured JSON logs to stdout, health endpoints, metrics available for collection.
services:
web:
build: .
port: 3000
health:
path: /health
interval: 10
timeout: 5
grace: 30Convox automatically captures stdout and stderr from containers, making them available through convox logs and integrable with external logging services via the syslog parameter. The platform also supports integration with monitoring solutions like Datadog for metrics and distributed tracing.
The investment in observability during migration pays dividends immediately. Teams report 50-70% faster incident resolution when structured logging and health checks are in place from day one.
Migration forces you to explicitly define your runtime environment. This is the ideal moment to update dependencies that have been languishing. If your application runs on Node 12 or Python 2.7, containerization requires you to specify that runtime—why not specify a supported version instead?
Before: EOL runtimes, outdated framework versions, vulnerable dependencies.
After: Current LTS runtimes, updated frameworks, addressed CVEs.
This doesn't mean rewriting the application. Most runtime upgrades require only minor adjustments. The key is doing this work during migration when you're already testing thoroughly, rather than as a separate project later.
For applications with private dependencies, Convox's private registry support allows you to pull base images and packages from authenticated sources during builds.
A practical approach: update to the latest LTS runtime, update your web framework to a supported version, and run automated security scanning on dependencies. This typically takes 1-3 days of developer time and eliminates entire categories of vulnerabilities.
Legacy applications often store state in local filesystems—session data, uploaded files, cached computations, temporary files. This works when you have a single server; it fails in a containerized environment where instances are ephemeral and horizontally scaled.
Before: Local session storage, filesystem-based uploads, in-memory caches.
After: External session stores, object storage for files, distributed caching.
resources:
database:
type: postgres
cache:
type: redis
services:
web:
build: .
port: 3000
resources:
- database
- cache
scale:
count: 2-10
targets:
cpu: 70Convox's resource linking automatically injects connection strings as environment variables, making it straightforward to configure applications to use external state stores. Redis becomes your session store; S3 or cloud storage handles uploaded files.
Statelessness enables horizontal scaling—the autoscaling configuration shown above only works correctly when any instance can handle any request. This pattern is essential for achieving cloud elasticity and is much easier to implement during initial containerization than to retrofit later.
Not all applications should migrate at the same time or receive the same level of modernization investment. A thoughtful sequencing strategy maximizes learning while minimizing risk.
Wave 1: Low-risk applications with clear boundaries. Start with applications that have minimal dependencies, limited traffic, and lower business criticality. Internal tools, admin interfaces, and batch processing jobs are ideal candidates. These migrations build team expertise and validate your platform choices without existential risk.
Wave 2: Stateless web applications. Once the team has migrated several applications successfully, move to customer-facing but stateless applications. These benefit immediately from cloud elasticity and validate your observability and deployment pipelines under real traffic.
Wave 3: Stateful applications and data stores. Applications with significant state, database-heavy workloads, and core business logic come last. By this point, your team understands the platform deeply, has established patterns for common challenges, and can apply that knowledge to your most critical systems.
Throughout this process, Convox's rolling deployment and rollback capabilities provide safety nets. If a deployment goes wrong, you can revert to the previous release in seconds—a capability that simply doesn't exist with traditional VM deployments.
A successful migration isn't just "the application works in the cloud." Strategic replatforming should deliver measurable improvements across multiple dimensions:
Deployment frequency: How often can you release? Legacy environments often support monthly or quarterly releases. Containerized applications on Convox typically achieve daily or multiple-daily deployments. Track this metric before and after migration.
Lead time for changes: How long from code commit to production? If legacy deployments require change management boards, maintenance windows, and manual processes, lead times might be weeks. Modern CI/CD pipelines with Convox's workflow integrations can reduce this to hours or minutes.
Mean time to recovery: When something breaks, how quickly can you fix it? Rollback capabilities, improved observability, and faster deployments all contribute to reduced MTTR.
Developer onboarding time: How long until new developers can deploy confidently? Declarative manifests and standardized deployment processes typically reduce onboarding from weeks to days.
Infrastructure cost efficiency: Are you paying for resources you're using? Track cost-per-transaction or cost-per-user-request to normalize for traffic changes.
Before beginning a migration, ensure you can answer these questions for each application:
Strategic replatforming requires a platform that makes modernization the path of least resistance. This is where purpose-built PaaS solutions like Convox differ from raw infrastructure or DIY Kubernetes setups.
With Convox, the convox.yml manifest naturally guides you toward good practices. Defining a health check is easier than not defining one. Externalizing configuration is the default pattern. Scaling rules are declarative and straightforward. You're not fighting the platform to implement modernization patterns—the platform is designed around them.
For teams migrating legacy applications, this means less decision fatigue and more consistent outcomes. The patterns in this article aren't aspirational; they're the standard way applications run on the platform.
Consider the alternative: migrating to raw Kubernetes requires building deployment pipelines, configuring ingress controllers, setting up certificate management, implementing log aggregation, and dozens of other operational concerns—all before you've deployed a single application. That overhead makes it tempting to skip modernization entirely and just get applications running. Convox eliminates that overhead, freeing teams to focus on the modernization work that delivers lasting value.
Cloud migration is inevitable for most organizations. The question is whether you'll treat it as a one-time move or as an opportunity for strategic improvement. Pure lift-and-shift is faster in the short term but locks in legacy patterns and misses optimization opportunities. Full application rewrites are comprehensive but rarely practical at scale.
Strategic replatforming—containerization with targeted modernization—represents the pragmatic middle path. By applying the five patterns outlined here (container optimization, configuration externalization, observability injection, dependency modernization, and statelessness refactoring), you can achieve meaningful improvements without multi-year transformation programs.
The key is choosing a platform that supports this approach rather than fighting against it. The right platform makes modernization natural, provides safety nets for experimentation, and handles operational complexity so your team can focus on what matters: delivering better software, faster.
Ready to modernize your legacy applications during migration? Convox provides the platform foundation for strategic replatforming—handling infrastructure complexity while you focus on application improvements.
Our Getting Started Guide walks you through installing your first Rack and deploying an application in minutes. Check out our example applications to see real-world implementations of the patterns discussed here.
Console accounts are free, and you can Get Started Free with a Rack in your own cloud account. For enterprises planning large-scale migrations with compliance requirements, reach out to our team to discuss how Convox can accelerate your modernization journey.
