###The following issues are more important that where to put code on the disk or in an artifact:

If you don't understand that, you have already failed.

###What you describe is not refactoring, it is rewriting using a more palatable name:

Unless you have 100% code covered in unit tests already, someone(s) are going to get fired over this when (not if, when) this effort fails spectacularly, probably multiple times!

Even with awesome unit tests, someone is going to miss something. Someone is going to take the fall when it finally gets discovered in production, usually after months of silently corrupting data.

###Semantics are Important:

Removing Struts and replacing with Spring is not **refactoring** is **rewriting** by definition. Refactoring would be moving from Struts 1.1 to 2.0, replacing Struts means replacing all the Struts code with something else, by definition that is **rewriting** not refactoring.

###Working Software comes in many disguises:

The business always thinks what they have is *working*.

If you miss a deadline, introduce a minor bug, lose the smallest feature, misinterpret an undocumented process and *change* something, no matter how minor, even for the better, they will look for any problems, weaknesses or potential trouble to spread FUD and make sure your effort is a failure, at least most of the time.

All these things will cost you and your team political capital, someone will take the fall for these things, no matter how innocent or meritless the perceived failures are!

###Projected outcome:

Most likely you and/or other "non-Java" developers (and not the core Java people that created this working system that you "non-Java" people "refactored", and delivered on time broken and incomplete, or didn't deliver on time or didn't deliver at all) will pay the price.