Recommendations for migrating a legacy web app to a modern framework.

Question

Hello all,

I am currently doing some work for a company that runs a legacy web app built on Java Servlets (the system pre-dates JSP's, although they now use them when building new pages). The code base is a big jumbled mess as its around 10 years of building on top of an out of date framework. They have very little consistency in the code base(the app has been developed by various people over the years, most of which no longer work here), no concept of DRY (every page is basically created from scratch) a lot of unreadable / cryptic code and just in general a very inconsistent infrastructure.

As I have been working here I have been adding in modern features / trying to clean up the code base a little bit. I added some jQuery to where I was exposed, introduced a bit of security with input validations, cleaned up some of the modules to employ unobtrusive JavaScript principles etc. My work here is on new modules so I am not exposed to a lot of the old logic. I have tried to introduce best practices to all my work under their current infrastructure but I am forced to call a lot of their old code to make my stuff consistent.

They have reached a point where they are now considering a massive update to the system. They want to improve the maintainability of the code base and attempt to move to some sort of modern framework / MVC type application. A lot of the system predates XHTML with inline stylistic markup, javascript:function() calls, no unit testing, predates Hibernate, etc. There is a mix of out.println html generation and calling jsp's from within the Servlet.

Some apps they have been looking at include Wicket, Struts, Tapestry and possibly Grails. The problem is, the move to any of these may require a huge rewrite of a system that is already in use and they cannot afford to start over.

My question is: What would be the best way to migrate a legacy code base such as this to a more modern framework while keeping the existing business logic (no sense in rewriting stuff that has been tested and works).

Some of the ideas being thought of include:

• write an in house templating system that would work with their current infrastructure (generate pages in a consistent way)

• port code to a framework such as tapestry (reusing a lot of their old code)

• rewrite system from scratch using a modern framework but copying over logic from old system (if possible)

• keep the old system as is and just update the front end pages to give it a more modern look (might be best given time/money etc.)

what is the best way to update legacy Java Servlet code to a modern framework (using modern practices for easy maintenance, unit testing, DRY) while keeping the logic intact?

any insight is welcome.

Answer 1

The best way: Use the existing app as a functional specification and build the new app from scratch (with some possible cut-n-paste reuse or actual class reuse where it makes sense).

From my experience, trying to shoehorn a poorly written legacy app into a new framework or trying to "wrap" junk code with good code just results in something that is even more difficult and expensive to maintain in the long run.

Answer 2

Refactor the hell out of it, working toward a consistent style of design, as a preliminary to porting it over to the framework closest in spirit to whatever that style ends up being.

By "refactor" I mean - introduce tests in strategic locations, unit as well as functional, and work like mad to reduce duplication, leaning on these tests.

Answer 3

There is not a clear answer for this kind of question, but my main tip would be to first read up on the subject. Read books by people that know the stuff they are talking about.

For example, Code Complete (Steve McConnell), ch. 24 Refactoring.

• Save the code you start with

• Keep refactorings small

• Do one refactoring at a time

• Refactor when you add a routine, class, fix a defect

• Define an interface between clean and ugly code

• ...

There are many other resources, printed and online, that you can use. Afterwards, if you have a more specific question, you can use sites like SO to get a more useful answer than this one.

Answer 4

I asked a very similar question a few months ago, some of the answers might be useful for you:

What is the best way to migrate an existing messy webapp to elegant MVC?

Answer 5

this is just my opinion, because i think this question is what people pay expensive consultants to work out (and usually end up just wasting money! see thedailywtf.com for examples).

I think its not worth a complete rewrite, because during the process of rewriting, you might have to also maintain the original app*, and thus the rewrite will have a moving target. the better way is to pay off code debt as you refactor - i.e., it will take 2x, 3x or even 10x the effort to implement one simple feature, simply because doing it in a nice way involves refactoring heaps. but this effort is needed, as the debt owed in this app is high, and eventually have to be paid somehow.

it may hurt, but good medicine hurts.

• if you are given a good chunk of time to do the rewrite, i.e., the original app is frozen and not maintained (not even bug fixes), then it might work as a complete rewrite into whatever framework you deem fit. but i highly doubt this is going to be the case in any institution.