How to migrate a monolith to the cloud (without rewriting it)

Most businesses do not run microservices; they run one application that does everything, and it works. The good news: that monolith can move to the cloud largely as it is, and the teams who accept that ship in weeks instead of years.

The honest argument: do not rewrite it during the migration

The temptation is real. The migration feels like the natural moment to “do it properly”: split the monolith into services, adopt Kubernetes, go serverless. Resist it, for three concrete reasons:

1. You would be running the two riskiest project types in software simultaneously. An infrastructure migration and an architectural rewrite each have long tails of unknown unknowns. Stacked, they multiply: when checkout breaks at 2 a.m., is it the new network, the new service boundary, or the new code? You have no stable baseline to bisect against.
2. The timeline stops being a timeline. A rehost of a typical monolith is 4 to 10 weeks. Decompositions are measured in quarters, and mid-rewrite there is a long period where you maintain both the old and new systems. Migrations scoped as “move and modernize at once” are the ones that turn into 18-month sagas with nothing shipped.
3. The cloud makes the monolith better anyway. Real hardware instead of the aging box in the closet, snapshots, load balancers, managed databases, autoscaling. Most of the pain that motivated the rewrite conversation (slow provisioning, no failover, scary deploys) is infrastructure pain, and rehosting fixes it without touching the code.

This is the lift-and-shift vs replatform vs refactor decision applied to one app, and for monoliths the answer is almost always: rehost now, with a short list of surgical fixes, and treat decomposition as a separate, later decision.

The pre-flight fixes worth making

“Move it as is” has a caveat: a few habits from single-server life will break in the cloud, or block you from ever running more than one instance. Fix these before or during the move; each is days of work, not months.

Habit	Why it breaks in the cloud	The fix
Sessions in process memory	Any restart or second instance logs users out	Managed Redis (ElastiCache, Azure Cache for Redis, Memorystore), or signed cookie sessions
Files written to local disk	Uploads vanish when the instance is replaced	Object storage via SDK, or a shared file system as the low-change bridge (see the file storage guide)
Config and secrets in files on the server	Blocks automation; credentials end up in images and repos	Environment variables plus a secrets manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)
Logs written to local files	Nothing survives an instance replacement	Ship to CloudWatch, Azure Monitor, or Cloud Logging via stdout or an agent
Scheduled jobs in cron on the box	Runs once per instance, or not at all after a rebuild	One designated worker instance, or the platform scheduler (EventBridge, Logic Apps, Cloud Scheduler)

The common thread: get state out of the instance. Once the machine itself holds nothing precious, instances become replaceable, and replaceable instances are what unlock scaling, self-healing, and calm deploys.

The database deserves its own plan. Moving it to a managed service (RDS, Azure SQL, Cloud SQL) is the one replatform nearly always worth taking mid-migration; the method is in the database migration guide.

Rehost mechanics, briefly

With the fixes above, the move itself is standard: replicate the server to a cloud VM (AWS MGN, Azure Migrate), or build a fresh VM from your deploy process if you have one, put it in a private subnet of a properly planned VPC, front it with a load balancer even while there is only one instance (it makes the later steps free), and cut over via DNS in a low-traffic window. Size the VM to match current hardware, then right-size down after a month of metrics.

A note on containers: packaging the monolith into a single container image is a reasonable middle step, mostly for reproducible deploys. It is not required, and it is not the same thing as microservices. The tradeoff has its own guide: should you containerize before migrating?

Scaling the monolith once it lands

Monoliths scale further than their reputation suggests:

• Vertical first. Cloud instances go far bigger than typical on-prem hardware; moving from an old 8-core box to a modern 32-core VM is often a generational performance jump on its own.
• Horizontal second. With sessions and files externalized, run N identical instances behind the load balancer and enable autoscaling on CPU or request count. Most monoliths need no code changes beyond the pre-flight list.
• Read replicas for the database when reads dominate, and a CDN in front of static assets, before anyone says the word “microservices.”

If you do decompose later: the strangler fig

Some monoliths genuinely earn decomposition: one module needs independent scaling, a separate release cadence, or a dedicated team. The safe pattern is the strangler fig: leave the monolith running, put the routing layer you already have (the load balancer or an API gateway) in front, and peel off one capability at a time into its own service. Route only that traffic to the new service, watch it in production, then pick the next piece. The monolith shrinks gradually and can keep serving everything the new services do not.

Two rules keep it honest: extract a module only when you can name the concrete problem staying in the monolith causes, and never let the strangler project block the migration schedule. Many teams peel off two or three edges (a reporting endpoint, an image pipeline) and correctly stop there. A smaller monolith plus a few focused services is a fine end state, not a failure to finish.

FAQ

Should we break the monolith into microservices before migrating?

No. Migrate first, decompose later if the pain justifies it. A rehost is a contained project measured in weeks; a decomposition is an architectural program measured in quarters. Combining them means debugging new code, new infrastructure, and new failure modes at the same time, with no stable baseline to compare against. The monolith that annoys you today will run fine on cloud VMs while you decide what actually needs to change.

What has to change in the app before it can move?

Usually three things. Sessions must move out of process memory into a shared store like managed Redis, or users get logged out whenever an instance restarts. Files written to local disk (uploads, exports, generated PDFs) must move to object storage or a shared file system. And configuration hardcoded in files must become environment variables or a secrets manager entry. Everything else can usually move as is.

Can a monolith scale in the cloud?

Yes, further than most teams ever need. Scale vertically first: cloud VMs go far larger than typical on-prem hardware. Once sessions and files are externalized, the monolith is stateless enough to scale horizontally too, with identical instances behind a load balancer and autoscaling on CPU or request count. Stack Overflow famously served global traffic for years on a small number of beefy machines.

When is the strangler fig pattern worth it?

When a specific part of the monolith has a concrete problem the monolith cannot solve: one module needs to scale independently, deploy on its own cadence, or be owned by a separate team. Peel that piece off behind the load balancer and leave the rest alone. If you cannot name the module and the problem, you do not need the pattern yet.

---

Weighing a move for an application that has grown for a decade? Talk to a Webisoft cloud engineer. We’ll look at the codebase’s actual cloud blockers, scope the pre-flight fixes, and give you a realistic rehost timeline before you commit to anything larger.