Migration from FoxPro to Dot-Net

No redundant questions! Code is the best documentation!


Example of interface in FoxPro



Example of interface recreated in WPF



Order of interaction (briefly):

Write us ...

Some details:

Prerequisites for project implementation

The mandatory condition of beginning of work is submission of the FULL source code and the test data.

We must be able to run and to trace ALL components of the application, which must be recreated in Dot-Net.

The source project and the test data must be transferred to us BEFORE beginning of work after NDA signing, but BEFORE the agreement on migration signing. We have to make sure that we have the FULL actual and working source code and the actual test data.

Versions of FoxPro projects that can be migrated

Any version of FoxPro including FoxPro 2.X for DOS can be migrated

Technologies that can be used

The selection of set of technologies depends on technology of data access in the new application. In most common situation we organize the application onto four parts:

  1. Components working in the local network (LAN) with direct access to data (using TCP/IP).
  2. Components working with data remotely, but not using WEB-interface. The same WPF applications, which work with data with using of REST protocols (HTTP is general).
  3. Components working with data remotely through public networks (Internet, Intranet) which have WEB-interface.
  4. Components working with data remotely through public networks (Internet, Intranet) as mopile applications (Windows Phone, iOS, Android).

The set of technologies for the first group of components is: UWP (Universal Windows Platform) or WPF + ADO.NET(plain or E-F) + SQL Server.

One question must be answered: use plain ADO.NET ( DataSet ) or use Entity Framework? The choice is based on one main criterion. If the structure of the data is permanent, and there are no components of CMS (Content Management System), then we use Entity Framework.

But if the functionality of CMS is required, if administration or user must have the ability to extend or to modify the structure of data, then we Do NOT use E-F, but DataSet with our own framework.


If there are components of the second group, then we have to decide:


In the third and fourth cases we create n-tier solution (three levels for basic security requirements):


The above is valid in cases where the solution is NOT deployed inside of the cloud. In clouds we work with appropreate technologies (ASP.NET(MVC) + HTML5 + jQuery + SQL Server in case of Azure).

Prices

A preliminary estimate can be determined by using of our VFP-form, which we send. But the PREFFERED way is to let us do estimation, if client agrees to give us full source project and test database ( when NDA is concluded ).

The final estimation can only be created when we have the FULL source project(all source codes, forms, reports, ...) and the test database. We must be able to run and to trace any component of source project.

Payment order

Two arrangements are possible:

Terms

Terms estimate is the same as price estimate. Preliminary terms estimate client can do by themselves by our VFP-form we will send, or we do it if client sent us full source components and test data. Final terms can be estimated only after we have full source project and test data deployed.

Order of interaction

Using of pre-conversion

The following conditions make pre-conversion expedient:

Mainly, pre-conversion insures that no code or functionality will be lost!

Pre-conversion is one of first items to complete and requires at least a month to be finished.
First item is always the data migration!

During the pre-conversion we move into the new project: structure of classes, forms layout with controls. All source code will be commented and placed into appropriate methods.

Components of third-party companies can be used

Telerik UI for WPF

Angular JS or Telerik Kendo

IdeaBlade DevForce for data access

Of any other company client prefers

Procedure for commissioning

First stage - creation of program of migration+synchronization of data.
During migration the program creates tables and other components of SQL database, and then the program copies the data.
The synchronization process allows synchronization of the data in the current database with data in the new database, which provides the possibility of working in both the current and the new application at the same time.

When the next group of components is implemented based on workflow, client begins entering and working with part of data in the new application, but client still work with other components (not migrated yet) in the current application.
Data must be synchronized daily or any time, as needed. The possibility to rollback to work in the current application is ALWAYS present!

So, the process of testing and of the commissioning goes step-by-step and provides MAXIMUM RELIABILITY AND DATA INTEGRITY!

Write us ...

More detailed about technologies ...