The gmStudio Value Proposition

So what does it cost???

Prospective customers always ask us two things: What is this going to cost? And, How long is this going to take? Both are important questions to ask and difficult questions to answer. Most teams start with two simplistic, but critical requirements:

  • Reproduce Functionality: The new system must, with few or no exceptions "do what it does now."
  • Upgrade the Technology: The new system must use .NET instead of VB6/ASP/COM and "use it well."


Reproducing functionality is primary and it is fairly objective. The idea is this: the existing VB6/ASP source code is a complete, formal specification of the legacy functionality, so IF one can rewrite it precisely and accurately, the resulting .NET code will produce the functionality "exactly". We know it's a big IF, but one thing we also know is that the precision, accuracy, and scalability of rewriting code with gmStudio and our tool-assisted rewrite methodology can meet this requirement much more efficiently than doing it manually.

Upgrading technology is also extremely important, but is much more subjective. One cannot know how far they will travel until they know where they are starting from and decide where they are going. gmStudio can help you understand and plan upgrade work, but teams must still understand what the new platform has to offer and agree on how to take advantage of it. Teams will want to try, test, refine, and apply technical design changes on a large scale and doing this with gmStudio is much more efficient than doing it manually.

gmStudio enables an agile Tool-Assisted Rewrite Methodology that helps
serious migration teams incrementally verify, improve, and customize an
automated, repeatable upgrade process to meet their unique technical requirements.

Using gmStudio can dramatically change how you allocate your upgrade project budget:

  • Spend less on functional requirements gathering: because you can get
    them in detail from your source code and rewrite them very precisely.

  • Spend less on coding: because most of the code is generated
    by a custom configured translation tool.

  • Spend less on testing: because the code is produced systematically
    it has fewer defects and corrections can be made efficiently by
    retranslating the entire application.

  • The bottom line is this: teams can deliver a lot more upgrade
    with fewer resources, and can spend a greater portion
    of the resources on technical design, optimization,
    and strategic functional enhancements.

Next Steps