Migrate from Spring to Quarkus - 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 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.
From 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
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.
Hands-on walkthrough
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.
Learn about Konveyor AI
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.
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.
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.
Browse all Spring guides
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.
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.
Not much — @Inject instead of @Autowired, @Path instead of @RequestMapping. Most developers are productive within days.
Quarkus has hundreds of extensions built on proven projects like Hibernate, Vert.x, and RESTEasy, with a large, active community behind it.
You migrate just those parts to their Quarkus equivalents — everything else can stay on compatibility extensions.
Yes — many teams run MTA first to scope the effort, then use the Migration Skill or OpenRewrite to do the work.
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.
Quarkus is open. All dependencies of this project are available under the Apache Software License 2.0 or compatible license. CC by 3.0This website was built with Roq on Quarkus, is hosted on GitHub Pages and is completely open source. If you want to make it better, fork the website and show us what you’ve got.