Migrating a Visual FoxPro application to modern .NET can be one of the most valuable technology projects a business undertakes, but data preservation must be treated as a first-class requirement.

A legacy application may contain years of customer records, invoices, orders, inventory transactions, employee information, pricing history, and operational records. Losing even a small portion of that data can create serious business consequences.

Visual FoxPro 9.0 has been out of extended support since January 13, 2015. As organizations modernize, the safest approach is to treat application migration and data migration as related but separately controlled workstreams.

This article explains how to move from Visual FoxPro to modern .NET while minimizing data risk.

Start With a Data Inventory

Before migrating anything, identify exactly what exists.

Create an inventory of:

• DBF files

• Tables

• Indexes

• Relationships

• Memo fields

• Lookup tables

• Configuration data

• Archived records

• External files

• Imported datasets

• Reports that depend on specific fields

Do not assume the database folder contains the complete data model. Legacy applications often use files, procedures, and configuration settings outside the obvious database structure.

Identify the System of Record

Some Visual FoxPro applications exchange information with other systems.

For example, customer information might come from one system while invoices are created in another.

Determine which system owns each piece of information.

This prevents duplicate or conflicting data after migration.

Create a simple ownership matrix:

This exercise can eliminate unnecessary migration work.

Profile the Data Before Moving It

Data profiling identifies problems before they become migration failures.

Check for:

• Duplicate records

• Blank values

• Invalid dates

• Invalid codes

• Unexpected characters

• Inconsistent capitalization

• Incorrect numeric values

• Orphan records

• Duplicate keys

For example, a customer table may contain:

• ABC Corporation

• ABC CORPORATION

• ABC Corp.

These may represent the same organization.

Data cleansing rules should be agreed upon before migration.

Design the Target Data Model

Do not automatically copy every DBF table exactly as it exists.

A legacy database reflects the requirements of the past. The target database should reflect the requirements of the future.

Review:

• Primary keys

• Foreign keys

• Normalization

• Indexing

• Constraints

• Data types

• Audit columns

• Security requirements

The target database may require structural changes.

Build a Data Mapping Document

Every important source field should have a defined destination. A data mapping document creates a clear connection between the Visual FoxPro database and the new application.

This document becomes the reference point for development, testing, validation, and sign-off.

Handle Data Types Carefully

Data types are a common migration risk.

Character Data

Check field lengths, encoding, special characters, and text normalization. Do not assume every field should become a short string.

Numeric Data

Review precision and scale. Financial values should use appropriate decimal types rather than floating-point representations where exact precision is required.

Dates

Verify how legacy dates are represented and interpreted. Test edge cases, including historical dates and missing values.

Logical Fields

Map legacy logical values consistently to Boolean or equivalent target values.

Memo Fields

Large text fields need appropriate target storage. Confirm that long-form content, notes, and descriptions are preserved correctly.

Migrate in Test Cycles

Never make the first migration your production migration.

Run multiple test cycles.

Cycle 1: Technical Migration

Confirm that data can be extracted, transformed, and loaded successfully.

Cycle 2: Cleansed Migration

Apply approved data-quality rules and verify the transformed records.

Cycle 3: Business Validation

Ask business users to verify important records and workflows.

Cycle 4: Performance Validation

Measure migration duration, database performance, query response times, and application behavior.

Cycle 5: Production Rehearsal

Execute the complete migration procedure using production-like data and the same operational steps planned for the final cutover.

This reduces surprises during the final migration.

Validate Record Counts

Record counts provide a basic but important check.

If the source contains:

• 500,000 customers

• 2 million transactions

• 8 million detail records

the target should reconcile against those totals according to documented transformation rules.

A difference should never be ignored.

Sometimes a lower count is intentional because duplicates were removed. That should be documented and approved.

Validate Business Totals

Counts are not enough.

For financial and operational data, compare business totals.

Examples include:

• Total invoice value

• Total outstanding balance

• Inventory quantity

• Monthly sales

• Customer count

• Transaction totals

If the old and new systems produce different results, investigate before production cutover.

Validate Relationships

A record can exist in both systems while still being incorrect.

For example:

Customer → Order → Order Detail

The migration should verify that these relationships remain intact.

Check:

• Foreign keys

• Orphan records

• Duplicate relationships

• Missing references

Preserve Historical Data Carefully

Not all historical data needs to remain active.

Separate:

• Active data

• Operational history

• Archived data

• Obsolete data

The business should define retention requirements.

Archived information should remain accessible when required without unnecessarily increasing the complexity of the active application.

Protect the Original Data

Never modify the only copy of the legacy database during migration experimentation.

Maintain:

• Original backup

• Migration copy

• Test copy

• Production backup

Use controlled processes and document who can access each copy.

Build a Rollback Plan

Every production migration needs a rollback strategy.

Before cutover, define:

• What triggers rollback

• Who makes the decision

• How the legacy system is restored

• How new transactions are handled

• How users are informed

• How data reconciliation is performed afterward

A rollback plan is not an admission of failure. It is a normal part of responsible change management.

Consider Parallel Validation

For critical systems, run old and new processes in parallel for a defined period when practical.

For example, a selected set of transactions can be processed through both systems and compared.

This can expose subtle differences in calculations or business rules.

Parallel operation is not suitable for every architecture, but where feasible it can provide valuable confidence.

Migrate Business Rules, Not Just Data

A data migration can be technically perfect and still fail operationally.

Why?

Because the old application may contain rules such as:

• Pricing calculations

• Discount rules

• Tax logic

• Inventory allocation

• Customer eligibility

• Approval requirements

These rules must be identified and implemented correctly in the new system.

This is why Visual FoxPro migration is both a data project and a business-process project.

Automate Reconciliation

Manual validation does not scale.

Create automated checks for:

• Record counts

• Totals

• Duplicate keys

• Missing relationships

• Invalid values

• Unexpected nulls

• Data-type conversion errors

Automated reconciliation provides repeatability and makes each test migration easier.

Plan the Cutover

A typical cutover sequence might be:

1. Freeze changes in the legacy system.

2. Take a final backup.

3. Extract final data.

4. Transform data.

5. Load the target database.

6. Run automated validation.

7. Run business validation.

8. Enable the new application.

9. Monitor transactions.

10. Keep the legacy environment available according to the rollback plan.

The exact sequence depends on the business and the application's architecture.

Train Users Before Go-Live

Users should understand:

• New screens

• Changed workflows

• Search methods

• Reports

• Permissions

• Error handling

• Support procedures

Training reduces operational errors during the transition and helps users adapt to the new application.

After Migration

Do not consider the project complete immediately after launch.

Monitor:

• Application errors

• Database performance

• User issues

• Integration failures

• Data inconsistencies

• Reporting differences

Review results during the first days and weeks.

Final Thoughts

A successful Visual FoxPro to .NET migration is not measured by how quickly the old application disappears.

It is measured by whether the business can continue operating with accurate data, reliable workflows, and a sustainable technology foundation.

Protect the original data. Understand the existing business rules. Design the target data model carefully. Run multiple test migrations. Automate reconciliation. Validate real business scenarios. Plan rollback.

When these practices are followed, organizations can modernize their Visual FoxPro applications while significantly reducing the risk of data loss and business disruption.