Return to Question

We have a legacy system to bring up-to-date because:

1. It uses an unpopular (amoung our users) non-sql database (Btrieve)
2. Provides only a text interface
3. Is written in Turbo Pascal (but compiled in free pascal) which is hard to recruit/retain developers to maintain it

To give you an idea of the scale, the code base is 15MB over 756 files.

All the studies I've looked in to such as those listed here suggest it is vastly more expensive to rewrite than to adapt what you have.

If I thought we could encapsulate the legacy stuff behind a web service and then design new client(s), that would be fine. But I'm stuck with this legacy database which 90% of those 756 files reference.

We even attempted replacing the low-level DB code with code to convert to SQL, and while it worked fine, it was too slow because the code is still accessing records one at a time generating far too many SQL statements than it would need. Plus this approach does not allow any improvements in the DB design.

When faced with such an upheaval as replacing the DB that is referenced so heavily in code and the other requirements listed, can it still pay to reuse or are we better off treating the new version as a whole new product and just listing the current systems abilities as requirements (bearing in mind no handy requirements doc exists for the current system).

I know it's too hard to give a definitive answer on this, so just any advice would be appreciated especially if you've experienced a similar situation.

We have a legacy system to bring up-to-date because:

1. It uses an unpopular (amoung our users) non-sql database (Btrieve)
2. Provides only a text interface
3. Is written in Turbo Pascal (but compiled in free pascal) which is hard to recruit/retain developers to maintain it

To give you an idea of the scale, the code base is 15MB over 756 files.

All the studies I've looked in to such as those listed here suggest it is vastly more expensive to rewrite than to adapt what you have.

If I thought we could encapsulate the legacy stuff behind a web service and then design new client(s), that would be fine. But I'm stuck with this legacy database which 90% of those 756 files reference.

We even attempted replacing the low-level DB code with code to convert to SQL, and while it worked fine, it was too slow because the code is still accessing records one at a time generating far too many SQL statements than it would need. Plus this approach does not allow any improvements in the DB design.

When faced with such an upheaval as replacing the DB that is referenced so heavily in code and the other requirements listed, can it still pay to reuse or are we better off treating the new version as a whole new product and just listing the current systems abilities as requirements (bearing in mind no handy requirements doc exists for the current system).

I know it's too hard to give a definitive answer on this, so just any advice would be appreciated especially if you've experienced a similar situation.

We have a legacy system to bring up-to-date because:

1. It uses an unpopular (amoung our users) non-sql database
2. Provides only a text interface
3. Is written in Turbo Pascal (but compiled in free pascal) which is hard to recruit/retain developers to maintain it

To give you an idea of the scale, the code base is 15MB over 756 files.

All the studies I've looked in to such as those listed here suggest it is vastly more expensive to rewrite than to adapt what you have.

If I thought we could encapsulate the legacy stuff behind a web service and then design new client(s), that would be fine. But I'm stuck with this legacy database which 90% of those 756 files reference.

We even attempted replacing the low-level DB code with code to convert to SQL, and while it worked fine, it was too slow because the code is still accessing records one at a time generating far too many SQL statements than it would need. Plus this approach does not allow any improvements in the DB design.

When faced with such an upheaval as replacing the DB that is referenced so heavily in code and the other requirements listed, can it still pay to reuse or are we better off treating the new version as a whole new product and just listing the current systems abilities as requirements (bearing in mind no handy requirements doc exists for the current system).

I know it's too hard to give a definitive answer on this, so just any advice would be appreciated especially if you've experienced a similar situation.

We have a legacy system to bring up-to-date because:

1. It uses an unpopular (amoung our users) non-sql database (Btrieve)
2. Provides only a text interface
3. Is written in Turbo Pascal (but compiled in free pascal) which is hard to recruit/retain developers to maintain it

To give you an idea of the scale, the code base is 15MB over 756 files.

All the studies I've looked in to such as those listed here suggest it is vastly more expensive to rewrite than to adapt what you have.

If I thought we could encapsulate the legacy stuff behind a web service and then design new client(s), that would be fine. But I'm stuck with this legacy database which 90% of those 756 files reference.

We even attempted replacing the low-level DB code with code to convert to SQL, and while it worked fine, it was too slow because the code is still accessing records one at a time generating far too many SQL statements than it would need. Plus this approach does not allow any improvements in the DB design.

When faced with such an upheaval as replacing the DB that is referenced so heavily in code and the other requirements listed, can it still pay to reuse or are we better off treating the new version as a whole new product and just listing the current systems abilities as requirements (bearing in mind no handy requirements doc exists for the current system).

I know it's too hard to give a definitive answer on this, so just any advice would be appreciated especially if you've experienced a similar situation.

We have a legacy system to bring up to date because:

1. Is it uses an unpopular (amoung our users), non-sql database
2. Provides only a text interface
3. Is written in Turbo Pascal (but compiled in free pascal) which is hard to recruit/retain developers to maintain it

To give you an idea of the scale, the code base is 15MB over 756 files.

All the studies I've looked in to such as those listed here suggest it is vastly more expensive to rewrite than to adapt what you have.

If I thought we could encapsulate the legacy stuff behind a webservice and then design new client(s) that would be fine, but I'm stuck with this legacy database which 90% of those 756 files reference.

We even attempted replacing the lowlevel db code with code to convert to SQL, and while it worked fine, it was too slow because the code is still accessing records one at a time generating far too many SQL statements than it would need. Plus this approach does not allow any improvements in the db design.

When faced with such an upheaval as replacing the DB that is referenced so heavily in code and the other requirements listed, can it still pay to reuse or are we better off treating the new version as a whole new product and just listing the current systems abilities as requirements (bearing in mind no handy requirements doc exists for the current system).

I know it's too hard to give a definitive answer on this, so just any advice would be appreciated especially if you've experienced a similar situation.

We have a legacy system to bring up-to-date because:

1. It uses an unpopular (amoung our users) non-sql database
2. Provides only a text interface
3. Is written in Turbo Pascal (but compiled in free pascal) which is hard to recruit/retain developers to maintain it

To give you an idea of the scale, the code base is 15MB over 756 files.

All the studies I've looked in to such as those listed here suggest it is vastly more expensive to rewrite than to adapt what you have.

If I thought we could encapsulate the legacy stuff behind a web service and then design new client(s), that would be fine. But I'm stuck with this legacy database which 90% of those 756 files reference.

We even attempted replacing the low-level DB code with code to convert to SQL, and while it worked fine, it was too slow because the code is still accessing records one at a time generating far too many SQL statements than it would need. Plus this approach does not allow any improvements in the DB design.

When faced with such an upheaval as replacing the DB that is referenced so heavily in code and the other requirements listed, can it still pay to reuse or are we better off treating the new version as a whole new product and just listing the current systems abilities as requirements (bearing in mind no handy requirements doc exists for the current system).

I know it's too hard to give a definitive answer on this, so just any advice would be appreciated especially if you've experienced a similar situation.