Migration

Old applications often represent a significant business investment, and often they serve as a critical part of a business.  Unfortunately these applications have a limited life span due to the ever changing nature of the computer industry.  Migration allows you to retain much of your original investment through code re-use.

Our migration process is comprised of a series of sequential steps. The steps taken depend on the type of application, current language and target language for the new application. Regardless of the exact approach used, the resulting application is compatible with XP, VISTA and Windows 7.  As such, it will serve you for a long time to come.

Typically we use the current version of Visual FoxPro as the platform for the new application. We will also use C#, ASP and other languages depending on your need. In addition, we can use MS SQL or MYSQL as the database manager with if you so desire or when your application requires it.  The original platform, the target platform, and database manager dictates how much of your old code can be re-used.

With some Visual FoxPro applications we can perform a migration to the current version with only minor changes to the original source code. These minimum change migrations are the exceptions and not the norm. With the typical dBase, Clipper or FoxPro application there are multiple steps that are required for a successful migration.    The older dBase, Clipper and FoxPro application do allow for code re-use.

When we are migrating an application to Visual FoxPro we use an Application Framework.  The Application Framework provides basic functionality through a combination of program files, classes and data structures. The Framework also provides a stable foundation upon which new applications came be built. By using an existing Framework, the development effort is focused on business logic instead of standard processing functions.

A customer review may be required for the output of each step, depending on the needs of the customer and the complexity of the existing application.

Step 1
A high level review of the existing application with a focus on function, existing problems and desired features. The output of this step includes a rough application menu set, issue log, module descriptions and a list of existing and desired screens

Step 2
Meta-Data is generated based on the current data structure. New structure additions and structure changes are also applied during this step. Recommendations for data structure modifications are made during this step. Typically, these recommendations focus on data normalization to reduce the amount of stored data and increase ease of use. Changes are applied to the Meta-Data based on approved structure changes. Look-up fields and their source data are also identified during this step. The output of this step includes Meta-Data, table list, index structure list, look-up field list, relationship description, data change recommendations. Changes are also made to the menu set, issue log, module descriptions and the list of screens where necessary.

Step 3
Once the Meta-Data has been developed then data controls classes are generated from the Meta-Data. Existing data screens are also reviewed for layout details when necessary.  Data centered business logic is also identified during this process, such as display initialization code and data validation code. The output for this step includes data control classes and a list of data centered business logic segments.

Step 4
Business logic is applied to the data display classes where necessary and the data display forms are generated using the Meta-Data.  Necessary changes are applied to the business logic based on language differences, efficiency and data structure changes. The completed and approved data display forms are the output for this step.

Step 5
Existing reports are reviewed along with any associated business logic. Depending on the existing report source, new reports are either generated to match the existing layout or the original reports are imported into the new version. Necessary changes are made based on data structure changes applied during the second step. Business logic is applied to the reports and modified as necessary. The new reports are the output for this step.

Step 6
Menus are generated along with processing modules. The associated business logic is applied to menu options and the processing modules. Changes to the business logic are made for efficiency, data structure, error correction and new functionality. The output for this step is the application menus and processing modules.

Step 7
All of the application components are compiled. Final unit, module and application testing is conducted and documented. Acceptance testing is also conducted. All necessary modifications are made based on the approved project scope and application design specifications. The final testing results, application executable and signed approval forms are the output for this step.