Knowledge from practice

Notes from modernizing systems the business cannot stop.

The important part is not the technology alone, but the decision that reduces risk and moves responsibility without losing business continuity.

Each note begins with a real problem, explains the chosen direction and points to production evidence. Architecture recommendations stay connected to their delivery consequences.

Read the full ERP case study Discuss your system

Modernization strategy

Why rewriting a critical ERP is usually the wrong first move

A full rewrite combines the highest technical uncertainty with the largest possible release.

Problem

In a weakly documented ERP, business rules are distributed across people, code, databases and files. Sales, purchasing, warehouses and financial documents still need to operate, so the system cannot be frozen safely while every rule is reconstructed.

Decision

First stabilize delivery and observability, map the process and its truth sources, then move one complete business responsibility into a domain with explicit contracts. Retire the old implementation only after every dependency has moved and the cutover is verified.

Result

In the automotive ERP, production OMS and SCM took over core workflows while sales, purchasing and warehouse operations remained available. The remaining domains are explicitly presented as work in progress rather than completed outcomes.

See the evidence in the case study

Operational excellence

How a risky one-hour legacy deployment became a reversible 40-second process

Modernization began by shortening and securing the risk window, not by replacing the application.

Problem

Legacy deployments depended on one person, took about an hour and made smaller changes difficult to deliver safely. Without a repeatable process, every further modernization step would increase operational risk.

Decision

The release became a short, repeatable and reversible automated sequence. Delivery stabilization, rollback, monitoring and backups came before extracting further responsibilities from legacy.

Result

Maximum reversible deployment time fell from about one hour to 40 seconds, turning the legacy release into a short, repeatable process.

See the evidence in the case study

Production ownership

Observability for business failures, not only servers

Healthy infrastructure is not enough when a critical process has stopped behaving correctly.

Problem

In the ERP environment, users often reported failures first. Technical signals did not provide one view across eight legacy systems, six new ERP components and their infrastructure.

Decision

Legacy and modern components gained one layer of logs, metrics and alerts, extended with visibility into business processes. Observability became a prerequisite for safely moving responsibility between domains.

Result

The signal moved from a user report to an automated alert arriving within seconds.

See the evidence in the case study

Your system

Are you facing a similar decision in a live system?

Bring the process, the production constraint and the failure the business cannot accept. We can identify which reversible step makes sense first.

Discuss your system