02. Move It or Fix It First?
Leadership wants to move to the cloud. Before evaluating that answer, separate what migration solves from what modernization solves.
“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 go backward into the problem space and work out what it would actually solve, what it would leave untouched, and whether the timing even makes sense.
What leadership is actually reacting to
Section titled “What leadership is actually reacting to”Behind “move to the cloud” is a stack of legitimate pressures:
- infrastructure hardware approaching its refresh cycle;
- rising operational burden in the current data center;
- disaster-recovery expectations that are getting harder to meet;
- seasonal demand that forces sizing for peaks;
- environment provisioning that takes too long;
- reluctance to sign off on another large capital investment;
- expected company growth;
- a general desire for more operational flexibility.
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.
Treated as one problem, all of that gets one answer, and that is the trap.
Recover the problem space
Section titled “Recover the problem space”Before any target architecture, sort the pressures by what kind of problem they actually are. The category an item lands in is a strong hint about what will fix it.
Infrastructure / platform
- Hardware refresh cycle
- OS / infrastructure lifecycle
- Disaster recovery
- Capacity planning
- Slow environment provisioning
- Data-center operational burden
- Capital expenditure
Application architecture
- Tightly coupled business capabilities
- Shared database
- Monolithic deployment
- Slow, risky releases
- Brittle partner integrations
- Team coupling in one codebase
- No independent scaling of capabilities
External constraints
- Legacy systems that must stay on premises
- Vendor products that cannot move yet
- Latency-sensitive integrations
- Unsupported OS or runtimes
- Licensing restrictions
- Hardware-attached dependencies
- Contractual obligations
Economics & timing
- Remaining useful life of current hardware
- Prepaid or committed licenses
- Support and data-center contracts
- Upcoming license renewal
- Hardware end of life
- An upcoming growth event
Which problems does each answer actually fix?
Section titled “Which problems does each answer actually fix?”Evaluate the pressures through two broad lenses, migration and modernization. Migration changes where the application runs. Modernization changes how the application is built. They are lenses on the problem, not the only two strategies available, and they solve different subsets of it.
| Pressure / problem | Migration helps? | Modernization helps? | If nothing changes |
|---|---|---|---|
| Hardware approaching refresh | High | Low | Capital expense, lifecycle risk |
| DR does not meet expectations | High | Medium | Recovery risk remains |
| Seasonal peak sizing | High | Medium | Idle capacity remains |
| Slow environment provisioning | High | Low | Delivery drag remains |
| Monolithic, risky releases | Low | High | Delivery risk remains |
| Shared database | Low | High | Domain coupling remains |
| Team coupling in one codebase | Low | High | Change stays slow |
| Brittle partner integrations | Low | High | Change stays expensive |
| Legacy systems must stay on premises | Negative / adds complexity | Neutral | Hybrid dependency remains |
| Prepaid licenses with years left | Negative / strands cost | Neutral | Early move wastes value |
The infrastructure pressures are primarily addressed by moving, while the application pressures are primarily addressed by modernizing. 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.
Comparing the real options
Section titled “Comparing the real options”“Migrate” versus “modernize” is a false binary. There are at least four strategies, and they differ on far more than whether they fix a given problem.
| Factor | Stay + Modernize | Migrate As-Is | Migrate + Selective Remediation | Migrate + Modernize Together |
|---|---|---|---|---|
| Addresses infrastructure lifecycle | Low | High | High | High |
| Addresses application coupling | High | Low | Low/Medium | High |
| Near-term cost | Medium | Medium | Medium | Very high |
| Delivery complexity | Medium | Medium | Medium | Very high |
| Program duration | Medium/High | Low/Medium | Medium | High |
| Infrastructure transition risk | Low | Medium | Medium | High |
| Application-change risk | Medium/High | Low | Low/Medium | High |
| Speed to leave current infrastructure | Low | High | High | Low |
| Speed to improve app agility | Medium | Low | Low initially | Potentially high |
| Reversibility | Medium | Relatively high | Medium/High | Low |
These matrices are not scorecards. Nothing here adds up to a winner. They exist to make the exchanges visible so the decision can be argued honestly.
What does it cost to leave, and what does it cost to stay?
Section titled “What does it cost to leave, and what does it cost to stay?”Migration decisions are often dominated by money and timing rather than technology. The questions that actually move the decision:
- Where are the current hardware, licenses, and support contracts in their lifecycle?
- What existing investment would be stranded by moving now?
- What new investment would be required if the company stays?
- Are any major renewals, refreshes, or business events creating a natural decision point?
Can the workload even move on its own?
Section titled “Can the workload even move on its own?”A workload’s migration readiness is partly set by the systems around it. ZibiWorks does not run in isolation.
flowchart LR
CW["ZibiWorks Platform"]
SQL[("SQL Server")]
Fulfil["Legacy Fulfillment"]
WMS["Warehouse / Manufacturing"]
CW --> SQL
CW --> Fulfil
CW --> WMS
The questions that decide movability:
- Which of these dependencies are moving, and which cannot move yet?
- Would relocating ZibiWorks push core transactions repeatedly across a WAN?
- Do the current OS and runtime run in the target environment? Are the vendor products supported there?
- Are there hardware or licensing dependencies that make relocation hard?
- Does a partial move improve the system, or just relocate part of it?
Legacy dependencies do not automatically block a move. They change its cost and shape. A dependency that must stay on premises turns a clean migration into a hybrid one, with private connectivity and latency to manage.
Is migration even necessary?
Section titled “Is migration even necessary?”The original request skips this one. If ZibiWorks’ most painful problems are slow delivery, shared data, team coupling, brittle integrations, and risky releases, then moving infrastructure alone solves none of them. And 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.
Do not confuse the destination with the problem.
Migration has to earn its place against the alternative of modernizing where the system already runs.
At this point the analysis has narrowed the decision, but it has not made it. The matrices expose what each option solves, what it costs, and what complexity it introduces. They do not select a strategy. That requires the facts specific to ZibiWorks: its lifecycle, dependencies, timing, and business priorities.
How ZibiWorks lands, and why
Section titled “How ZibiWorks lands, and why”For ZibiWorks specifically, the facts line up in a particular way:
- the current infrastructure is approaching a hardware refresh;
- major licenses are approaching renewal at roughly the same time;
- recovery expectations are rising faster than the data center can meet them;
- seasonal peaks force expensive over-provisioning;
- expected growth would require a fresh round of infrastructure investment;
- environment provisioning is too slow to support the delivery pace;
- the monolith can run in the target cloud with manageable remediation;
- a few legacy systems must stay on premises but can be reached over private connectivity;
- full application modernization would take far longer than the infrastructure lifecycle allows.
Given those facts, the sensible next move is:
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 timing and constraints (new hardware, prepaid licenses with years left, no growth event, healthy DR), the same analysis could lead somewhere else, such as “stay and modernize.”
Migration blockers vs. modernization concerns
Section titled “Migration blockers vs. modernization concerns”Selective remediation means changing only what is necessary to make the migration safe, supportable, and useful, and deliberately leaving the rest. 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 this 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
What carried the decision
Section titled “What carried the decision”A few things did the real work in this analysis, and they hold up outside ZibiWorks. Migration and modernization usually are not solving the same problem, so the option that fixes the most problems is not automatically the best next move. Infrastructure lifecycle, application architecture, and business economics run on different clocks, and what it costs to leave matters as much as what it costs to stay.
Those ideas turn into a repeatable way to structure the conversation. When someone proposes moving a workload, work through five dimensions rather than debating the destination:
There is no total to compute and no weighting to tune. The point is to get the important factors on the table before arguing for a destination. These five dimensions provide a useful structure for that conversation, both for ZibiWorks and for similar migration decisions.
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.