Microservices migration: When to split a production system and how to control the risk

Last substantive review: August 2026.

For a stable company with a mature production system, microservices are not a modernization badge. A split is justified only when a specific boundary needs independent ownership, release, scaling, failure isolation, security treatment, or technology—and when the organization can operate the new networked system without making customers carry the migration risk.

Horizon Labs starts with a bounded split-readiness and first-extraction engagement. We map the production behavior, identify the actual delivery or reliability constraint, test a candidate service boundary, define the data and transaction plan, and write rollout and rollback evidence before moving traffic. Senior architecture, platform, data, security, AI, embedded, IoT, and integration specialists are typically $150–200 per hour. That lane fits inherited backlogs and high-risk migrations; it does not promise that every monolith should be split or that a particular schedule will hold before discovery.

This article is for CTOs, vice presidents of engineering, platform leaders, and product owners deciding whether to divide a working system. It owns the production split decision and migration controls. It is not generic startup-scaling advice, a catalog of cloud products, or a Kubernetes tutorial.

Define the constraint before choosing the architecture

A monolith can be well designed, modular, observable, and safe to change. A collection of services can be tightly coupled, hard to test, and deployed as one fragile unit. Count deployment and ownership boundaries, not repositories or containers.

Write down the recurring constraint in operational terms. Examples include a capability that must scale independently but forces the whole application to scale; customer-facing work that waits on a shared release train; a regulated data path that needs a distinct trust and access boundary; a failure-prone integration that should not consume the main process; or two teams that repeatedly coordinate changes inside one business area. Support the claim with release history, incident records, dependency graphs, telemetry, change collisions, and interviews.

Traffic and team size are context, not automatic triggers. A high-volume application may scale as a monolith. A small service estate can still be operationally expensive. Before a split, test less expensive corrections:

• make module boundaries explicit and stop cross-module writes;
• repair build, test, environment, review, and release bottlenecks;
• assign clear code and operational ownership inside the monolith;
• move slow or failure-prone work behind an internal queue without creating a separate service;
• isolate a workload at the process or infrastructure layer;
• remove unused dependencies and customer-specific branches;
• add observability around the suspected boundary and measure it through normal operation.

If those changes remove the constraint, keep the modular monolith. Horizon Labs’ architecture decisions guide covers reversible choices and evidence thresholds before a production system absorbs more complexity.

Use a split decision record

A decision record prevents “microservices” from becoming an untestable strategy. For each candidate boundary, state:

• the business capability and language it owns;
• current callers, owners, repositories, tables, jobs, queues, vendors, and customer commitments;
• the constraint a split is expected to remove;
• why a module, process, queue, managed product, or operational change is insufficient;
• which deployment, scaling, security, data, and availability properties must become independent;
• the new failure modes, network calls, operating cost, and team responsibilities;
• how success and customer safety will be observed;
• the migration sequence, stop conditions, and rollback path.

The current Microsoft guidance on identifying microservice boundaries begins with bounded business contexts and validates that services are cohesive, loosely coupled, independently deployable, and not chatty. It also recommends coarse boundaries when uncertain because splitting a service later is easier than untangling functionality spread across several services. Treat that as architecture guidance, not a formula that discovers the right domain automatically.

A useful boundary owns a coherent business invariant and can change without coordinated deployment of its neighbors. It has a named team that can build, release, observe, support, and retire it. If every feature requires synchronous calls through several services, a shared schema change, and a coordinated release, the system has distributed the code without distributing autonomy.

Choose the first seam for learning and value

The first extraction should teach the organization how to operate a service while addressing a real constraint. “Easy but irrelevant” proves plumbing and little else. “Most critical and least understood” creates an unsafe first experiment. Look for a capability with visible business ownership, a tractable caller set, testable behavior, manageable data dependencies, and a reason to deploy or scale independently.

Map the seam before writing the service. Trace incoming requests and events, authorization decisions, database reads and writes, scheduled jobs, reports, caches, outbound notifications, and failure handling. Find callers outside the main application, including support scripts, analytics jobs, customer exports, mobile versions, devices, and partner integrations. Search production telemetry as well as source; undocumented consumers are common in mature systems.

Define the new contract from the consumer’s perspective. Include semantics, authentication and authorization, versioning, idempotency, timeouts, rate behavior, error handling, payload limits, and deprecation. A network boundary makes previously local failure and latency visible. Avoid copying an internal class interface into an HTTP API and calling the result decoupled.

Set an operational budget for the extraction. The new service adds at least one deployment unit, configuration surface, identity, secret set, dependency edge, dashboard, alert path, on-call responsibility, and failure mode. It may add a database, message broker, certificate path, network policy, cost allocation, and incident handoff. Name who will own each item before production traffic moves.

Install the platform prerequisites before multiplying services

Independent deployment is only valuable if deployment is repeatable. A team that releases one application manually will not become faster by releasing several applications manually. Establish a paved path that covers:

