Home/ Questions/Q 797521
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T22:49:10+00:00

This question is regarding migration project. Currently the legacy Application is in ColdFusion and

  • 0

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 are:

  1. What are the things to keep in mind while considering Migration Project ?
  2. Are there any specifics things that I need to keep in mind while considering migration from ColdFusion to Spring Framework ?
  3. How do ColdFusion stack up with Spring Framework ?
  4. What resources would you recommend to get myself familiar with before starting on Migration Project from ColdFusion to Spring ?

I know some might think that this is very open ended question but this is my first Migration Project and I have never had any experience with Migration Project and what looking for some useful guidance over here.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.)

    • 0