Migration over time from VWG

We are in the same boat.. started looking at strategies for a migration plan that might take a few months.

So what we came up with was as follows:

1. Accept the fact that you are going to have two solutions, two projects. Don’t see any way around that.
2. For business objects classes, just share the code between projects using ‘Linked’ files.. this means any object change in the one project is picked up on the other one.
3. Re-tool the bootstrap/logon page to work the way WiseJ does authentication
4. Get to a compile point that your classes and a minimal logon/main page are accessible in WJ.
5. Now move one screen/function over at a time, testing and validating as you go. Remember, the database and object layer are fully compatible between both systems so you have a baseline to compare to.
6. This works OK for a few screens.. but we have several hundred to deal with..

So now the real challenge: How do you manage two code bases over an extended period and not go crazy?

We have many large customers running our VWG code. There is no way we can flip a switch and move them to WJ overnight. This migration project will take months at a minimum. During that period, we have code fixes and updates happening in the VWG code base.. so managing two stacks of code will be a big challenge.

In our case, and I suspect in many sites, there is a lot of code in the forms and controls: All of the event handlers, menus, validations, etc are in code-behind routines.  I really don’t like just duplicating this code to WJ because it will quickly become out of sync with the VWG codebase.   The good news is that most of the event handlers are compatible between the two platforms. There are some differences in how messagebox event handlers are handled, but those can be automatically retooled.

I tried experimenting with Partial Classes to see if we could put common event code in a second file that could be shared… it sort of works, but Visual Studio can’t really handle it properly.

i also tried referencing the main DLL from the VWG project in the WJ project with the idea that all the object names are available.. This strategy doesn’t work because the event signatures are different.. so the compiler will require that you reference Gizmox DLLS.. before long you are going around in circles with compiler errors.

C# doesn’t have a way to include blocks of code from other C# files (sadly), so we are formulating a plan to automate code updates: Our plan is to define a region in the VWG form/controls that indicate common code that should work in Wisej.. for example:

#region WJCommonCode ….

private void btnClick….

{

}

etc

#endRegion.

We plan on writing a scanner program that copies this code from VWG to WiseJ and replace the corresponding block. This will allow for a common block of code to run in both systems for an extended period. We will continue to do fixes in the VWG codebase, and then bulk refresh the corresponding file in WJ.  Not sure how practical this will be, but its the best idea I have short of a mass duplication.

One item that is impacting us is the missing properties in WJ that we use frequently in VWG, notable “SelectedItem”. As you all know, in VWG you can set/retrieve the ListView SelectedItem.  It would be nice to have this property available to avoid a lot of rewrites.

Be interested to hear how other companies are approaching the conversion.

Mitch

Hi Mark,

I’m not sure it’s a good approach to go in production with a VWG and Wisej mixed app. We have several projects going from VWG to Wisej and most of the work has been to remove workarounds, bug fixes, remove the composite controls for tool buttons, validation events, etc.

There is a small guide here: http://wisej.s3.amazonaws.com/support/guides/VWG%20to%20Wisej%20migration%20white%20paper.pdf

If you need development services for the migration let me know. I can put you in contact with the group handling the migrations.

Best,

Luca