CODEWITHSUNDEEP
javaspringarchitecturemigration
Roam
Roam

Reputation: 4949

migrating a large-scale, poorly structured Java system to Spring application framework

I'm looking for development stories/experiences on migrating a Java system to Spring Application Framework. our aim is the benefits of a bean container and the dependency injection of Spring. We're not considering Spring MVC or any other of its specific components at the time.

Our system is currently using no bean container of any kind. all in pure Java-- nothing of JEE either.

It has its own, house-built service engines for managing Db services, in-memory caches, session mngt, configuration, and certain product-specific components. what's more, it is poorly structured. very poorly encapsulated -- needs lots of refactoring, elimination of duplicate and unused code, bug fixing. a good amount of our development efforts are going into bug-fixing rather than structural -- making it even further deteriorate. it's a 10+ year-old system and has been built around its original architecture.

We aren't even sure yet whether to work on its existing structure first then look to get the benefits of Spring, or to do them both at once.

To me, working a new architecture from scratch on Spring that implements the logic and not the structure of the current system is the best. however, this may/not be as feasible since it won't have tangible results in a near-enough future for the upper management.

I'll appreciate direct/indirect references opinions, experiences and other input.

TIA.

//=====================================

EDIT:

so - in a phrase, this is on "how to migrate a dinosaur to Spring". it's a matter of strategy-- not of technical migration like how/where to organize/define/integrate the specific components.

Upvotes: 2

Views: 888

Answers (2)

Fendy
Fendy

Reputation: 4643

First, see this article. If you fulfill the requirement for server migration, then continue. If you don't think so, then drop your plan.

If you think that you only need to replace some parts inside the system and not the whole system, you need to consider whether the benefit will outdone the cost. There is a guidance that says "if it works, don't change", because any change to an existing code increase the risk of being error. Are you sure that Spring will bring all the benefits that you think of? Moreover, the amount of tests initiated to reduce the risk is also costly.

That aside, if you still insist that you need to do the migration whatever the costs, I suggest that you rebuilding the new system separated from old one while still maintaining the old one. Then you will need to implement the new system partially under the same database and not total cutoff.

Upvotes: 0

icsmith23
icsmith23

Reputation: 41

I'd start by creating a migration plan that...

  • Converts as many of the legacy java classes/functions you can into bean format.
  • Swaps out legacy code with built in Spring libraries such as database access, security, etc. and/or wrap Spring libraries with the legacy interfaces to migrate off legacy code
  • Devises a way to run both the legacy system and the new system together while slowly transitioning elements from the legacy system to the new system

Upvotes: 3

Related Questions