Spring2quarkus

Step 2 — Ask clarifying questions

Before estimating, ask the essential questions to assess migration complexity:

1. How many developers work on this project and what is their familiarity with Quarkus/CDI?
2. Are there custom Spring framework extensions or auto-configurations?
3. Is reactive programming (WebFlux, Project Reactor) already in use?
4. What test coverage exists (unit, integration, end-to-end)?
5. Are there external libraries with no Quarkus equivalent?
6. What are the non-functional requirements (startup time, memory footprint, native image)?
7. Is there a target go-live date or migration window?

Step 3 — Identify critical dimensions

Analyze and document:

• Technical risks: Spring-specific abstractions with no direct Quarkus equivalent (e.g., Spring Batch, Spring Integration, Spring Cloud Gateway)
• Paradigm shifts: annotation-based DI (Spring) → CDI/Arc; @Transactional semantics; reactive vs. imperative
• Organizational risks: team upskilling needs, parallel running period, feature freeze constraints
• Data risks: schema migration, Flyway/Liquibase compatibility, multi-datasource setups

Step 4 — Propose a migration strategy

Structure the migration in phases:

1. Bootstrap – Initialize Quarkus project, configure extensions (quarkus-resteasy-reactive, quarkus-hibernate-orm-panache, quarkus-security, etc.)
2. Domain model – Migrate entities, repositories (Spring Data → Panache)
3. Business logic – Services, components (Spring beans → CDI beans)
4. API layer – Controllers (Spring MVC → JAX-RS / RESTEasy Reactive)
5. Security – Spring Security → Quarkus Security / OIDC / SmallRye JWT
6. Messaging / async – Spring AMQP/Kafka → SmallRye Reactive Messaging
7. Configuration – application.properties/application.yml → Quarkus config (%prod, %dev profiles, MicroProfile Config)
8. Tests – JUnit + Mockito → @QuarkusTest, @QuarkusMock, RestAssured
9. Build & CI – Maven/Gradle Quarkus plugin, container image, native build (GraalVM)
10. Cutover – Blue/green or feature-flag strategy for production switch

Step 5 — T-shirt sizing per migration step

For each phase/component identified, assign a complexity using the reference abacus:

Present a sizing table with one row per migration phase/component so the user can communicate estimates to their manager.

See the detailed reference for mapping of common Spring → Quarkus equivalents.

Output format

At the end of the analysis, provide:

1. Functional summary (3–5 bullet points)
2. Critical risks (ranked by severity)
3. Recommended migration strategy (phased plan)
4. Sizing table (phase → size → effort → rationale)
5. Quick wins (XS/S items to tackle first to build momentum)