Morph by Modelcode (modelcode.ai) is an AI platform for monolith to microservices migration that takes on the execution work: once your architects settle the service boundaries, it moves one capability at a time through milestones your team approves, delivers each one as pull requests, and can check the new service against the monolith’s recorded behavior before you merge.
The video below follows one extraction from the dependency map to the merge in under two and a half minutes.
What should an AI platform do in a monolith to microservices migration?
It has two jobs. The first is to give your architects evidence for the boundary decision without taking that decision away from them. The second is to carry out the extractions those boundaries imply, proving at each step that callers see no change. A tool that proposes boundaries and then hands back unverified code leaves the hardest part to your team. A tool that only translates code leaves the sequencing, the cutovers and the verification to people.
Mapping the dependencies across every repository
Where to cut is an architecture decision, and it stays with your architects. What a platform can add is a picture of the actual wiring. Modelcode’s documentation says Morph detects dependencies and architecture across repositories and, on full-stack projects, follows the dependencies that run between backend services and the UI layers calling them. That matters in a decomposition: a module that looks self-contained on the backend can still feed screens kept in a separate frontend repository, and a boundary drawn without that link usually surfaces as a broken page after the cutover.
Morph handles the shape a decomposition takes: one or many source repositories into one or many target repositories, with monolith to microservices decomposition and service extraction listed among the supported transformations. Teams that want help finding the seams sometimes add a runtime analysis tool before the plan is written; vFunction, for example, pairs runtime insights with its own analysis to turn monoliths into modular services.
Step 1: the plan becomes a Project Spec your team approves
The boundary decisions are written into the Project Spec, the document that describes how Morph will transform the code across the repositories in the project. Its Repo map lists each repository before and after the migration and what happens to it: edited in place, kept read only, created new, or fully migrated. In a decomposition, the new service repositories show up there, and Morph creates them only when the spec is approved. Before that, your team can refine the spec in Knowledge chat, run Auto-review to compare it with the codebase analysis and your stated intent, and pull in anyone likely to catch a missing constraint. Approval starts roadmap planning: an ordered sequence of milestones.
Step 2: each extraction runs as approved milestones
In the video, one extraction takes three moves: an empty service is stood up, the capability’s code moves into it, and callers switch to its interface, each move being its own milestone. On the platform, the roadmap sets the milestones from the approved spec, and every milestone follows the same cycle. Before any code is generated, your team reads the Milestone Spec (scope, relevant files, design decisions and risks), adjusts it if needed and approves it; while earlier milestones are still unmerged, the next one can be read but not approved. Inside a milestone, the agent splits the work into tasks, commits after each one, and the milestone ends in one or more pull requests. Each milestone delivers a working increment, so the migration can pause after any extraction with a system that still runs.
Step 3: the new service is checked against the monolith
Validation depth is a project setting. At the Low level, Morph checks the build and runs the tests without starting either application; at Medium, it runs the migrated application; at High, it runs the original first, captures a baseline, and verifies the target against it. That last level is the one the video shows. On the backend, testing agents read the source, start the application and capture how its APIs and CLIs respond. For an API test, the same method, headers and request body go to both versions, and the status code and response body are compared. The tests run against the pull request branch, so the comparison is in front of reviewers before the merge.
A failing test opens a review issue on the milestone automatically. When the two versions differ for an expected reason, such as a version bump, an agent-written note says so, which keeps real regressions easy to spot. In a multi-repository project, each repository’s tests are tracked and reported separately, so every new service keeps its own record.
Step 4: later extractions re-check the earlier ones
From the second milestone onward, Morph re-runs the functional tests accumulated from every previous milestone as a regression suite, after the current milestone’s own tests. In a decomposition, extracting the fourth service re-tests the behavior proven when the first three left the monolith. A regression failure is surfaced rather than blocking the current milestone, because the right fix may belong to either one and that call is yours.
Step 5: review lessons and rules carry forward
When a milestone merges, a background Milestone Learning task reads the merged pull request (review comments, inline feedback, the final diff, your follow-up commits) and writes what it learns back to the project as wiki updates and new rules, which start as drafts until you publish them. Rules are included in the context of every task in every milestone, so a convention your reviewers enforce on the first service, say how services handle errors or receive their dependencies, applies to each service extracted after it. The merge stays with your team: nothing reaches your mainline without your explicit approval, and the final pull request presents the whole migration as one reviewable unit.
Questions to ask any AI platform for this migration
Does it show dependencies across all the repositories involved, frontend included?
Can we edit and approve the plan, and each step, before any code is generated?
Does every step land as pull requests that our reviewers read like any other change?
Is the new service compared with what the monolith actually returns, or only with tests written after the fact?
When a later step lands, are the earlier steps tested again?
Does a correction we make once reach every service that follows?
FAQ
Can an AI platform decide where to split a monolith?
It can inform that decision, not own it. Morph maps dependencies across repositories, including the links between backend services and UI layers, so architects draw boundaries on evidence. The boundaries, and the plan built on them, are approved by your team in the Project Spec before work starts.
How do you extract a microservice without breaking the monolith?
One capability at a time, in the order the approved plan sets, with every step delivered as a working increment your team reviews. Morph lets the next milestone be approved only after earlier ones merge, and it re-runs earlier tests as later work lands.
Which languages and application types does Morph support for a decomposition?
Source or target languages include Java, C#, Python, Go, PHP, Ruby, Kotlin, Scala, Rust, C, C++, Groovy, Clojure, Ada, Node.js, TypeScript and JavaScript. Targets can be RESTful services, CLI tools or full-stack applications. Native mobile apps, desktop GUI applications and plugins are not supported as migrations today.
For why decompositions fail differently at the boundary and at the move, read Monolith to Microservices: the Deciding Half and the Executed Half on this blog.
Learn more about Morph: https://modelcode.ai/?utm_source=substack&utm_medium=blog&utm_campaign=video3_companion