• version-controlled builds and deployment definitions;
• artifact identity and promotion between environments;
• automated unit, integration, contract, and critical journey tests;
• environment configuration and secret handling;
• service identity, least-privilege access, and certificate or key rotation;
• database migration sequencing and backward compatibility;
• progressive delivery, feature or routing controls, and rollback;
• central logs, metrics, trace context, ownership metadata, dashboards, and alerts;
• runbooks, on-call escalation, incident review, and service retirement.

The specific platform can be modest. Managed containers, platform-as-a-service, serverless functions, virtual machines, and Kubernetes can all host services. Kubernetes provides a control plane for desired state and container workloads; it does not choose domain boundaries, make APIs compatible, resolve distributed transactions, or staff on-call. Adopt it only when its capabilities justify cluster upgrades, networking, access control, security policy, capacity management, and troubleshooting.

If the existing release path is the constraint, repair that first. Horizon Labs’ CI/CD pipeline guide covers build, test, artifact, deployment, and rollback controls. The principle is provider-independent: prove one repeatable path before each extraction creates another variant.

Give each service a data boundary

A service is not independent when another service writes its tables. During migration, temporary sharing may be unavoidable, but call it transitional, restrict it, instrument it, and give it a removal milestone. A new API in front of the same mutable schema can preserve the tightest coupling while adding network failure.

Microsoft’s current data considerations for microservices state that a service manages its private data store and other services should not access it directly. The guidance distinguishes a separate schema from a separate physical database server and asks teams to define where strong consistency is required and where eventual consistency is acceptable. Apply that boundary pragmatically during migration; do not split data before understanding its invariants.

For the candidate service, create a data ownership ledger:

Prefer expand-and-contract changes: add compatible fields or endpoints, deploy consumers that understand both forms, move producers, verify adoption, then remove the old form. This protects rolling deployments and lets old and new paths coexist. Destructive schema cleanup should happen after the confidence window, not during the first traffic shift.

Design cross-service transactions instead of hand-waving them

Keep an invariant inside one service and one local transaction when that is the honest boundary. Splitting a checkout, booking, entitlement, or device command across services changes failure semantics. “Eventual consistency” is not a recovery plan; the team must define what a user sees after each partial outcome and which action makes the business state acceptable.

For a workflow that must span services, model states and transitions. Identify local commits, durable messages, timeouts, retries, duplicate handling, ordering assumptions, compensation, manual review, and the point after which an action cannot truly be undone. A refund may compensate a captured payment, for example, but it is a new business action rather than a database rollback.

Microsoft’s saga pattern guidance describes a sequence of local transactions coordinated through messages or events, with compensating transactions after failure. It also documents the added complexity and isolation concerns. Use a saga when the business process needs it; do not introduce one to avoid drawing a better service boundary.

A common failure is the dual write: code commits business data, then publishes an event, and one operation succeeds while the other fails. AWS’s transactional outbox guidance stores the business change and an outbox record in one local transaction, then publishes committed records. It warns that consumers may receive duplicates and should be idempotent. An outbox narrows one consistency gap; it does not make the entire distributed workflow exactly once.

Give every command and event a stable identity. Make handlers safe for expected redelivery, store enough state to detect repeats, and decide how poison messages are isolated, inspected, corrected, and replayed. Set retention and replay boundaries. A dead-letter queue with no owner or tool to repair events is storage for unresolved production incidents.

Use a strangler sequence with observable checkpoints

A big-bang rewrite combines behavior change, platform change, data migration, and traffic cutover. The strangler pattern reduces that concentration by routing one bounded capability to a new implementation while the old system continues to serve the rest. AWS’s current strangler fig guidance describes a proxy or anti-corruption layer, progressive routing, service-owned data, and eventual retirement of the monolith. It also warns that premature decomposition, the proxy itself, synchronous calls, and data consistency introduce risk.

1. Baseline: instrument the current path and agree on customer, correctness, latency, error, and operating signals.
2. Intercept: add a routing or adapter seam that initially preserves existing behavior. Test its availability and bypass or rollback path.
3. Implement: build the new service and contract against recorded and synthetic cases. Keep incompatible business changes outside the extraction where possible.
4. Populate: backfill or replicate required data with counts, checksums or domain reconciliation, lag monitoring, and a declared source of truth.
5. Compare: shadow safe reads or compare outputs without creating customer-visible side effects. Investigate differences; do not normalize them away.
6. Shift: move an internal cohort, tenant, route, or percentage that can be identified and reversed. Watch user outcomes and downstream effects.
7. Stabilize: run through representative load, failure, deployment, incident, and recovery scenarios. Complete runbooks and ownership transfer.
8. Retire: remove old callers, data synchronization, adapters, code, infrastructure, and access only after evidence shows they are no longer required.

Each step needs an entry condition, named approver, evidence, stop condition, and rollback action. A calendar date is not enough. If reconciliation drifts, tracing disappears, rollback data is incomplete, or a customer-critical error rises beyond the agreed threshold, stop the shift and diagnose.

Make observability part of the boundary

A local function call inherits context. A network call can time out, retry, duplicate work, queue, or fail after the caller gives up. Instrument the new edge before the first production cohort. Propagate request or correlation context; record service, version, environment, route, dependency, outcome, and latency without placing secrets or sensitive payloads in telemetry.

