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 build migration tools. Check out B2 migration.)