We're in the midst of a major legacy migration from Java to Spring, which has been put off for years due to uncertainty about the scope and effort involved. To help unblock the project, I'm exploring what kind of solution would be most effective for the team. I'm imagining a 'Risk Intelligence Service' that provides a comprehensive Upgrade Strategy Report after reviewing our repo; this would include details on what breaks, identify test gaps, and lay out a step-by-step migration plan (like which libraries to upgrade first). I'm curious: if you had a budget of $3k-$10k, what would be the best investment for handling this migration?
1. **Option A (The Map):** A detailed analysis report that outlines exactly what needs to be done so the developer team can focus on implementation without wasting time on research.
2. **Option B (The Driver):** A service that comes in to handle the refactoring and upgrades directly, delivering a clean pull request.
3. **Option C (Status Quo):** Stick to what we know and tackle the migration in-house, despite the pain.
Is this a knowledge bottleneck or an issue of capacity to get the work done?
5 Answers
I think you can handle it in-house. Spring migrations have plenty of documentation. Just take it slow and be sure to read all the release notes as you go. Options A and B might not be the best in the long run since your team wouldn’t gain enough knowledge.
I’ve been through this before. Option A is only effective if the team already knows what they’re doing. The real challenges often come to light only during the migration, so having someone experienced to consult with would have made a big difference for me. I suggest starting with one of the templates from Spring Initializr and integrating your code from there.
I’d go with Option C. Upgrading works best when you take it one piece at a time. It requires some commitment but can be manageable if you keep track of library release dates; they can provide hints on compatibility.
I lean towards Option C, but I think it’s time to consider rewriting from scratch. If you’re working with a monolith, transitioning to a service-oriented approach with a newer stack might be the way to go. Upgrades to Spring Boot can be a hassle, especially when sticking only to minor upgrades, which can cause bigger issues later on. That budget you mentioned really limits your options; proper migration could take months, maybe even a year, which far exceeds that budget limit.
Honestly, Options A and B seem similar to me. If you understand the changes needed (like in Option A), you should just implement them directly (like in Option B). It might actually be less work to just create a pull request.
Rewriting from scratch usually turns out to be more troublesome than expected.