Leadership wants to move to the cloud. Before evaluating that answer, separate what migration solves from what modernization solves.
This article is part of ZibiWorks, an ongoing fictional modernization case study. The ZibiWorks site is the canonical home of the series, with the full company context, starting architecture, and related installments. Explore the full series at ZibiWorks.
"Move to the cloud" is a reasonable instinct, and it comes from real pressure.
But it is a solution, not a problem. Before evaluating it, the job is to work
out what moving would actually solve, what it would leave untouched, and whether
the timing even makes sense.
What leadership is actually reacting to
Behind "move to the cloud" is a stack of legitimate pressures: hardware
approaching its refresh cycle, a rising operational burden in the data center,
disaster-recovery expectations that are getting harder to meet, seasonal demand
that forces sizing for peaks, environment provisioning that takes too long, and
a reluctance to sign off on another large capital investment just as the company
expects to grow.
ZibiWorks also has a separate, well-known set of problems in the application
itself, established back in The Starting
Point: risky monolithic releases,
teams colliding in one codebase, a shared database, tightly coupled business
domains, brittle partner integrations, and no way to scale business capabilities
independently.
Both lists are real. The trap is treating them as one problem with one answer.
Sort the pressures by what kind of problem they are, and a pattern shows up:
some are about where the application runs, and some are about how it is
built. A third set is not a problem class at all. These are the constraints and
timing that shape when and how either kind of change can happen.
Where it runs (infrastructure)
- Hardware refresh and OS lifecycle
- Disaster recovery
- Capacity planning and seasonal peaks
- Slow environment provisioning
- Data-center burden and capital expenditure
How it is built (application)
- Tightly coupled business capabilities
- Shared database
- Monolithic, risky deployment
- Brittle partner integrations
- No independent scaling of capabilities
Constraints and timing
- Systems that must stay on premises
- Unsupported runtimes or licensing limits
- Prepaid or committed licenses
- Upcoming renewals, refreshes, or growth events
Migration and modernization solve different problems
Migration changes where the application runs. Modernization changes how it is
built. They are not rival strategies so much as answers to different questions,
and the split in the pressures above maps almost cleanly onto them.
| Pressure | Migration helps? | Modernization helps? |
|---|---|---|
| Hardware refresh, DR, seasonal peaks | High | Low |
| Slow environment provisioning | High | Low |
| Monolithic, risky releases | Low | High |
| Shared database, domain coupling | Low | High |
| Brittle partner integrations | Low | High |
| Systems that must stay on premises | Negative / adds complexity | Neutral |
The one line to carry out of this installment:
Moving the monolith to the cloud does not un-share the database or untangle the domains. Modernizing in place does not replace aging hardware or fix DR.
That is why "migrate or modernize" is a false binary. The real options sit on a
spectrum: modernize in place, migrate largely as-is, migrate with
selective remediation, or migrate and modernize together. Doing both at
once addresses the most problems, which is exactly why it is tempting, but it
also carries the most cost, the longest duration, the heaviest coordination, and
the greatest execution risk. The question is not which option is best in the
abstract. It is which sequence fits ZibiWorks right now.
What narrows the decision
Sequencing is decided less by architecture than by lifecycle, money, and
dependencies. Three facts do most of the work.
Timing and economics. Much of what makes a move cheap or expensive is not
technical at all. The cost of leaving and the cost of staying both turn on where
ZibiWorks sits in the hardware, license, and contract lifecycle, and that
position changes constantly.
The same decision flips with the calendar. A migration that looks unattractive
the month after a hardware purchase can look obvious when that hardware is a
year from replacement. Note when things expire, not just what they are.
Dependencies. A workload's readiness to move is partly set by the systems
around it, and ZibiWorks does not run in isolation.
Legacy dependencies do not automatically block a move; they change its cost and
shape. Some can move, some cannot move yet, and anything that must stay on
premises turns a clean migration into a hybrid one, with private connectivity
and latency to manage.
Whether the move is even necessary. It is worth saying plainly that if the
current infrastructure had years of life left, met capacity and recovery needs,
and was cheap to run, delaying the move could be the right call. Migration has
to earn its place against simply modernizing where the system already runs.
How ZibiWorks lands, and why
For ZibiWorks, those facts line up in one direction. The hardware refresh is
approaching and major licenses are nearing renewal at roughly the same time.
Recovery expectations are rising faster than the data center can meet them,
seasonal peaks force expensive over-provisioning, and expected growth would
otherwise trigger a fresh round of infrastructure investment. Environment
provisioning is already too slow for the delivery pace. On the application side,
the monolith can run in the target cloud with manageable remediation, and the
few legacy systems that must stay on premises can be reached over private
connectivity. Crucially, full modernization would take far longer than the
infrastructure lifecycle allows.
Put together, the infrastructure clock is forcing a decision now, and the
application work cannot be finished on that timeline. So:
Move now. Modernize next. Change only what is required to make the move safe and useful.
That is migration with selective remediation: not a blind lift-and-shift,
and not a big-bang modernize-while-moving. Under different facts (new hardware,
prepaid licenses with years left, no growth event, healthy DR), the same
reasoning could land on "stay and modernize." The decision follows the
constraints, not a preference for one strategy.
What gets fixed now, and what waits
Selective remediation only works if the line between the two is explicit. The
deferred items are real and important; they simply do not need to be solved to
move the application safely. Keeping that line clear is what stops the move from
sliding into a rewrite.
Fix now: migration blockers
- Repeatable, automated deployment
- Externalized environment configuration
- Remove hard dependencies on server identity
- Health checks
- Baseline observability
- Reliable backup and recovery
- Infrastructure automation
- Connectivity to systems staying on premises
- Anything unsupported in the target environment
Defer: non-blocking modernization concerns
- The shared database
- Business-domain coupling
- Monolithic deployment
- Brittle integration boundaries
- Most code-level modernization work
A known problem can be deliberately deferred when solving it is not required to
reach the current objective. That is a discipline, not an oversight.
What the move leaves behind
After the move, ZibiWorks has better infrastructure automation, better recovery,
faster provisioning, a more flexible capacity model, and less dependence on
physical hardware. The platform is in a better position to evolve. But when the
teams open the codebase again, the same problems are waiting: the monolith is
still a monolith, the database is still shared, the business capabilities are
still tightly coupled. ZibiWorks chose not to solve those during the move. Now
it is time to.
The next question is whether to replace the application or evolve it.
ZibiWorks is fictional. The ideas and opinions expressed throughout the series are my own and do not represent the views, positions, or practices of my employer.
Top comments (0)