DEV Community: Bob Palermo

Rewrite vs. Evolve

Bob Palermo — Wed, 14 Oct 2026 12:34:17 +0000

The platform has to change. The question is how: replace it with a clean-sheet build, or evolve the existing system toward the target.

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.

The infrastructure question is settled. ZibiWorks chose to move before
modernizing the application, but that decision left the monolith, the shared
database, and the tangled domains intact. With the migration path established,
attention turns to how the application itself should change.

The problem forcing the question

A specific business capability is under pressure: Order Fulfillment.

As ZibiWorks has grown, seasonal demand has grown with it, and Fulfillment
needs to scale more independently than it can today. Because Fulfillment is
embedded in the monolith, adding capacity for it means scaling far more of the
application than necessary, and problems or deployments in unrelated areas can
disrupt fulfillment processing. As order volume climbs, its availability and
resiliency matter more every quarter, and leadership wants this materially
improved before the next major peak season.

ZibiWorks is not modernizing for cleanliness. It has a business capability
that has to get better on a specific timeline, and that deadline is the single
most important criterion weighing on the decision.

Before comparing the two paths, one thing is worth settling: this is a decision
about how ZibiWorks travels, not where it is going. Whichever path it takes,
good domain analysis should land on substantially the same business
capabilities, bounded contexts, ownership, and data responsibilities. An
evolutionary path may surface new information along the way, so the final
implementation can differ in detail, but the migration mechanism should not
dictate the target decomposition. The destination is not what is in question
here.

Two credible options

Both are credible. Neither is foolish.

Option A — Rewrite

Design and build the new platform alongside the existing system
Migrate the business onto it
Retire the old system

Option B — Evolve

Create seams in the existing platform
Move capabilities into new bounded contexts over time
Retire legacy implementations as confidence grows

A clean rewrite is genuinely appealing: clean boundaries from day one, a modern
architecture without legacy compromises during construction, freedom to rethink
persistence and integration, and far less transitional scaffolding cluttering
the codebase. Building straight toward the desired end state is a real
advantage, and it deserves a serious evaluation rather than a reflexive "big
rewrites fail."

Evolution has its own strengths and its own real costs. The two differ on three
things that matter here: where the complexity lands, when the business sees
value, and how data moves.

Where the complexity lands

Neither approach avoids complexity; they place it differently in time. Both
involve substantial construction work. What differs is where the migration,
coexistence, validation, and cutover complexity falls.

Dimension	Evolution	Rewrite
Complexity	Migration complexity distributed throughout the transition: temporary adapters, compatibility layers, and synchronization.	Cleaner construction path, but migration and cutover complexity concentrated near completion.
Delivery of value	Fulfillment can improve independently while the rest of the platform evolves.	Fulfillment improvements depend on enough of the replacement platform being ready.
Data migration	Incremental, domain by domain. Ownership and validation move in smaller steps.	Larger, coordinated migration and reconciliation near cutover.

Evolution distributes migration complexity across the journey. A rewrite concentrates much of it near the destination.

Can a rewrite meet the deadline?

On construction alone, a rewrite might. The deciding question is not whether
ZibiWorks could build a replacement in time, but what it would take to put one
safely into production before the busiest period of the year.

A full-platform replacement couples the Fulfillment deadline to the readiness of
the entire new platform. Before peak season, ZibiWorks would have to validate
not just Fulfillment but every capability on it, resolve defects in capabilities
that are not driving the deadline, and complete data migration, reconciliation,
and a production cutover, then stabilize an entirely new platform right before
its highest-demand weeks.

Those pressures have nothing to do with Fulfillment. It could be
production-ready while defects in Customer Management or Billing hold up the
cutover, with QA and release capacity consumed by unrelated problems. Even a
rewrite delivered on time would send ZibiWorks into peak season on a platform
with little production history. The risk is not simply missing the date; it is
introducing broad operational uncertainty across the whole system at the exact
moment Fulfillment needs to be more reliable.

This is not an argument that rewrites fail. A narrowly scoped or phased
replacement could be viable under different constraints, and in that form it
starts to resemble evolution anyway. ZibiWorks is weighing a broad replacement
because its problems span the monolith, and at that scope the coordination and
stabilization risk against this deadline is what makes it hard to justify.

Could ZibiWorks buy more time?

The opposite move is to attempt nothing structural: scale out the existing
monolith, survive one more peak season, and defer modernization. It is a
legitimate option, and it turns on a distinction that is easy to blur, between
capacity and architectural resilience.

