Break the monolith apart without stopping the business.
For monolithic applications that have grown over the years where every change becomes risky, deploy is an epic event, and new features take months. We decompose the monolith into smaller services with the strangler pattern: progressive refactoring, no big-bang, no business risk.
What happens today.
Many applications born as clean projects become rigid monoliths after 5-10 years of evolution: huge files, opaque dependencies, unexpected side effects. Every new feature takes months because any change risks breaking something else. Deploy is an epic event, rare and full of fear.
Rewriting from scratch is almost always a mistake: accumulated knowledge is lost, you find yourselves fragile mid-flight, the business asks for new features while you 'work on the rewrite'. The strangler pattern offers a concrete path: the monolith stays operational, new features are built into separate services, parts of the monolith are progressively replaced by the new code.
Serious refactoring is not a break from the business. It is business as usual, done better.
The solution, broken into parts.
-
Audit + dependency mapping
We map the monolith: modules, dependencies, hot paths, dead parts. We identify natural boundaries to extract services, and the modules with the highest refactoring ROI.
-
Progressive strangler pattern
We extract one service at a time. The monolith keeps running; the new service takes over a specific function (e.g. authentication, billing, notifications). An API gateway routes traffic. The monolith loses surface area module after module.
-
Modernized test + CI/CD
We add automated tests where needed (on modules to be refactored), CI/CD pipeline, structured monitoring. Deploy stops being an epic event, becomes an ordinary procedure.
The typical profiles who benefit.
-
SaaS companies with a legacy codebase
Software products born 5-10 years ago, today monolithic. New-feature development is slow, accumulated technical debt weighs, developer experience is declining.
-
SMEs with 'historical' custom apps in production
Custom applications built for the company years ago, today monolithic and fragile. Every change takes weeks of manual testing. Refactoring unlocks future evolution.
Transparency on what the client does.
Before we start we need a few accesses and decisions. All reasonable, no surprise asks.
-
System access
- Access to source code and staging environment
- Bug fix and incident history to identify the most fragile modules
- Internal team available for knowledge transfer
-
Scope decisions
- Which modules to refactor first (based on business value)
- Compliance constraints (GDPR, NIS2, audit)
- Target final architecture (refactored monolith vs separate services vs microservices)
Indicative numbers, not quotes.
- TIME
- Audit 4-6 weeks. Progressive refactoring 6-18 months depending on scope.
- COST
- Audit €15,000-30,000. Full refactoring €80,000-400,000.
- MODEL
- Audit on fixed milestone. Refactoring in modules with go/no-go at every phase.
Indicative numbers. For an accurate quote, let's talk.
Answers to the most common questions.
Is it better to refactor or rewrite from scratch?
Almost always refactoring. Rewriting from scratch has a high failure rate: accumulated knowledge is lost, you get fragile mid-flight, the business doesn't wait. Progressive refactoring lets you evolve without stopping the company, and after 12-24 months you typically have a system that is 'as if rewritten' without the rewrite risk.
Microservices yes or no?
It depends. Microservices make sense when the team is big enough to manage them (>15-20 developers) and when responsibility boundaries are clear. For smaller teams, a well-modular monolith (sometimes called "modular monolith") is often the better choice. Case-by-case, no dogmas.
Can we keep developing new features during refactoring?
Yes, and it is the preferred pattern. New features are developed in the new services (not in the monolith), so refactoring proceeds naturally alongside product development. Only critical changes on the monolith are coordinated so as not to slow the refactoring.
Recognize your case?
Write a couple of lines about your context. We'll reply within 24-48 hours with an initial assessment and a first orientation on time and cost.
Let's talk