The same app,
cut along lines that actually make sense
A monolith that has grown for years without clear boundaries is not usually a candidate for a full rewrite, which 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, with tests written first so each cut can be verified rather than hoped for. We rebuilt a factory ERP's core this way after it was recovered from a lost cloud account, piece by piece, staying live the whole time.
What it is
A monolith-to-modular refactor takes an application where everything, data access, business logic, presentation, for every feature is tangled together in one codebase with no clear internal boundaries, and reorganizes it into distinct modules, each owning one business domain, orders, billing, inventory, with explicit, limited interfaces between 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 you need it (and when you do not)
It earns its cost when changing one feature routinely breaks an unrelated one because the code paths are entangled, when onboarding a new developer takes weeks because nothing in the codebase indicates what depends on what, or when you are recovering a system that has drifted for years without anyone maintaining its structure. A factory ERP we rebuilt after a lost cloud account needed exactly this: a self-hosted rebuild where getting the module boundaries right mattered more than shipping fast, since 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 that is 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, since the first goal of a refactor is preserving behavior, not silently changing it. Each module is then extracted one at a time: move the code, keep the tests passing, verify the app still deploys and runs correctly, and only move to the next module once the current one is confirmed stable. 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, which 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, since 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, so 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 and the D2C store Thailand audit and 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, since 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 that nobody remembers the reason for until it breaks. We refactor in place, module by module, verified by tests, which 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, since 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, for 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, which we assess 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.