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?
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.
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.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
...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.
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.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
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.
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...