Horizontal scaling might handle the extra load, assuming Fulfillment's
bottleneck responds to additional compute. But more instances do not give
Fulfillment independent deployment or failure isolation, and the shared
constraints stay shared: database contention and synchronous dependencies can
remain, or even worsen as more instances press on the same backend. Scaling the
whole monolith to serve one capability raises cost too, though that is
secondary here.

Leadership asked for two things, scalability and resiliency. Additional
capacity may improve availability, but it does not eliminate the shared failure
risks Fulfillment faces within the monolith. Under lighter constraints, buying a
season of runway could be reasonable. For ZibiWorks it defers the problem rather
than reducing the risk it needs to retire before peak season.

Evaluating the options against the business needs

The choice becomes clearer when each approach is measured against what ZibiWorks
actually needs before peak season.

Decision criterion	Full rewrite	Scale existing monolith	Evolve incrementally
Improve Fulfillment before peak season	Depends on full-platform readiness	Can improve capacity quickly	Can prioritize Fulfillment
Scale Fulfillment independently	Yes, after replacement	No	Yes, after extraction
Improve Fulfillment resilience	Can design for resilience, but benefits arrive with replacement	Can add redundancy; shared failure risks remain	Can improve resilience as Fulfillment is extracted
Isolate Fulfillment from unrelated failures	Yes, with appropriate boundaries	Existing application coupling remains	Yes, with appropriate boundaries
Minimize peak-season deployment risk	Coordinated cutover and stabilization	Smaller immediate change, existing coupling remains	Smaller incremental transitions
Continue broader modernization	Complete replacement	Deferred	Progressive modernization

Leadership's requirements are explicit: improve Fulfillment's scalability and
resilience before peak season. Those are what the first rows measure. The rest,
deployment risk and the ability to keep modernizing, are supporting
architectural criteria rather than mandates, but they shape which option meets
the requirements safely. Read that way, no column strictly dominates. A rewrite
reaches the same target capabilities but gates them behind the whole
replacement; scaling adds capacity fastest but leaves the coupling and
resilience gap in place; evolution can act on Fulfillment first, provided the
extraction and its boundaries hold.

The decision

ZibiWorks chooses evolutionary modernization. It is the clearest path to
improving Fulfillment on its own timeline, without gating that improvement
behind a complete replacement. Scaling the monolith could improve capacity and,
through redundancy, availability, but it does not resolve the shared application
failure modes or give Fulfillment the independent failure isolation leadership's
resilience requirement implies. Evolution's gains are not free: they depend on
successfully extracting Fulfillment behind boundaries that hold. On ZibiWorks'
constraints that is the better bet than coupling Fulfillment's deadline to a
platform-wide cutover.

Under different constraints (no deadline, a smaller system, an appetite for one
coordinated cutover) the rewrite could be the better call. Here, the deadline
and the breadth of the system decide it.

What evolution requires

"Evolve the monolith" is a decision, not yet an architecture. Delivering it
means designing two architectures at once and keeping them distinct.

Target architecture

The system ZibiWorks ultimately wants
Domains, ownership, data responsibilities, integration
Permanent

Migration architecture

The temporary mechanisms that get there safely
Adapters, shims, DI seams, sync paths, fallbacks, routing, bridges
Designed to disappear

Keeping these separate is what stops the migration scaffolding from being
mistaken for the target. The migration architecture is real, designed work, even
though most of it is meant to be removed when the migration is done.

Reversibility, and its limit

One benefit of a designed migration architecture is that transitions can be made
reversible. The monolith depends on an interface representing a business
capability. Dependency injection first resolves that interface to the legacy
implementation; during migration it is swapped for an adapter that talks to a
newly extracted domain. From the monolith's point of view the contract is
unchanged even though the implementation boundary has moved, so routing can be
pointed back at the legacy implementation through configuration. A large
architectural change becomes a sequence of smaller, individually reversible
steps.

But routing rollback is not the same as business-state rollback. Flipping the
switch back is easy at the application boundary; whether it is safe depends on
what has happened to the underlying data. If the new domain has become
authoritative, how can the legacy implementation still be a viable fallback?

ℹ️ Data completeness and data authority are not the same thing

Authoritative writes can move to the extracted domain while the monolith keeps a complete enough representation of the data it needs, maintained from the new domain's events. The new domain owns the writes; the monolith's copy stays current enough for legacy workflows to keep running; the old implementation remains a plausible fallback. Call it dual presence, single authority: the data is present in both places, but only one side is the source of truth.

Completeness is not the same as authority, and it is not the same as safe rollback. Once authority has moved, reversing it also depends on state compatibility, business semantics, and the ability to reconcile whatever each side wrote in the meantime. Asynchronous synchronization keeps the fallback viable; it does not, by itself, guarantee a clean reversal.

Strangler Fig

With evolution chosen and the migration architecture understood, the Strangler
Fig pattern is the strategy that organizes the work. It gives the migration a
repeatable sequence: pick a capability, redirect its responsibility to a new
domain behind the existing contract, let old and new run side by side, move data
authority across once confidence builds, then retire the legacy implementation.
The cycle repeats, one capability at a time, until the monolith has been
strangled. Fulfillment is the natural first candidate, since it is the capability
under the most pressure.

The Scaffolding Fallacy

Most of that migration architecture is built to be thrown away, which invites a
tempting but wrong conclusion: that if something is going to be removed later,
the effort spent building it must be waste. Construction scaffolding is temporary
and is no part of the finished building, yet no one calls it wasted. Its value is
letting the building go up safely. Migration architecture is the same. It can
have no place in the target and still be worth a great deal during the
transition.

The guardrail is that "temporary" is not a license for uncontrolled complexity.
Scaffolding that earns its place has a purpose, a transition it enables, an
owner, and a known removal condition.

Temporary by design is very different from accidentally permanent. The problem
is not throwaway code; it is throwaway code that nobody ever throws away.

Consequences

The decision is a trade made with its costs in view.

What ZibiWorks gains

Fulfillment addressed first, ahead of peak season
Business value arriving earlier, not at the end
Smaller, independently validated transitions
A smaller blast radius per change, with more chances to roll back
Data migration spread across the program
No single platform-wide cutover

What ZibiWorks accepts

Temporary architecture and some disposable code
Coexistence between old and new
Eventual-consistency and synchronization concerns
Added operational complexity during migration
The ongoing job of actively retiring scaffolding

The right column is the price of the left one.

ZibiWorks has now decided to modernize, chosen evolution, and settled on
Strangler Fig as the approach. But a strategy is not a cut line. If a capability,
starting with Fulfillment, is going to move out of the monolith one piece at a
time, the next thing to understand is where the system can safely come apart.

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.

Move It or Fix It First?

Bob Palermo — Wed, 07 Oct 2026 14:14:56 +0000

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 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.

ℹ️ Timing is part of the architecture

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.

⚠️ When "later" becomes "never"

Deferring modernization is a deliberate decision, but it carries a risk. Once the migration is complete and the immediate infrastructure pressures are gone, the urgency to address those architectural problems may fade. "Migrate now, modernize later" can quietly become "migrate now, modernize never."

That does not make migration-first the wrong choice. It means the deferred work has to stay visible as part of the broader modernization effort.

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.

What's Driving Change?

Bob Palermo — Mon, 05 Oct 2026 12:33:27 +0000

Before designing anything, find where the current platform is starting to limit the business, and which touch points deserve a closer look.

ZibiWorks believes they need to modernize, but that conclusion did not come from an architecture diagram. It came from mounting pressure on the business and the teams supporting it. Changes take longer than they should. Deployments carry more risk. Partner integrations are getting harder to manage. New customer experiences and connected-product capabilities are placing demands on a platform that was built for a simpler business.

Those pressures are real, but they do not yet tell us what architecture to build. The instinct is often to jump directly to services, a message bus, the cloud, or a cleaner data model. That is premature. Before choosing an architecture, we need to understand where the current one is actually getting in the way, what business outcomes are being affected, and which problems are significant enough to justify change.

So this installment is about where modernization should start, not what to build. We will identify the business and technical pressures worth addressing, turn them into an initial set of success criteria, and establish the guiding principles that later architecture choices can be weighed against. Those criteria and principles become the decision lens for everything that follows.

What should guide the decision?

Before choosing an architecture, we need to know what should guide the choice.
That comes from combining two things: the business context, which tells us what
matters, and the technical context, which tells us what is feasible,
sustainable, and responsible to build and operate. The business rarely asks for
"changeability" or "resilience" by name; those are architectural
interpretations. Neither side provides the answer alone.

In brownfield work that business context often shows up as existing pain; in greenfield
work it more often arrives as goals, constraints, and assumptions. Either way,
the two inputs are:

Business context

