Morph by Modelcode (modelcode.ai) integrates with CI/CD through the path your team already trusts: every migration step lands as a pull request in the repository you already use on GitHub, GitLab or Azure DevOps, so the pipelines you already run test it like any other change. Nothing reaches your mainline until those checks pass and someone on your team merges it.
What should “CI/CD integration” mean for an AI migration?
For most engineering teams, the pipeline is the definition of done. A change that skipped it is a change nobody can vouch for, however clean the code looks. So the useful question about an AI modernization tool is not whether it ships a CI/CD plugin. It is whether its output enters the same path as human work: a branch, a pull request, the existing build and test jobs, a reviewer, a merge.
A tool that hands back an archive, a patch to apply by hand, or a rewritten repository in its own console leaves that integration work to your team. A tool that delivers through pull requests inherits your pipeline from day one.
How does Morph fit into an existing pipeline?
Morph works on a dedicated feature branch (morph-main by default) and splits the migration into milestones. Each milestone runs on its own branch and ends with a pull request back to the feature branch. From there, Modelcode’s documentation is explicit: CI/CD checks run on those pull requests automatically, your existing pipelines run against the changes, and you merge once the checks pass.
Three mechanisms sit on top of your pipeline:
Acceptance criteria. These are quality gates the Morph Platform checks on every milestone pull request. Two are built in when your lifecycle defines them: the build must succeed, and the test suite must pass. Teams can add deterministic thresholds of their own, such as zero lint warnings, a minimum line coverage, or zero high-severity audit findings. A failing criterion shows up as a reviewable issue instead of silently blocking the work.
The lifecycle. With an agent’s help, your team writes the scripts that install dependencies, build, start, health-check and test the application, plus a smoke script that exercises it enough to show it really works. Smoke is mandatory on the original application: until a smoke run passes there, Morph does not consider the setup validated. The same scripts run first against the original code, which becomes the behavioral reference, then against the migrated code, and the Validation Hub puts the behavior of the two applications next to each other.
Ordered merges. The next milestone stays locked until each pull request from the current one is merged or closed, so a red pipeline pauses the migration instead of letting new changes pile up on top of a failure.
Once every milestone is merged, Morph opens one final pull request from the feature branch to your target branch: the entire migration as a single reviewable unit, which your team can run through CI/CD and merge when ready. Morph ships the integration tests it used to verify each milestone along with the code.
What runs where?
On a Modelcode Hosted project, builds run in a container image built from the project’s Dockerfile. When the application depends on internal APIs, databases, private package registries or licensed services, the self-hosted ModelDaemon runs the build, run and test steps on a machine inside your network. The daemon only opens outbound connections, so the machine stays unexposed and your firewall keeps its inbound rules as they are.
Repositories connect through a GitHub App, through GitLab (gitlab.com, a self-managed server or a GitLab Dedicated instance), or through Azure DevOps with Microsoft Entra ID.
Where other approaches land
Recipe-based refactoring sits naturally in CI for mechanical changes. OpenRewrite recipes run from Maven or Gradle build plugins, and the Maven plugin’s dryRun goal can act as a gate: with failOnDryRunResults turned on, the build fails whenever a recipe would still change the code. On Moderne, the commercial platform built to run the OpenRewrite recipe catalog, running a recipe does not touch repositories by itself; the team chooses what to commit, directly or as a pull request.
General coding agents can open pull requests as well, but how much of the pipeline their work goes through depends on how each team wires them in. The distinction worth checking on any shortlist is whether CI is the default path for every change, or an option someone has to remember.
Questions to ask any vendor
Will each change reach us as a pull request in a repository we own?
Do our existing pipelines run on those pull requests without extra setup?
Can we add our own thresholds (lint, coverage, audit findings) and see failures before anything merges?
When the application needs private services, can the build and test steps run on our own machines?
Does a failed check stop the migration, or does work keep accumulating behind it?
FAQ
Does Morph replace our CI/CD pipeline?
No. Morph delivers its work as pull requests, and your existing pipelines run on them as they would on any other change. Its acceptance criteria and lifecycle checks add migration-specific gates on top.
Which Git providers does Morph work with?
GitHub, GitLab (gitlab.com, self-managed servers and GitLab Dedicated) and Azure DevOps. Each completed milestone opens a pull request in the connected repository.
Who merges the changes?
Your team does. No change lands on your mainline until someone on your team approves it, and the final pull request lets reviewers see the whole migration before it lands.
For how Morph checks behavior milestone by milestone, see Verifiable AI Code Modernization: What It Means and How It Works on this blog.
Learn more about Morph: modelcode.ai