They're large and complex applications for starters.

The original gurus are gone - you're left scratching your head, asking why did they do that?

You can't see the screen runtime code - its impossible to duplicate the functionality by converting generated and hand-built code.  Generated screens depend on CorVision's runtime screen handling -- and there is no source code for that.

CorVision apps can depend on VMS services for batch job handling, print queues, sorting, etc.  You have to find replacements for those too.

CorVision was a one-tier world. User interface, business logic, and database code are all tangled together - custom code and generated code too.  Separating the tiers is a seldom considered task.

A simple web interface doesn't cut it.  CorVision had rich field-by-field interactivity.  CorVision forms are not simple fill in a few fields and click SUBMIT.  Complex business rules and logic can be happening between every field.  Some CorVision sites built ASP page 'equivalents' of CorVision forms  - the users rejected them.

That green screen may be unlovely, but its a tough act to follow!

There's a lot of CorVision to replace!  Converting the Builder procedural code is a very small part of the task.  Remember:

• Menus & security & multi-form transaction bounding
• Screen event model & scrolling groups
• All the behind the scenes behaviors: Check links & integrity validations, pop-up windows for look-ups, steps, linked parent/child lists. 
• Reports & custom procedure & batch processing
• End user QUERY
• Help system
  

Testing and Revalidation is a huge  task.  With newly written code or a modified package,  you must go through the whole process of validating your CorVision replacement system. 

OK, so its coded and tested --
Now comes the real fun, Going Live!

Turning on the rewritten CorVision applications is a big-bang event, unless you can run against the exact same RMS and Rdb files CorVision is using, like a CV2VB application can.   A bad cutover of a good application will be remembered in your organization's cultural history for a long time. 

 

Great!  Its up and running --
How many developers does it take to...

CorVision generated 85-90% of the code -- your developers never looked at that generated code.   Generated code depended on a huge runtime system to handle the complicated screen processing.  That functionality has to be replaced too.

Even when your container ship comes in with that well rewritten perfectly converted application -- if you must maintain 5x the number of lines of code, how many developers will you need?

If you chose a CV2VB conversion from Order Processing Technologies, you can continue using CorVision to develop and test - then generate for Windows - OR - we provide CorVision-like tools, to maintain the repository -- so the developers won't spend time maintaining the plumbing, and your applications will retain a standard look and feel.