Desired outcomes and business capabilities
Where the pressure is (for ZibiWorks, existing pain)
Cost, delivery, and timing
Customer expectations and growth assumptions
Risk tolerance and regulatory constraints

Technical context

Current platform capabilities, where one exists
Available technology choices and constraints
Team skills and operational maturity
Resilience, security, data integrity, observability
Technical debt (where applicable) and cost to operate

Combining the two produces the first useful output, and it is not a target
architecture. It gives us two things we can use to evaluate architecture
choices: success criteria, which describe what needs to improve and how we
will know, and guiding principles, which describe how we make decisions
while pursuing those improvements.

Those criteria and principles become the lens for the decisions that follow.

These are working criteria and principles, not commandments. As the business and
technical context change, the decision lens changes with them.

For ZibiWorks, then, the first step is not to redesign the platform because the
architecture looks old. It is to find where the current architecture is actually
creating meaningful friction, trace those pressures into the platform, and mark
where architectural change might create leverage, stopping short of choosing a
solution. Each pressure below follows the same path:

Business pressure → Business constraint → Architectural touch point → Options examined later

The platform still works

The platform is doing its job. Orders are placed, Zibis are shipped, customers and partners are served. The business is operating.

The original architecture was a good fit for an earlier ZibiWorks. What changed is the business around it. Growth has changed the consequences of the original tradeoffs.

The result is not a broken platform. It is a working platform beginning to show wear in a few important places. Those pressures are where the rest of this installment focuses.

Pressure 01 · Brittleness: The platform is getting harder to change safely

Over time, ZibiWorks' concerns have grown into one another. Orders reach into
Pricing, Inventory, Payments, Fulfillment, Shipping, Customer, and Zibi
Lifecycle, with product and catalog logic close behind. Shared models span
several business areas. Entity Framework entities flow upward through the stack.
Common models are reused broadly, and shared tables carry ambiguous ownership.

No single one of these dependencies is wrong. An Order genuinely needs pricing
and inventory. The trouble comes from how many of them accumulate and cross
through the same shared models, so a change in one area rarely stays in one
area.

A local change around Orders rarely stays local, because Orders is entangled with several surrounding concerns.

Interwoven concerns → Larger blast radius → Broader testing → More coordination → Slower delivery

A local change can have non-local effects. Making a change safely takes broader
knowledge of the system, regression testing expands, releases need more
coordination, and one change is harder to isolate from everything else.

Pressure 02 · Partner Coupling: External change has become an internal delivery problem

ZibiWorks depends on PayPaw, Handle With Care, Paw & Circuit, RoboMotion
Systems, and HomeSphere. As covered in The Starting
Point, partner-specific fields,
statuses, identifiers, workflows, payload shapes, and batch formats have worked
their way into internal logic and shared models.

Partner change now reaches beyond the partner boundary.

The business impact is specific: a partner change can require changes in parts
of ZibiWorks that look unrelated to that partner. A new API version, changed
payload, revised status model, new capability, deprecated interface, or new
compliance requirement can all ripple inward.

There is a second cost that is easy to miss. Because the integrations are woven
so deeply into the platform, ZibiWorks may not be able to adopt a better
partner API or a new partner feature quickly. That quietly limits its options.

Pressure 03 · Growth: Each new capability increases the cost of the next one

ZibiWorks wants to expand: more connected Zibis, more partners, more
customer and internal capabilities, new products and services, more reporting,
and eventually new platform opportunities. The current platform can support all
of it. The problem is that each new capability tends to make the next one
harder. That points at a kind of scalability people often skip past.

Runtime scalability

More requests
More transactions
More connected devices
Can the infrastructure handle growth?

Change scalability

More capabilities
More teams changing the system
More dependencies and coordination
Can the organization keep changing safely?

Scalability is not only about runtime capacity. Runtime scaling and change
scaling are different problems. Right now, change scalability is the bigger
problem.

Pressure 04 · Capacity: Normal demand or peak demand?

ZibiWorks runs on traditional infrastructure, so it has to size capacity
ahead of demand. Demand is not steady. Holidays, promotions, product launches,
partner campaigns, and seasonal buying all push it around.

Size for normal demand: lower steady-state cost, greater peak risk.
Size for peak demand: more headroom, more idle capacity.

The architecture makes this sharper. Much of the platform scales as a
coordinated unit, so a spike in one area can force ZibiWorks to add capacity
broadly rather than where the load actually is. The conclusion is not that cloud
is the answer. ZibiWorks needs a better answer to variable demand, and cloud
elasticity may eventually be one option worth weighing.