The OpenTelemetry observability primer describes traces, metrics, and logs as complementary signals and explains that distributed traces follow a request through multiple services. Instrumentation is only the input. The team still needs user-centered service indicators, useful aggregation, data retention, dashboards, alerts tied to action, and an owner who can interpret the result.

Monitor both the service and the migration:

• customer success and failure for the migrated capability;
• request rate, latency, errors, saturation, timeouts, and retry volume;
• queue depth, age, redelivery, dead letters, and replay results;
• dependency latency and failures, including the remaining monolith;
• data replication lag, reconciliation differences, and rejected writes;
• old-versus-new routing, versions, deployments, and rollback actions;
• support contacts and business exceptions that system metrics miss.

Alert on conditions that require action. Paging on every service-local symptom creates noise; waiting only for infrastructure failure misses incorrect customer outcomes. During migration, temporary comparison and reconciliation alerts deserve explicit owners and expiry dates.

Engineer traffic rollback and data recovery separately

Traffic rollback sends callers back to the old path. Data recovery makes the resulting state coherent. They are not the same operation. If the new service accepted writes, traffic can return in seconds while records remain split, reordered, duplicated, or absent from the monolith.

Before cutover, write a phase-specific rollback matrix. State which route changes, how long propagation takes, which code and schema versions remain compatible, where writes land, whether events can be replayed, how duplicates are controlled, which data needs reconciliation, and who authorizes the move. Test the mechanism in a representative environment and rehearse the decision path with the people on call.

Avoid unrestricted dual writes from application code. If a transition requires mirrored data, declare one authoritative writer and use a durable, observable replication path. Keep a ledger of cutover cohorts and versions. Delay destructive cleanup, schema contraction, and cancellation of the old operating path until the agreed confidence period and recovery evidence are complete.

Rollback may be unsafe after an irreversible external action or after the old system can no longer understand new state. In that case, design roll-forward repair, compensation, or manual containment before release. “We can redeploy the old version” is not an adequate answer when the data contract changed.

Measure whether the split removed the original constraint

After stabilization, compare the evidence with the decision record. Can the owning team release the capability without coordinated deployment? Did the target workload scale or fail independently? Did customer reliability improve or at least remain within its agreed objective? Did change lead time improve without a rise in deployment instability, support load, or on-call burden? Did cloud, tooling, and staffing cost move as expected?

Also count the tax: cross-service changes, contract versioning, local development setup, test flakiness, incident handoffs, duplicated data, platform work, access reviews, and dormant services. If the boundary remains chatty or always changes with its neighbor, merge it or redraw it. Architecture is allowed to reverse a decision when production evidence changes.

Do not turn one successful extraction into a mandate to dismantle the monolith. Review the next candidate against the same bar. The best end state may be a modular core with a small number of independently operated services around genuine business and failure boundaries.

Horizon Labs can take on a split-readiness assessment, the first production extraction, or a bounded remediation tranche for a stalled migration. Work begins with the specific backlog, production evidence, and receiving owners. For API cutovers with temporary dual paths, the webhook and API reconciliation guide goes deeper on idempotency, ledgers, replay, and acceptance.

If your company needs senior engineering muscle to clear a migration backlog without turning the whole platform into an experiment, contact Horizon Labs. A useful first scope names one production seam, its business owner, the evidence available, and the rollback decision the team must be able to make.

Frequently asked questions

When should a company split a monolith into microservices?

Split when evidence shows that a business boundary needs independent ownership, deployment, scaling, failure isolation, security treatment, or technology—and the expected benefit outweighs the distributed-system and operating cost. Team size or traffic alone is not enough. If clearer modules and delivery repairs remove the constraint, keep the modular monolith.

Is Kubernetes required?

No. Microservices describe service and ownership boundaries, not a mandatory runtime. A company can use managed containers, platform-as-a-service, serverless functions, virtual machines, or Kubernetes. Choose Kubernetes only when its scheduling and control-plane capabilities justify the cluster, security, upgrade, networking, and on-call burden.

How do microservices handle transactions?

Keep operations that require one atomic commit inside one service boundary when possible. For a workflow that truly spans services, define the source of truth, consistency requirement, durable state, idempotency, message ordering assumptions, retry behavior, and compensation. A saga can coordinate local transactions; a transactional outbox can avoid an unsafe database-and-message dual write.

What is strangler migration?

It is an incremental replacement approach. A routing or adapter layer first sends behavior to the existing system, then selected calls move to a new service while the old path remains available. The team migrates one bounded capability at a time, verifies behavior and data, shifts traffic gradually, and retires legacy code only after dependencies have moved.

How do you roll back a service extraction?

Preserve a compatible old path, declare the authoritative data source at every phase, avoid irreversible cleanup during the confidence window, and define traffic and data rollback separately. Rollback triggers should use customer and system signals. Replaying events or reconciling writes may still be required after traffic returns to the monolith.

Sources

• https://learn.microsoft.com/en-us/azure/architecture/microservices/model/microservice-boundaries
• https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations
• https://learn.microsoft.com/en-us/azure/architecture/patterns/saga
• https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html
• https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html
• https://opentelemetry.io/docs/concepts/observability-primer/