.De Lucia, Francese, Scanniello, and Tortora (2008) discussed some of the challenges encountered when migrating a COBOL legacy system to a multi-tiered Web-based architectural environment. Some of the challenges they encountered were spaghetti code, database access for users, and embedded control flows (De Lucia, Francese, Scanniello, & Tortora, 2008). Migrating legacy systems depends on decomposability (Brodie & Stonebraker, 1995).
"A legacy system is classified as being decomposable, semi-decomposable, or non-decomposable, depending on how its user interface, application logic, and database software components are separated" (De Lucia, Francese, Scanniello, & Tortora, 2008, p. 1334).
Other things to keep in mind concern data conversion and data migration. These activities can mean data mapping documents are required. These documents could be created by the System or Business Analyst.
As an example, I worked on such a project where the old system identified customer phone numbers as Home, Work, Work2, Fax, Fax2, and Other. The new system displayed these as Home, Business, and Mobile. The business decision-makers needed to identify where the Fax, Fax2, and Other category were to map to in the new system. Decisions also needed to be made concerning how to handle transferring the data if the new system field(s) was/were already populated.
To further clarify, if the new system Business phone number had already been populated by the old system Work data, should the Other field over write that data? Should the data in the Other field just be deleted and not migrated? Some other solution?
The final decision was to not lose any customer data. The business was quite adamant about that decision. The solution was to have phone numbers that were not migrated to the new system phone designated fields to be logged as a note on the customer record. This way the users could as least view those phone numbers if they were needed.