By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,630 Members | 1,121 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,630 IT Pros & Developers. It's quick & easy.

Gradual Application Conversion

P: n/a
Hello,
I work for a company that sells a product with a VFP frontend/MSSQL backend,
and we have become aware for many reasons the we need to switch over to
..net. The problem is that our application is huge, and a flatout conversion
would take several years, during which time our core product would change.
It appears our best approach would is a gradual conversion from VFP to .net.

Has anyone faced and solved this challenge before? Any ideas on what would
be more practical - to call VFP from .net or vice-versa? Any recommended
reading would also be greatly appreciated.

- Chris
Jul 21 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
partitioning a conversion is difficult. So many factors depend on how well
the VFP application was written.

If your application was written to have a COM interface, you are off to a
good start. Otherwise, I would suggest that the first thing you do is
partition your application, entirely in VFP.

In other words, if your app isn't already based on front-end components that
call business components, where the business components are declared as
OLEPUBLIC, do it now. Write test cases against the COM interface to make
sure that you can fulfill 100% of the application functionality using the
COM interface. It honestly doesn't matter WHERE you draw that line through
your application, since all this code will end up in the dust bin...
however, the line must be drawn completely through the application. no
exceptions.

This is deliverable 1: a completely partitioned and automatically testable
COM interface structure that allows 100% of the functionality to be called
from a different front end than the one provided in VFP.

Then, deliverable 2, some months later, would be a completely new front end,
written in VB.NET or C#. It would call a set of objects that simply use COM
Interop to call into your VFP business objects. Those automatic test cases
will come in handy, because along the way, you will have had to make some
changes to the COM interface to make it easier for C# to call it (or to
support new business needs, as the application continues to develop new
features).

Now, you can offer two complete interfaces. The timeframe of developing
deliverable 2 should have MINIMAL front-end development on the VFP front
end. This is because you will have two branches in your source tree: one
for the VFP front end and the other for the .NET front end. You don't want
to make too many changes in both places.

After deliverable 2 is shipped and you have completed user acceptance
testing (e.g. your code base is fairly stable... exactly when this happens
depends on the SDLC and support procedures that your company uses), you can
embark on a vertical slicing of the application.

The front end work was a horizontal slice, across all functions. The next
step is to take natural groupings or clusters of functionality and replace
them in a vertical fashion: one feature group at a time. It isn't clear
what your app does, so I will refer to a retail system. You could pull off
the inventory counting and management components, and rewrite them, leaving
POS completely intact. Ship. Deliver. Stabilize.

Then pick off another vertical slice. All along the way, you may have to
add further COM interfaces where you cut apart older VFP components. Put in
automated tests as much as you can. Note: when you replace a VFP component
that has a set of test cases written against it, don't delete the test
cases. Make sure that the test cases can call your new component in exactly
the same way as they could call the COM components (minus the details of
Interop itself). I would even go so far as to create a COM wrapper for the
new .NET stuff so that your .NET interface uses COM to call the new .NET
components underneath. That way, you don't have to change the U/I code
right away. You can migrate that interface at your own pace.

After a while, this goes faster, because doing a single vertical slice will
require that you create some infrastructure code, code that you will add to
and refactor as you go. By the time you get to the last slice, you have
such a good data access layer, and you are so familiar with it, that it
should be a snap to kill off the last component.

As for which slice to pick first: pick a small but distinct one. (like the
data admin interface or something). Much of the expense of this layer will
be spent creating methods and techniques that you will re-use. During this
step, don't pick the hardest possible thing. You already have hard stuff on
your plate.

Then, after the first slice is stable, and you have your .NET GUI calling
both COM and .NET components, the second slice should be harder... much
harder. Something big and ripe and nasty. Something that needs the
rewriting. After you finish that one, your team will have all the practice
they need to pick off additional slices and push them out at a rapid pace.

Do this agile. Your requirements are fairly well understood (its your app,
after all). Depending on the size of the app, you may be able to knock the
whole conversion off in a remarkably short period of time (I'm talking
months, not years, assuming you use something like Scrum or XP).

Good Luck,
--- Nick Malik
fmr. Director of Development
Applications Architect

"Chris Brown" <cb******@store-trak.com> wrote in message
news:lWaOc.5352$NV3.3563@trndny01...
Hello,
I work for a company that sells a product with a VFP frontend/MSSQL backend, and we have become aware for many reasons the we need to switch over to
.net. The problem is that our application is huge, and a flatout conversion would take several years, during which time our core product would change.
It appears our best approach would is a gradual conversion from VFP to ..net.
Has anyone faced and solved this challenge before? Any ideas on what would be more practical - to call VFP from .net or vice-versa? Any recommended
reading would also be greatly appreciated.

- Chris

Jul 21 '05 #2

P: n/a
Thanks for your very well detailed answer! In the details of each point, a
chapter could be written.

On the plus side, we have a business object to handle each form in our
system, on the negative side, no COM - yet. We've been 99% frontend for
about 7 years, and switching over a lot of code recently. Looks like we're
in for a couple year battle.

Thanks again for your comments. I'll keep you posted...

