Migrate from Spring to Quarkus
What you need to know to move to Quarkus.
DI, REST controllers, data repositories, application.properties — many Spring concepts map neatly to Quarkus equivalents. You can get your Spring applications running on Quarkus by making (small!) adjustments to code that interacts with the framework, or by using compatibility libraries. Whichever way you go, there's lots of help available, including AI skills, migration tooling, and documentation.
AI-Driven Migration
AI skills give a coding agent a structured task to follow — the Quarkus Migration Skill does that for a Spring Boot to Quarkus migration. Point it at your app, and it inspects your codebase, migrates what applies — build files, REST controllers, dependency injection, data access, security, configuration, tests — flagging decisions for you along the way, then commits the result and opens a draft PR.
Best for: anyone who wants a concrete answer to “what would this actually take?” — on a real service, in an afternoon.
npx skills add quarkusio/skillsFrom your project root, prompt your agent: “Migrate this Spring Boot app to Quarkus.”
You can choose to use either target — native Quarkus APIs or Spring compatibility extensions (covered next).
Get the Quarkus Migration Skill
Also in the AI-assisted family
General AI coding assistants
Claude Code, Cursor, GitHub Copilot, Bob, and other coding assistants can translate Spring code with the right prompts. Konveyor AI adds IDE-integrated static analysis for teams already using Konveyor or MTA.
Konveyor AI (Kai)
Combines generative AI with static code analysis to assist migration directly in your IDE. Uses a RAG-based approach with historical migration data to provide context-specific guidance, without requiring model fine-tuning.
Two destinations, your choice
Whichever tools you use, there’s one decision to make: what should the migrated code look like? You can start with one and move to the other incrementally.
Native Quarkus APIs
Migrate to Quarkus’s own APIs: Jakarta REST for endpoints, CDI for dependency injection, Panache for data access. The concepts are the ones you already know — @Inject instead of @Autowired, @Path instead of @RequestMapping, and so on. In our experience most teams adapt to the new APIs quickly.
What you gain: the full performance of Quarkus — faster startup, lower memory, first-class native compilation — plus idiomatic code that most Quarkus guide, extension, and community answers are written for.
Best for: new services, services you’ll maintain for years, and teams ready to invest a small amount of learning for the full payoff. This is where most migrations end up — the only question is whether you go there directly.
Trade-off: some parts of your codebase will look less familiar, and the diff for the migration will be larger.
Spring compatibility extensions
Keep your Spring annotations and patterns — @RestController, @Autowired, JpaRepository, but running on the Quarkus runtime. The build plugin and BOM change, property names change, but your code largely stays as it is. The best bit? Your code doesn't change, but its performance does. A lot. (For the better!)
What you gain: the quickest route to Quarkus with near-zero code cognitive load. Your team stays productive on day one while still getting a leaner, faster application.
Best for: getting a service onto Quarkus fast, teams that can’t absorb any extra learning right now, and as a first step in an incremental migration.
Trade-off: coverage isn’t total, and you leave some performance and ecosystem benefits on the table until you complete the move to Quarkus's own APIs.
Spring compatibility extensions reference
| Extension | Covers |
|---|---|
| Spring Web | @RestController, @RequestMapping, @GetMapping |
| Spring DI | @Autowired, @Component, @Service |
| Spring Data JPA | JpaRepository, CrudRepository, derived queries |
| Spring Data REST | Automatic CRUD endpoints from repositories |
| Spring Security | @Secured, @PreAuthorize |
| Spring Cache | @Cacheable, @CacheEvict |
| Spring Boot Properties | @ConfigurationProperties |
| Spring Scheduled | @Scheduled periodic tasks |
| Spring Cloud Config | Spring Cloud Config Server client |
Deterministic and specialized tools
The Migration Skill handles the general case. These tools shine in particular ones — large portfolios, bulk mechanical changes, or when you want to understand every rule yourself.
| Tool | What it does | Best for |
|---|---|---|
| Migration Toolkit for Applications (MTA) | Rule-based analysis (built on Konveyor) that reports exactly what needs to change in your app, with guidance for each issue. Web console, CLI, Maven plugin, or IDE plugin. | Sizing the effort across a large portfolio before committing; teams that need an assessment report for planning or stakeholders. |
| OpenRewrite | The SpringBootToQuarkus recipe automates dependency swaps, annotation changes, and configuration migration deterministically via Maven, Gradle, or CLI. |
Applying the same mechanical changes across many similar services; teams that prefer repeatable, rule-based transforms over AI. |
| Snowdrop Migration Guide | A structured manual guide with rules and decision flowcharts for Spring Boot 3.x Quarkus 3.x, covering both destination strategies. Includes Konveyor analysis rules. | Understanding exactly what changes and why; handling edge cases that automation misses. |
Common questions
- Do I have to migrate everything at once?
No. Migrate one service, and within it, run compatibility extensions and native APIs side by side — incrementally, even class by class, as it suits you.
- How much do I have to relearn for Quarkus-native APIs?
Not much —
@Injectinstead of@Autowired,@Pathinstead of@RequestMapping. Most developers are productive within days.- Is the Quarkus ecosystem mature enough?
Quarkus has hundreds of extensions built on proven projects like Hibernate, Vert.x, and RESTEasy, with a large, active community behind it.
- What if my app uses Spring features the compatibility extensions don’t cover?
You migrate just those parts to their Quarkus equivalents — everything else can stay on compatibility extensions.
- Can I combine these tools?
Yes — many teams run MTA first to scope the effort, then use the Migration Skill or OpenRewrite to do the work.
- Where do I start?
Run the Quarkus Migration Skill on one service and review the draft PR it opens.
For more guidance, the free Quarkus for Spring Developers e-book explains the similarities and differences between the two frameworks, and helps you map Spring Boot concepts to their Quarkus equivalents.
