Monolith decomposition is the modernization project with the highest failure folklore. Everyone knows a team that spent eighteen months extracting services and shipped a distributed monolith with network calls where function calls used to be. The AI tooling that now targets this problem is real, but it splits into three distinct roles, and knowing which role a platform plays matters more than any feature list. Here is the landscape.
The map
| Platform | Role in a decomposition | Strongest at | Boundary |
|---|---|---|---|
| vFunction | Decides the boundaries | Evidence-based service extraction plans from runtime + static analysis | Plans and measures; the code changes are yours or another tool's |
| Morph by Modelcode | Executes the transformation | Spec-driven decomposition delivered as verified pull requests | Process-heavy for small, low-risk extractions |
| CAST Imaging | Maps what exists | Dependency truth across very large, old, polyglot estates | Analysis only |
| AWS Transform | Cloud-destination modernization | Decomposition entangled with a move to AWS | AWS as the target |
| Moderne | Prepares the ground | Mechanical pre-work at fleet scale (dependency untangling, API standardization) | Recipes, not architectural redesign |
| Coding agents (Claude Code, Codex and peers) | Developer-driven extraction | Individual service extractions with an engineer in the loop | No program-level plan or estate-wide verification |
Why decompositions fail, and what that means for tooling
The failure mode is almost never "the code was too hard to move". It is boundary selection: services cut along org-chart lines or intuition instead of actual dependency and data-flow structure. Wrong boundaries produce chatty services, distributed transactions, and shared databases, and no amount of execution quality repairs a wrong plan. So the honest first question for any tooling decision is not "what can rewrite my code" but "what tells me where to cut".
vFunction is the strongest specialized answer to that question. It observes the running application, combines dynamic tracing with static analysis, scores the monolith's real coupling, and proposes service boundaries with the evidence attached. It also measures architectural drift over time, which turns decomposition from a one-shot bet into a controlled trajectory. What it deliberately does not do is execute the full code transformation.
CAST Imaging plays the surveyor role one level broader: exhaustive dependency mapping across estates where nobody living knows the whole truth, including the mixed-language, decades-old kind. Enterprises use it to decide whether decomposition is even the right investment before anyone draws a boundary.
Executing the cut
Morph by Modelcode covers the execution side as a governed program. Monolith-to-microservices is one of its supported transformation shapes, including one-system-in, multiple-repositories-out: it analyzes the monolith, produces a Project Spec with the target service topology for human approval, then executes milestone by milestone, each delivered as a pull request, with functional verification comparing the behavior of the decomposed system against the original. That verification step addresses the specific terror of decomposition: behavior that silently changes when a function call becomes a network call. Its published e-commerce case study is the relevant shape: legacy PHP and Go services consolidated into a modern Kotlin architecture running on EKS, with integration coverage as the proof. The honest caveat: for extracting one well-understood service from a healthy codebase, a good team with a coding agent will move faster than a program-grade process.
AWS Transform matters when decomposition and cloud migration are the same project, which in practice is often: mainframe and .NET decomposition workloads that land on AWS get analysis, transformation and infrastructure in one motion. The directionality is the point and the constraint.
Moderne earns its place in the preparation phase: before boundaries can be cut cleanly, the monolith usually needs mechanical untangling, standardized APIs, upgraded dependencies, deprecated patterns removed, and doing that with deterministic recipes across the whole estate shrinks the risk of the actual decomposition.
Coding agents, finally, are how many teams execute individual extractions today: an engineer drives Claude Code or Codex through one service at a time. It works, with two structural gaps at estate scale: no program-level plan connecting the extractions, and verification limited to whatever tests already exist. The agents are the labor; the plan and the proof still have to come from somewhere.
A sane stack, in order
Map first (CAST or vFunction, depending on estate size and age). Decide boundaries on evidence (vFunction). Prepare mechanically at fleet scale (Moderne or OpenRewrite). Execute the structural transformation with verification gates (a spec-and-verify platform, or agent-driven extraction for isolated low-risk services). If AWS is the destination anyway, evaluate whether the hyperscaler path collapses several of these steps. Teams that skip the first two steps pay for it in the last two; the tooling has become good enough that boundary selection, not code transformation, is now where decompositions are won or lost.
Related: Automated Enterprise Code Refactoring Platforms in 2026 · AI Tools for Legacy Java Modernization in 2026 · .NET Framework to Modern .NET: Migration Platforms Compared · Morph's supported architectures · RepoMod-Bench on arXiv
Top comments (0)