- Chris

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:iatOc.59023$eM2.49814@attbi_s51...
partitioning a conversion is difficult. So many factors depend on how well the VFP application was written.

If your application was written to have a COM interface, you are off to a
good start. Otherwise, I would suggest that the first thing you do is
partition your application, entirely in VFP.

In other words, if your app isn't already based on front-end components that call business components, where the business components are declared as
OLEPUBLIC, do it now. Write test cases against the COM interface to make
sure that you can fulfill 100% of the application functionality using the
COM interface. It honestly doesn't matter WHERE you draw that line through your application, since all this code will end up in the dust bin...
however, the line must be drawn completely through the application. no
exceptions.

This is deliverable 1: a completely partitioned and automatically testable
COM interface structure that allows 100% of the functionality to be called
from a different front end than the one provided in VFP.

Then, deliverable 2, some months later, would be a completely new front end, written in VB.NET or C#. It would call a set of objects that simply use COM Interop to call into your VFP business objects. Those automatic test cases will come in handy, because along the way, you will have had to make some
changes to the COM interface to make it easier for C# to call it (or to
support new business needs, as the application continues to develop new
features).

Now, you can offer two complete interfaces. The timeframe of developing
deliverable 2 should have MINIMAL front-end development on the VFP front
end. This is because you will have two branches in your source tree: one
for the VFP front end and the other for the .NET front end. You don't want to make too many changes in both places.

After deliverable 2 is shipped and you have completed user acceptance
testing (e.g. your code base is fairly stable... exactly when this happens
depends on the SDLC and support procedures that your company uses), you can embark on a vertical slicing of the application.

The front end work was a horizontal slice, across all functions. The next step is to take natural groupings or clusters of functionality and replace
them in a vertical fashion: one feature group at a time. It isn't clear
what your app does, so I will refer to a retail system. You could pull off the inventory counting and management components, and rewrite them, leaving POS completely intact. Ship. Deliver. Stabilize.

Then pick off another vertical slice. All along the way, you may have to
add further COM interfaces where you cut apart older VFP components. Put in automated tests as much as you can. Note: when you replace a VFP component that has a set of test cases written against it, don't delete the test
cases. Make sure that the test cases can call your new component in exactly the same way as they could call the COM components (minus the details of
Interop itself). I would even go so far as to create a COM wrapper for the new .NET stuff so that your .NET interface uses COM to call the new .NET
components underneath. That way, you don't have to change the U/I code
right away. You can migrate that interface at your own pace.

After a while, this goes faster, because doing a single vertical slice will require that you create some infrastructure code, code that you will add to and refactor as you go. By the time you get to the last slice, you have
such a good data access layer, and you are so familiar with it, that it
should be a snap to kill off the last component.

As for which slice to pick first: pick a small but distinct one. (like the data admin interface or something). Much of the expense of this layer will be spent creating methods and techniques that you will re-use. During this step, don't pick the hardest possible thing. You already have hard stuff on your plate.

Then, after the first slice is stable, and you have your .NET GUI calling
both COM and .NET components, the second slice should be harder... much
harder. Something big and ripe and nasty. Something that needs the
rewriting. After you finish that one, your team will have all the practice they need to pick off additional slices and push them out at a rapid pace.

Do this agile. Your requirements are fairly well understood (its your app, after all). Depending on the size of the app, you may be able to knock the whole conversion off in a remarkably short period of time (I'm talking
months, not years, assuming you use something like Scrum or XP).

Good Luck,
--- Nick Malik
fmr. Director of Development
Applications Architect

"Chris Brown" <cb******@store-trak.com> wrote in message
news:lWaOc.5352$NV3.3563@trndny01...
Hello,
I work for a company that sells a product with a VFP frontend/MSSQL

backend,
and we have become aware for many reasons the we need to switch over to
.net. The problem is that our application is huge, and a flatout

conversion
would take several years, during which time our core product would change. It appears our best approach would is a gradual conversion from VFP to

.net.

Has anyone faced and solved this challenge before? Any ideas on what

would
be more practical - to call VFP from .net or vice-versa? Any recommended reading would also be greatly appreciated.

- Chris


Jul 21 '05 #3

P: n/a
les
Hi Chris,

We're working on a tool to automate the process. The problem, of course, is that the success of source code conversion depends on the design of the original VFP code. In many cases, VFP code takes advantage of capabilities (macro expansion, weak typing, the VFP report writer and others) that are not found in .NET.

You can compile VFP components as DLLs, then let Visual Studio build wrappers around them so that they are callable from .NET, but the benefit from doing this is unclear. The reason for migration is not to get an improved platform or greater speed, but to use a technology supported by Microsoft.

I have a company based in Mexico that employs some of the top .NET people in the world. We specialize in migrating FoxPro applications to .NET. I think that using offshore resources to rewrite your FoxPro form classes, then redesigning the application to use inheritable forms, reduces the coding time to a bare minimum, and gives you a true .NET application.

Please give me a call at (650) 344-3969.

Thanks,

Les

************************************************** ********************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...
Jul 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.