|
|
|
|
|
|
|
Services->Application Development->Migrating Legacy Application |
|
|
|
As the cost of maintaining custom legacy applications increases, there are now a
number of low-cost application servers that can be used to migrate these applications
to other platforms and lower the total cost of ownership (TCO).
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
NETSOFT guide you through the steps required to successfully migrate a legacy application
to a more cost-effective platform for both development and maintenance costs.
- Documenting the Existing System If we were to look at the Software Development Life
Cycle, a key part of the process is actually gathering requirements from users on
the functionality that they need in the application you will eventually build. In
the case of migrating a legacy application, the process is slightly different, as
you will need to perform analysis on the existing system to understand how it works,
who uses it, what they use it for. A good starting point for gathering this information
is in the existing documentation for the system you want to migrate. This documentation
could take the form of the original specifications for the application, as well
as the systems design and documentation produced once the application was completed.
You may also find crucial information in other forms of documentation, including
guides, manuals, tutorials, training materials, etc. that end-users may have used.
- Requirements Analysis The next step in the migration process is to perform
a detailed requirements analysis to determine what features are required in the
new application. At a very basic level, the features and functionality that are
in the legacy system should be included and you should perform interviews with the
users and system administrators to see what features are required. A key point to
get across to users is that the first step is a migration of existing features and
functionality to a new platform. The most effective way of cutting over to a new
platform is to ensure that the application supports the existing features and functionality
first before adding anything new. A good way to limit the scope of the migration
project is through the development of Use Cases that detail how the legacy system
is currently being used. You can then use these Use Cases to design your new application
and ensure that the exact functionality offered in the legacy system is included
in your application.
- Platform Selection With an understanding of how the application is being used and
the code behind it, as well as the user requirements, you can then select a platform
for the migrated application. With legacy applications, this decision was most likely
made on a consolidated platform where the application logic and data both resided
on the same platform. With modern applications, the application logic and data are
usually separated into two distinct components, so you will need to decide on both
an application and database platform. The major decision to be made on the application
platform is whether the migrated application will be a “fat” client application,
installed locally on each user’s computer or whether it will be a Web application
that the user can run from their browser. Will you need to buy additional servers
or can the application be hosted on current hardware? Will the application be scalable
and meet your needs in the future or will you need to add additional servers to
support users?
- Design, Development and Deployment Finally, with the system requirements ironed
out and the application and database platform you can start the detailed design
and development phase of the migration, where you actually create the detailed design
document for the system you are migrating to and start development. Another key
to a successful migration is ensuring that you do a thorough detailed design that
encompasses the current functionality in the legacy system and user requirements.
User should be able to take the screen designs from your detailed designs and walk
through the tasks they would normally carry out in the legacy system you are replacing.
Before the final cutover point you should run both systems in parallel to ensure
that there are no critical gaps in support for the business. It is best to run the
systems in parallel through a normal processing cycle—for example, if you are replacing
an order entry system that performs month-end processing, make sure that you run
both systems through the entire process. Once you are satisfied that the new application
is fully functional, you should leave the legacy application and platform up and
running for the next few months. And before you finally pull the plug, make sure
that you have a complete backup of all of the relevant data and applications and
that you have a way to access this information when required.
|
|
|
|
|