Things to keep in mind during Application Migration: ColdFusion to Spring

Question

This question is regarding migration project. Currently the legacy Application is in ColdFusion and we want to migrate it to Spring Framework.

So my main questions

Answer 1

Much is going to depend on the existing structure of your CFML application. Whilst there is a framework available for CFML that matches the IoC portion of Spring fairly closely, I suspect you're looking at migrating from an unstructured CFML application to Spring Web, rather than just the IoC portion - and you're looking at moving from one language to another: CFML to Java.

So the reality is: it's not a migration project, it's a complete ground-up rewrite.

I know you said "Migration is an requirement" (sic) but I think you need to explain a bit more about what's driving this so folks can provide a better answer than "You're crazy, don't do it!" - because with the little information you've provided, no one is going to be able to provide a useful answer.

As for the mechanics of such a migration, IF you have a well-structured, MVC CFML application that uses ColdSpring, you could migrate the model, piece-by-piece to Java and use Spring's IoC instead of ColdSpring for bean management (you'd want Spring to be the parent bean factory for ColdSpring so that the rest of your CFML code could still access the newly migrated beans).

Once you have all your model (and data access layer) migrated to Java / Spring, you would then tackle the translation of all your .cfm view pages to .jsp view pages and rewrite all of your CFML controllers / listeners (depending on which CFML framework is in use) to Spring Web handlers.

It's likely to be a massive project - and that's assuming a well-structured, MVC-framework-powered CFML application that's already using ColdSpring to manage the model.

I'll bet that what you're starting with is an unstructured mess (which is why there's a directive to migrate) in which case your massive project just got more massive.

Answer 2

Migration projects are fraught with danger.

The first danger is, "this is expensive and painful. Lets rebuild it all from scratch and implement any new idea or feature that any marketer/manager/programmer has using structured methodologies and blah blah blah..." This path leads to doom, because

1) its an open-ended amount of work, and

2) nobody actually knows what the old system does (seen the spec recently?) and therefore you'll end up rediscovering what the old system after the new one goes live, at great pain and damage to the organizations' ability to do its job with the new software. Usually in fact the new system never catches up with the old one and so the rewrite dies an ugly death.

The right way to do such a migration is: insist on leaving the functionality alone, and convert the existing system. No new goodies, features, methodologies.

That insistence has its own troubles: the organization often has to make some changes for survival reasons during the window in which the migration is occurring.

To handle that, you really want an automated migration tool, so that the "no functionality changes" rule only applies during the actual conversion, and is thus as short as possible. Its ok for the developers of the migration tool to take some time to build it and thoroughly test the conversion tool; in the meantime, the organization can enhance the legacy system by its usual methods. When the migration tool is ready.... pull the trigger, convert the code, patch the problems and test the result system for effectiveness.

Once the system has been migrated, then you can consider radical restructuring or reshaping, knowing that the fundamental functionality is still sound.

Whatever you choose for an automated migration tool, you need to be careful that the code it produces is maintainable in the new environment. Many converters to truly naive 1-to-1 conversions, and the resulting code ends up being legacy-foo-coded-in-new-bar, or what is laughingly called "JOBOL" after naive COBOL to Java conversions. The conversion tool must be sophisticated about how it maps the language constructs. (You might want to read this SO discussion of PL/1 To Java Conversion).

Your biggest trouble is likely to be "testing". The current system has complete functional tests, right? Uh, you don't have any functional tests? How will you verify the new system implements what the old one did correctly?

The right answer here is to construct tests of the legacy system in terms of its input-output behavior, and apply those tests to both the legacy system and the migrated one. This is a lot of work, and nobody wants to do it, let alone pay for it. This is the second way migrations fail.

The last thing that happens is that management woefully underfunds and undertimes the work required to do this right. Usually negotiations with the development team go like this:

Mgr:  How long to do this?
Team:  Two years...?
Mgr:  BZZZT!  Wrong answer, try again...
Team:  One year?
Mgr:  BZZT! ..
Team: (Gulping) 6 months?
Mgr:  OK, get started.

Notice how there's no actual discussion of the work here.

At the end of 6 months, finger pointing will start. Manager: "I asked you guys, and you said 6 months..."

You're in for a rough ride. Prepare carefully. Insist that people really list all the issues, and that they produce believable estimates. If its your first time doing a migration, you have no good basis to make such estimates; if its the organization's first time, it has no basis by which to judge if any estimate is right.

(Full disclosure: I'm biased. I've been building automated migration tools for 22 years. Check out B2 migration.)