Run gradle init in the root of the Maven project. Gradle parses the POMs and generates build scripts, a settings script for multi module builds, the repositories listed in the POM, and your dependencies. It does not convert assemblies, and plugin coverage is limited. Treat the output as a first draft and review every dependency line.
What the conversion produces
The Gradle migration guide says the automatic conversion creates the build files you need, even for multi module builds. The new build includes the custom repositories specified in the POM, external and inter project dependencies, and the plugins needed to build the project, limited to the Maven Publish, Java and War plugins. For simple projects it may be ready to run.
The same guide is clear about gaps: assemblies are not automatically converted and need manual work, such as the Distribution plugin, the Application plugin or custom archive tasks.
Steps
- Keep the Maven build working in place. The guide recommends keeping the old and new builds side by side until the Gradle build produces the same artifacts.
- Run the conversion from the project root.
- Run a build and read the failures.
- Review dependencies line by line (below).
- Replace Maven plugins with Gradle equivalents one at a time.
- Compare outputs against the Maven build before cutting over.
gradle init
gradle build
Review the dependency output
The conversion is mechanical, so the security review is yours. Look for:
| Item | Question to ask |
|---|---|
| Scopes | Did compile, runtime, test and provided land in the right Gradle configuration? |
| Exclusions | Was the original reason preserved? See migrating Maven exclusions to Gradle |
| Version management | Did dependencyManagement become a platform or constraints? |
| Repositories | Are only intended repositories present? |
| Resolved versions | Do they match the Maven tree? See version shift between Maven and Gradle |
Expect output differences
The guide notes that generated POMs from Gradle contain only the information needed for consumption, and that file order in archives and on classpaths can differ. Most differences are minor, but identify and verify them. A changed classpath order can matter when two jars contain the same class.
Lock it down afterwards
Once the Gradle build matches, turn on dependency locking and consider verification metadata so the new build is as pinned as the old one. See how to turn on Gradle dependency locking and bootstrapping Gradle dependency verification safely.
Safeguard's dependency scanning and SBOM generation can inventory the Maven build and the Gradle build for comparison. Try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the direct and transitive split, which you should compare across the two builds.
Quick check
Does gradle init convert Maven plugins?
Only a limited set. The guide says the Maven Publish, Java and War plugins. Others need Gradle equivalents or custom work.
Should I delete pom.xml after converting?
Not until the Gradle build produces the same artifacts and has shipped a release. The guide recommends keeping both side by side.
Sources
Last reviewed: 19 October 2026.
