Page tree
Skip to end of metadata
Go to start of metadata

Budget Setting

gmStudio was initially created to help us deliver large-scale custom migration services to our clients. Early in our discussions with these clients, we were always asked two questions:

  • What is this going to cost?  
  • How long is this going to take?

Unfortunately, most teams do not have a useful notion of how big or "complex" their systems are, let alone what they want their systems to become as a result of the migration. The requirements were typically little more than this:

  • Our legacy codebase is not well documented, but we have been adding functionality to it for a long time and it is "big";  
  • Our objective is to have a .NET application that does the same things as our legacy application.

Given the lack of clear requirements, we had our work cut out for us to come up with accurate cost and time estimates. We leveraged our toolset to help us gather information on the source system -- the idea being that if we can build a sufficient knowledge base of what the system is in VB6/ASP, then we can use it as a framework for planning the work to reproduce it in .NET. The assessment process and tools described here were the results of this experience.

The Role of Design

You cannot know how far you have to travel until you know where you are starting from and decide where you are going. Beware that assessment work alone does not tell you how to solve your problems, it only helps you understand them better. You must still develop an understanding of what the new platform has to offer -- both the good and the bad -- and agree on which designs will work well for your application. You will have to do this design work no matter if you plan to use tools or start from scratch. The source code assessment helps you know what you are getting into. Using tools helps you implement and experiment with new designs in a more systematic and efficient fashion. 

Simple Estimation Model

Creating Estimates from metrics looks simple enough:

   R = X * Y

where:

   X = number of "units" of a given type to be migrated (applications, components, forms, methods, lines of code, etc.)
   Y = cost for migrating a unit of X (amount of resources needed to complete one unit of migration)
R = total resources needed to do the migration of all units of X

For example: if your your application has 100 forms and you decide that each form will take an average of 20 hours to migrate then you will need 2000 hours to migrat the application.

Clearly, this approach is too simplistic. You will want to account for a few other factors to boost your accuracy:

  • Whether X is lines of code, forms, systems classes, whatever, beware that all X are not created equal, and all X do not require the same effort.  You need to think about what factors drive the effort to migrate a given unit of 
  • Even if you set out to define different effort levels based on complexity, there will be serious unknowns to contend with and the effort per unit will also decrease as you gain experience. This is particularly true with our methodology, which is specifically designed to be flexible, improvable and repeatable.

So, no matter what, it is very likely that your initial estimates will be very rough and depending on your style they will have some degree of error. You will certainly want to refine the numbers as you progress.

Fortunately, gmStudio can produce a collection of extremely detailed reports and help you do other types of adhoc analysis. These data can help you map out a set of finite migration tasks that can each be assigned a reasonable work estimate.

Phases and Features

We usually estimate a project in up to four Phases.  The First Phase is a Standard Upgrade: providing .NET code that Builds in .NET and meets a few other general, objective measures of completeness and quality.  The first phase will be a "direct translation" leveraging simpler, out-of-the-box capabilities.  Given a well-formed, complete source codebase, a skilled gmStudio user can completed a Standard Upgrade fairly easily. The Second Phase is the Custom Upgrade: providing code that contains specific upgrade features, but still objectively measurable technical code quality.  Upgrade features are of four types:

  • Language Compatibility and Coding Conventions
  • COM API Replacements
  • Win32 Replacements
  • Structural Changes

Delivering each Custom Upgrade feature requires definition, analysis, design, implementation and verification with a corresponding effort.  Upon completing the Second Phase you will have a .NET code that is ready for final optimization and integration testing.  The Third Phase of the methodology is an Optimized and Verified Upgrade: providing an integrated runnable .NET code meeting the specific functional (correctness, performance) requirements that are in scope.  The final phase is Transition: providing .NET code that is running in production and being efficiently maintained on the .NET platform.   The emphasis on the translation tool is very strong in the beginning phases and shifts to an emphasis on testing and manual maintenance processes in the later phases.

Other Important Variables

A final word of caution on estimation. There are many factors beyond the size and complexity of the source code that can have a very large impact on time and cost. These other factors must figured into the estimate and managed carefully during the project:

  • Desired .NET coding standards and "code quality"
  • Desired Schedule and competing the work
  • Makeup of the migration team and the various experience, efficiency, and costs of labor for different members of the team
  • Increasing efficiency as the automated migration process is refined  
  • Increasing efficiency as the team climbs the .NET learning curve  
  • Frequency of delivery cycles you will make during the migration effort  
  • Quality of the source codebase
  • Size, type, and frequency of changes to the source code during the migration effort
  • Development processes and working environment efficiency (e.g., onsite, offsite)  
  • Ability to define test cases, prepare test data, and do testing, especially runtime testing in later stages of the methodology  
  • Consistency, depth and completeness of technical requirements for each cycle  
  • Impact of synergy other changes being made to the system for ongoing maintenance