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 knowledgebase of what the system is in VB6/ASP, then we can use it as a framework for planning the work to reproduce the system in .NET. Our assessment process and reporting tools 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. 

Uncertainty

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 are often dynamic and very difficult to quantify.  In practice most teams must manage these factors carefully to keep the pace and cost of the project within expectations.

• Experience, efficiency, and costs of labor for different members of the team
• Desired Schedule
• Expected and actual allocation of resources
• Desired .NET coding standards and "code quality"
• Increasing efficiency as the automated migration process is refined  
• Increasing efficiency as the team climbs the .NET learning curve  
• Frequency of delivery cycles during the migration effort  
• Quality and consistency 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. network, workstation speed)  
• Ability to define test cases, prepare test data, and do testing, especially integration testing in later stages
• Consistency, depth and completeness of technical requirements for each sprint
• Impact of synergy of other changes being made to the system for ongoing maintenance