Microservices Migration: Example from a Company

A microservices migration example from a company is rarely the story of a brave big-bang rewrite. In practice, modernization usually starts where the pressure is highest: releases take weeks, individual bugs incapacitate entire functions, or the growth of a digital product can no longer be economically supported by the existing architecture. The key is not to build as many services as possible. The key is to bring business changes into production faster and with calculable operational risk.

This is particularly relevant for medium-sized companies. A grown monolith is not automatically a problem. It becomes a problem when it makes teams dependent on each other, scaling becomes unnecessarily expensive, or any adjustment triggers a disproportionately large testing and approval effort. In such cases, a gradual migration to microservices can make sense - provided that architecture, platform operation, and organization are considered together.

Microservices Migration: Example of a Typical Company

Let’s imagine a medium-sized B2B retailer with its own e-commerce platform. The company processes customer accounts, pricing logic, orders, stock levels, invoices, and interfaces to ERP in a central application. The system has grown over years, is functionally valuable, and fundamentally stable. However, a new customer portal is to enable individual assortments, real-time availability, and faster quotation processes.

The difficulties do not arise in individual functions but rather in the dependencies: a change in the pricing service affects the entire release. Load spikes in the product catalog consume the same resources as checkout. The ERP sometimes responds slowly and can, in the worst case, block ordering processes. At the same time, only a few developers can reliably change the critical parts of the application.

The wrong response would be to completely replace the monolith and move all domains to containers in parallel. Such an undertaking ties up capital, extends the time to first business benefit, and often creates two unstable systems instead of one modernized system. The better approach is to start the change at a functionally clear and business-relevant point.

In this example, the availability and inventory information is a suitable candidate. It is heavily used, needs to respond quickly, and has a clearly defined task. An independent service can take over stock information from the ERP, process it, and provide it for the shop and customer portal. The monolith remains the leading system for orders and billing for now. The new function is consumed via an API while the existing system is gradually relieved.

The Path from Grown Application to First Service

At the start, there is no technology decision, but a solid inventory. Teams need to know which business processes are contained in the monolith, what data flows exist, and where real bottlenecks arise. Particularly important are the invisible dependencies: shared database tables, batch jobs, manual operational processes, and interfaces whose error behavior no one has documented.

Afterwards, a first service is selected in such a way that it meets three conditions: it solves a concrete business problem, its functional responsibility is understandable, and its decoupling does not jeopardize core operations. This could be inventory synchronization, but also notifications, document generation, or a search function. A service for "customers" is often too broadly conceived because customer data can have different meanings in sales, invoicing, and support.

For the inventory service, clear responsibilities are defined. It provides available quantities and timestamps, but it does not create orders or write invoices. The service receives its data via events or controlled interfaces from the ERP. If the ERP goes down temporarily, it can still deliver the last known inventory - visible as potentially outdated information. This decision is both functional and technical: for certain products, a delayed display is acceptable, while for scarce goods it may not be.

The database remains with the respective service. This is one of the most challenging parts of a microservices migration. A shared database may seem practical in the short term, but it leads to services remaining implicitly coupled. Having their own data storage does not mean duplicating data without defining rules. It means consciously shaping data ownership, updates, and error cases.

Platform Operation Determines the Benefits

A single decoupled service brings little value if its operation generates more manual effort than the monolith. That is why the target platform must be included in the migration scope from the first productive service onward. Containerization alone is not enough. Teams need reproducible environments, automated deployments, traceable configurations, and a security basis that does not have to be rechecked with every release.

In practice, this includes a CI/CD pipeline with automated tests, security checks, and traceable artifacts. Infrastructure as Code ensures that development, testing, and production environments do not diverge. Kubernetes can be useful for scaling and standardized operation but is not mandatory for every company. With few services and manageable load, a leaner managed approach may be more economical. The platform must fit the complexity of the product and the available operational model.

Equally early, the new service observability is necessary. Metrics show response times, error rates, and delays in ERP synchronization. Central logs help to trace a failed call across multiple components. Traces become relevant as soon as a user request passes through several services. Without this transparency, migration merely shifts errors into a landscape that is more difficult to diagnose.

For the B2B retailer, a productive KPI could be: the inventory service must handle 99.9 percent of its requests within a defined response time. Additionally, it is monitored how old the inventory data is. This way, the operations team can recognize not only a technical failure but also a functionally critical delay in data provision.

What Changes After the First Productive Step

Once the inventory service is stable in operation, the company benefits directly. The customer portal can display availability without burdening the monolith with every request. The function can be scaled independently. Adjustments to caching, display formats, or synchronization intervals can be delivered in a smaller release cycle.

At the same time, new responsibilities arise. Teams must manage versions of APIs cleanly, clarify responsibilities for disturbances, and document operational knowledge. A fault in a distributed architecture does not always manifest as a clear failure. It can occur as a delayed message, double-processed order, or conflicting data state. Therefore, business processes need mechanisms for retries, idempotent processing, and controlled compensation.

Only when the first service functions both technically and organizationally does the next domain follow. In this example, product data or search could follow, as these functions also cause high load and can be developed independently. Order processing may remain in the monolith longer because it consolidates many critical business rules. This is not a sign of an incomplete migration but a conscious prioritization based on risk and benefit.

When Microservices Are the Wrong Answer

Microservices are not a quality characteristic. If an application is manageable, a team masters it well, and releases run reliably, a modularly structured monolith may be the better solution. It is easier to test, easier to operate, and requires less distributed infrastructure.

Even in a migration under high time pressure, caution is warranted. If a company must first solve stability problems, unclear responsibilities, or missing release automation, it should prioritize these fundamentals. A monolith with a clean CI/CD pipeline, monitoring, and clear module boundaries can already enable significantly faster releases. Microservices enhance good engineering practices but do not replace them.

The cost question must also be on the table. More services mean more pipelines, more runtime components, more monitoring, and a larger security surface. Therefore, a viable architecture considers FinOps from the outset: resources are appropriately sized, costs are transparently allocated, and scaling rules are regularly compared with actual usage.

A successful migration is not measured by the number of containers but by the fact that functionally important changes become planable again. Those who start with a well-defined domain, consistently automate production operations, and measure each further decoupling by business benefits modernize without jeopardizing the stability of ongoing business.