Pressure 05 · Customer Experience: Reliability is becoming part of the product

ZibiWorks is increasingly customer-facing. When the platform mostly supported
internal operations, downtime was an internal disruption. As more of it faces
customers, downtime becomes something customers see: a slow storefront, a failed
checkout, account functions that will not load, delayed order information,
Zibi management that is unavailable, connected features that degrade.

This connects directly to the capacity pressure. The periods of highest customer
demand are often the periods of highest infrastructure strain, so a capacity
shortfall tends to show up as a customer-facing outage at the worst possible
time.

Customer demand ↑ → Infrastructure pressure ↑ → Performance / availability risk → Customer experience

Reliability and scalability are becoming part of the customer experience, which
raises later questions about resilience, observability, failure isolation,
graceful degradation, and recovery.

None of these pressures selects an architecture. They mark where the current
platform constrains the business. Patterns and technologies come later.

From business pressure to architectural touch point

Each pressure points at an area of the architecture worth examining later. These
touch points show where the series will look next without assuming the eventual
solution.

Business pressure	Architectural touch point
Changes ripple	Boundaries, dependency structure, modularity
Partner blast radius	Integration boundaries, anti-corruption layers (ACLs), contract isolation
Growth cost rises	Extensibility, deployment boundaries, incremental evolution
Variable demand	Scaling model, workload isolation, elasticity
Visible downtime	Resilience, failure isolation, observability, recovery
Ambiguous ownership	Domain modeling, data ownership, contextual models
Diverging experiences	API boundaries, consumer-specific contracts
Reporting pressure	Analytical separation, read models, data movement

Sorting what is fine from what is not

Not everything imperfect in the platform is worth changing. Some of what looks
dated is still doing its job perfectly well, and some of what works today is
already starting to strain. The point of sorting is to separate the parts that
are fine from the parts that are actually costing the business something.

Still serving the business

.NET
SQL Server
Entity Framework
Responsive web application
Relational transactions
Shared deployment where it still simplifies operations

Creating measurable friction

Cross-domain business coupling
Ambiguous data ownership
Partner logic inside core services
Coordinated deployment
Broad regression impact

The business is beginning to require

Stable API contracts
Additional user experiences
More independent scaling
Clear telemetry and state ownership
Separation of operational and analytical workloads
Higher customer-facing availability

If this does not materially affect delivery speed, risk, scalability, availability, security, cost, or a business capability, why are we changing it?

We carry forward only the areas where a technical constraint can be tied to
meaningful business impact.

The initial decision lens

The pressures point to five areas worth deeper investigation. Together they
become the first working success criteria for ZibiWorks: for each, the
current strain and what improvement would look like.

Area & current strain	What success looks like
Changeability. Cross-domain coupling, shared ownership, and broad regression impact are raising the cost of change.	A smaller blast radius, less regression and coordination effort, and more changes that stay local.
Extensibility. Partner coupling and the rising cost of adding capabilities make external change expensive.	Less effort to absorb partner and capability changes, with fewer unrelated areas affected.
Scalability. Variable demand and increasingly different workload profiles expose both runtime and change-scaling constraints.	Handling variable demand without scaling the platform as one unit, while improving the system's ability to absorb ongoing change.
Reliability. Performance and availability problems are becoming visible to customers.	Fewer customer-visible failures, with better failure isolation and recovery where the business impact justifies it.
Data. Ambiguous ownership and competing operational and analytical needs are creating friction.	Clearer ownership and meaning, with less interference between operational and analytical workloads.

These are directions, not numeric targets. The evidence tells us what needs to
improve; the levels worth committing to come as specific decisions get made.

These criteria describe what needs to improve. The guiding principles describe how ZibiWorks should make decisions while pursuing those improvements. They are not intended to map one-to-one to the criteria; most apply across several of them.

Favor change isolation where coupling is materially slowing delivery.
Improve resilience where failures are becoming customer-visible.
Prefer reversible changes while the cost of being wrong is high.
Add complexity only when it buys a capability the business actually needs.
Preserve simplicity where the current design is still serving the business.
Design for foreseeable growth, not every theoretical future.
Treat security, data integrity, and operability as baseline constraints.

These are ZibiWorks' first working criteria and principles, not permanent rules.
They give the next decisions a consistent starting point and will be revisited
as the context changes.

With the pressures identified, the criteria named, and the principles in hand,
ZibiWorks can take on its first real choice: do we address these constraints
before moving the platform, or move first and modernize afterward?

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.