• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Bear Bibeault
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • salvin francis
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Jj Roberts

What's the best strategies to migrate an app developed in Mumps to Java?

 
Ranch Hand
Posts: 701
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

We have an old application developed in Mumps, which is very large (56,000 programs, 3,000,000 lines of code). This application has been developed for about 20 years, and is very critical, because deals with financial market in a bank, and can never stops. If this app stops for a few moments a large amount of money is lost.
This app is very difficult to mantain, because each little thing you change can damage other things, and people who knows programming in Mumps are retiring themselves. Besides the structure in a Mumps program is not like SQL databases, many relationships are made by programming.
So, they are thinking about migrating this app to J2ee, but in steps: we need a way to migrate all the functionalities with the current app working.
What would it be the best strategies to do that?
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
MUMPS... I remember reading about that... at WorseThanFailure.com: A Case of the MUMPS. It looks like a very old and primitive programming language that you wouldn't want to use for anything today...

Converting such a big system written in MUMPS to Java is going to be a large project; you'll have to rewrite everything.

It's ofcourse very hard (impossible) to give you a fail-safe recipe for doing something like this. Out of the little information you give it's impossible for anyone who reads your post to determine if you can do this in parts - that depends on how that MUMPS system is put together. Does it consist of subsystems that you could replace by a Java system without affecting the rest of the system too much?

Maybe it's a good idea to see if you can find a not-too-large subsystem, and do a pilot project to see how difficult it is to convert it to Java and to get an idea of what problems you might encounter.
 
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jesper Young:
Maybe it's a good idea to see if you can find a not-too-large subsystem, and do a pilot project to see how difficult it is to convert it to Java and to get an idea of what problems you might encounter.



That would be one approach.

However, under the circumstances, a better approach might be to tackle the huge problem straight away. The advantage of this is that, presumably, the management and customers know it is a huge project and hence won't expect results for at least a few months. That should give you plenty of time to look for an internal transfer or a ticket out of there.
 
Marshal
Posts: 71065
292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
. . . and you will probably have to notify all the Bank's customers that the system will be unavailable from 3am to 6am one Sunday morning.
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you have automated tests? If you do, congratulations!

Otherwise, I'd get to work writing them, right away. Write automated tests that confirm every little bit of the existing system's functionality: you're going to need them.

Meanwhile, Google "Java MUMPS." I see several commercial products to help with this specific migration. At least one is a MUMPS compiler that targets Java.
 
Rogerio Kioshi
Ranch Hand
Posts: 701
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Peter Chase:


...That should give you plenty of time to look for an internal transfer or a ticket out of there.



Yeah, I've been thinking that it might be a good idea to be transfered... but they (bosses) know that it is not easy to do this migration, since even they gave us at least 5 years to conclude the whole project. So, now the project is in the "soft" level.

I've known that many others tries to do this migration have been done, none of them were successful.

I've also known that 2 architects worked here previously, but one of them quit and the other decided to work at another place (bad signals).

Well, I think I'll try to take this project for 2 months. After that, if I see it is a really bomb, I'll ask for being transfered.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a common and horrific situation. Some solutions are big-bang cutover of the whole thing, gradual migration of one feature at a time with some kind of integration, and running in parallel for validation until you've built enough to be more valuable than the old system.

Oh, and running away sounded pretty good, too, except that this could be a chance for large-scale green-field system building, which has it's appeal if you can dodge the pain of the rest of the situation.
 
Marshal
Posts: 26128
77
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My high-level estimate of the time to do that migration is 3 years. That's assuming you don't have a moving target and that you retain people who know how the system works. So I'd say your bosses' estimate is not too bad. They know more than I do.

I dunno, the conversion to Java idea sounds to me like you'd just end up with a steaming pile of unmaintainable Java. And the idea of migrating by steps sounds like trying to cross the Amazon river one step at a time. But what do I know, either or both of those ideas might work.

And before you write the unit tests that confirm the system's functionality, you will probably need to do some archaeology to find out just what that functionality is. That alone could take several months.

Also, I don't think that J2EE is necessarily a good target. It might be a good target for the parts of the system that people work with interactively, but I will bet there are a lot of "batch" processes that get run every night, or at month end. You could target them with Java too, but not really J2EE.
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One thing that you have to watch out for with migration projects is that you get the specifications for the new system correct and in detail.

With these kinds of projects (where you're going to replace an existing system with something new that has essentially the same functionality), it is often too easy to describe the specs for the new system with one short sentence: "The new system should do exactly what the old system does".

The problem is that most likely nobody knows exactly what the old system does, so if you spec the new system in terms of the functionality of the old system, you won't know what the new system is supposed to be doing either...
 
Tongue wrestling. It's not what you think. And here, take this tiny ad. You'll need it.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic