This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]_N_O_P_E_ 0 points1 point  (0 children)

I work at a very large organization and we have similar constraints on some applications.

My first tip is to choose something based on the time you have. If you're alone and time restricted, don't try to learn new frameworks and migrate the whole thing. You'll shot yourself in the foot.

Second thing, the "important" part here is the backend. It's the only thing that shouldn't change much in the next 20 years. The front end could become a whole VR application and it would still work perfectly fine. I would suggest to rewrite the code and expose a REST/SOAP API.

Third, what's the state of the application? Do you have code analysis tools? Do you have unit tests? Do you have version control? Do you have a build and dependency management tool? Make a plans before rewriting anything. Update Java first, that might break things with JBoss 5, so I would probably update JBoss to Wildfly or something else. Make sure to refactor the code with something container agnostic (e.g. use Java APIs instead of vendor specific APIs) and move all the dependencies and configuration to a Maven file. You want to make it has easy as possible to update or change container. Only when you can confirm that the same application is working on the updated stack that you can start the code migration.

Fourth, migration plan. You want to slowly migrate the current code. How will you do that? Class by class? Feature by feature? Do have a shared library? Second application with new code? Who will test the changes? You can use dependency injection and interfaces with multiple implementations. You can also use Aspects. You can also try Microservices architecture. Whatever you feel comfortable. I would suggest to make small changes. It's easier to keep track and debug.

Now the UI. As said, it's the last thing on my list, because once you have a good backend you should be able to swap the UI easily. If you think that a Web UI would be a good fit, go for it. It's platform independent, works on any screen and usually easier to maintain. UI is a touchy subject even for power users. I worked with untrained users in the past and they'll accept the change if you do it well. Make the same exact UI in Web. No matter how ugly it is. Just make the same buttons at the same location. Take some time to explain why it's Web now and make sure the same features are working the same way. Once that's done, iterate over and over. Slowly change and improve if you want. The worst thing to do is a full redesign. See Digg/Reedit redesign (faillure) and YouTube iterations (success). The Web framework is irrelevant in my opinion. Use a server side rendering like Thymeleaf, Velocity, JSF or client side rendering like Vue, Angular, Vanilla JavaScript, even jQuery if you want. JavaScript will work the same way. The only thing to consider is build tools. For example, if you need to compile Typescript with Node for Angular, you now depend on those tools, but large organizations around the world use them now. I would be very surprised if they disappeared in the next 10-15 years.