The same app,
cut along lines that actually make sense
A monolith that has grown for years without clear boundaries is rarely a candidate for a full rewrite. A rewrite carries its own huge risk of breaking what already works. It is a candidate for carving out real module boundaries one piece at a time. We write tests first, so each cut can be verified, not just hoped for. We rebuilt a factory ERP's core this way, piece by piece, staying live the whole time.
What actually changes
A monolith-to-modular refactor starts with an application where everything is tangled together: data access, business logic, presentation. Every feature sits in one codebase with no clear internal boundaries. It reorganizes that into distinct modules, each owning one business domain: orders, billing, inventory. Explicit, limited interfaces connect them. The app can stay a single deployable unit, a modular monolith, or the modules can become separately deployable services, depending on what the team actually needs.
When this is worth doing, and when it is not
It earns its cost when changing one feature routinely breaks an unrelated one because the code paths are entangled. It earns its cost when onboarding a new developer takes weeks because nothing in the codebase shows what depends on what. It also earns its cost when you are recovering a system that has drifted for years without anyone maintaining its structure. A factory ERP we rebuilt needed exactly this. It was a self-hosted rebuild, and getting the module boundaries right mattered more than shipping fast. The system now had to run reliably every day without outside dependencies.
It is the wrong tool, or at least premature, for a young codebase still finding its shape. Refactoring a six-month-old product into formal modules often locks in boundaries before anyone actually knows where they should be. It is also not the answer if the real problem is a small team stretched too thin to maintain any structure. Modularizing the code does not fix a staffing problem.
How we build it
We start by reading the actual code and mapping its real dependencies, which is almost always different from what the folder structure suggests. A codebase organized into “controllers,” “models” and “views” can still have billing logic scattered across a dozen files with no clear owner. This map is the honest starting point for deciding where module boundaries should actually fall, around business domains rather than technical layers.
Before touching any logic, we write characterization tests that record what the current code does, bugs and quirks included. The first goal of a refactor is preserving behavior, not silently changing it. Each module is then extracted one at a time. We move the code, keep the tests passing, and verify the app still deploys and runs correctly. Only then do we move to the next module. This is slower than a rewrite in the first week and dramatically safer by the fourth.
We decide modular monolith versus full microservices based on your actual team size and deployment needs, not by default. A modular monolith gets most teams the organizational clarity they need without the operational cost of running, monitoring and deploying many separate services. That is why it is our default recommendation, unless a team genuinely needs independent per-module scaling.
What to watch
A refactor without tests first is not a refactor. It is a rewrite with extra steps and the same risk. We will not skip the characterization test phase even under timeline pressure, because skipping it is exactly how refactors introduce the regressions they were meant to prevent. Module boundaries drawn around the wrong thing, a technical split instead of a business-domain split, recreate the same tangled dependencies in a new shape within a year. This decision gets real discussion before any code moves. And a refactor that takes too long without visible progress loses organizational support. We extract and verify modules incrementally, so there is a working, improved system at every checkpoint, not one long branch that merges all at once.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Focused refactor | from $4,000 | Tests and modularization of the most tangled part of the system | 4 to 6 weeks |
| Full modularization | from $12,000 | Dependency mapping and modularization across the whole codebase | 8 to 10 weeks |
Running cost is unchanged from your current infrastructure. The investment is entirely in the refactor itself, not new hosting.
Related
This pairs with serverless backend architecture or micro-frontends for large teams once modules are cleanly separated and ready to be independently deployed. See the development service page for our full build process. For real examples, see the factory ERP recovery and self-hosted rebuild.
Is one tangled part of your codebase slowing down every new feature? Get in touch and we will read the code before proposing anything.
FAQ
How much does a monolith refactor cost?
From $4,000 for a focused refactor of the most tangled part of a mid-sized codebase, 4 to 10 weeks. A full modularization of a large, years-old monolith runs $10,000 to $25,000, scoped after we have actually read the code. Estimating this honestly needs that first.
Do you rewrite everything from scratch?
No, and we are wary of anyone who proposes that as the first option. A full rewrite risks losing years of accumulated bug fixes and edge-case handling nobody remembers the reason for, until it breaks. We refactor in place, module by module, verified by tests. That is slower to start but far less likely to introduce a regression that takes weeks to find.
How do you know what to test before refactoring code nobody fully understands anymore?
We write characterization tests: tests that record what the current code actually does, including its quirks, before changing anything. This gives us a safety net even when the original intent behind a piece of logic is not fully documented. The goal of the first pass is preserving current behavior, not fixing it.
Modular monolith or microservices?
A modular monolith, clear boundaries inside one deployable application, fits most teams. It gets most of the organizational clarity of microservices without the operational cost of running and monitoring many separate services. Full microservices earn their cost mainly for larger teams needing independent deployment and scaling per module. We assess this honestly rather than defaulting to the more fashionable answer.
What if something breaks during the refactor?
Each module extraction is a small, reversible step with tests run before and after, and a rollback plan if something does not verify cleanly. We would rather take ten small, checked steps than one large step that might work.